Bitcoin Forum
December 03, 2016, 06:03:25 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Transactions with identical hashes  (Read 2301 times)
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
November 17, 2010, 01:52:11 AM
 #1

Generation transaction d5d27987d2... appears in block 91812 and 91842. This is probably an accidental side-effect of miners that reuse keys.

How does Bitcoin handle this conflict when these transactions are redeemed? I haven't found anything for this situation in the code. If it's not handled, are all such transactions worth only the value of one?

(Bitcoin Block Explorer isn't handling this correctly, but I don't have time to fix it right now.)

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
1480788205
Hero Member
*
Offline Offline

Posts: 1480788205

View Profile Personal Message (Offline)

Ignore
1480788205
Reply with quote  #2

1480788205
Report to moderator
1480788205
Hero Member
*
Offline Offline

Posts: 1480788205

View Profile Personal Message (Offline)

Ignore
1480788205
Reply with quote  #2

1480788205
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480788205
Hero Member
*
Offline Offline

Posts: 1480788205

View Profile Personal Message (Offline)

Ignore
1480788205
Reply with quote  #2

1480788205
Report to moderator
1480788205
Hero Member
*
Offline Offline

Posts: 1480788205

View Profile Personal Message (Offline)

Ignore
1480788205
Reply with quote  #2

1480788205
Report to moderator
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
November 17, 2010, 05:05:42 PM
 #2

Oh no! That's really bad!

Suggested fix: Include the block number in the coinbase.

For discussion: The new client release should, among the other changes, allow an artificial "special" coin generation to credit that public key to compensate for the unusable coinbase credit.

ByteCoin
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
November 17, 2010, 05:13:18 PM
 #3

Oh no! That's really bad!

Not really. The effect is limited to the people who create these transactions (which stock Bitcoin would never do).

I probably should have specified in the OP: this is not a problem with the cryptography. These miners are actually creating transactions that are exactly the same.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
SmokeTooMuch
Legendary
*
Offline Offline

Activity: 873


View Profile
November 17, 2010, 05:20:46 PM
 #4

so ... how did something like that even happen ?

Date Registered: 2009-12-10 | I'm using GPG, pm me for my public key. | Bitcoin on Reddit: https://www.reddit.com/r/btc
You like what I'm doing? Why don't you send me a coin: 17Pj8jpUgY6qTaKgiopL5U48zxU4rTrkuB
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
November 17, 2010, 05:24:19 PM
 #5

so ... how did something like that even happen ?
The implementation does not take enough care to ensure that different coinbase transactions have different hashes. That is to say that the "standard" does not mandate that something like the block number *has* to be in the coinbase transaction for the block to be valid.

ByteCoin
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
November 17, 2010, 05:29:22 PM
 #6

so ... how did something like that even happen ?

Generation transactions aren't very different from one another if you modify Bitcoin to re-use the same key for every generation. The only real difference between them at this point is the extraNonce value, which has a relatively small range of typical values.

This is not a fault in Bitcoin, but in someone's custom miner. (Maybe the network should have rejected the transaction. No harm done to the network, though.)

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
November 17, 2010, 05:45:24 PM
 #7

This is not a fault in Bitcoin, but in someone's custom miner. (Maybe the network should have rejected the transaction. No harm done to the network, though.)
There is an implied contract between the miners and the network that the effort that the miners exert to generate blocks is rewarded by 50BTC (at least, and at the moment) which they can spend as long as they take care not to lose their secret key for example. The network is breaking their side of the bargain by not allowing 50BTC rightfully mined to be spent.

The damage to the network is to its reputation and credibility. If you had 50BTC held in some address, if the majority of generating power conspired appropriately, they could arbitraritly fail to accept any transactions using that address. Would you argue that in this case there's no harm to the network too? What about if the miners conspired to exclude all non-fee paying transactions or on some other metric?

ByteCoin
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
November 17, 2010, 05:51:40 PM
 #8

There is an implied contract between the miners and the network that the effort that the miners exert to generate blocks is rewarded by 50BTC (at least, and at the moment) which they can spend as long as they take care not to lose their secret key for example. The network is breaking their side of the bargain by not allowing 50BTC rightfully mined to be spent.

The miners are mining wrong. You need to prevent this situation from happening. The network can't do it for you.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
November 17, 2010, 06:01:14 PM
 #9

The network can't do it for you.
Yes it can. The network should demand that valid blocks have the block number hashed into the coinbase before accepting the block. The way that hashed transaction values are used in bitcoin demands that reasonable effort is made by all parties to ensure that they are unique. Clients already make a number of checks before accepting blocks and this should be one of them. Of course the onus really falls on the mining clients to check previous blocks. All the more reason why it should be easy to make your own highly optimised mining program without having to worry about keeping the network healthy by ensuring your software performs adequate checks. There should be a mining interface to the current vanilla client.

ByteCoin
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
November 17, 2010, 07:35:51 PM
 #10

The network can't do it for you.
Yes it can. The network should demand that valid blocks have the block number hashed into the coinbase before accepting the block. The way that hashed transaction values are used in bitcoin demands that reasonable effort is made by all parties to ensure that they are unique. Clients already make a number of checks before accepting blocks and this should be one of them. Of course the onus really falls on the mining clients to check previous blocks. All the more reason why it should be easy to make your own highly optimised mining program without having to worry about keeping the network healthy by ensuring your software performs adequate checks. There should be a mining interface to the current vanilla client.

ByteCoin

What if you modify your client so that the coins are sent to an address for which no private key was generated? Is the network still at fault?

I don't know enough to have an opinion of this particular situation, but obviously to some extent custom miners need to make sure they understand how the network works.

If somehow it was said or implied that what they were doing would be fine, then obviously that should be fixed or made clear.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
November 17, 2010, 08:22:18 PM
 #11

The network can't do it for you.
Yes it can. The network should demand that valid blocks have the block number hashed into the coinbase before accepting the block. The way that hashed transaction values are used in bitcoin demands that reasonable effort is made by all parties to ensure that they are unique. Clients already make a number of checks before accepting blocks and this should be one of them. Of course the onus really falls on the mining clients to check previous blocks. All the more reason why it should be easy to make your own highly optimised mining program without having to worry about keeping the network healthy by ensuring your software performs adequate checks. There should be a mining interface to the current vanilla client.

ByteCoin

What if you modify your client so that the coins are sent to an address for which no private key was generated? Is the network still at fault?

I'm pretty sure that the standard client can send coins to an address that doesn't actually exist, if the address is entered by hand and is a valid address by it's checks. 

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
November 17, 2010, 09:08:16 PM
 #12

The network can't do it for you.
Yes it can. The network should demand that valid blocks have the block number hashed into the coinbase before accepting the block. The way that hashed transaction values are used in bitcoin demands that reasonable effort is made by all parties to ensure that they are unique. Clients already make a number of checks before accepting blocks and this should be one of them. Of course the onus really falls on the mining clients to check previous blocks. All the more reason why it should be easy to make your own highly optimised mining program without having to worry about keeping the network healthy by ensuring your software performs adequate checks. There should be a mining interface to the current vanilla client.

ByteCoin

Yeah, I think that is right. I was thinking more if you sent your generates to go to unowned addresses, but the point is the same, there is some obligation to know what you are doing, the network can't magically fix mistakes people make.

What if you modify your client so that the coins are sent to an address for which no private key was generated? Is the network still at fault?

I'm pretty sure that the standard client can send coins to an address that doesn't actually exist, if the address is entered by hand and is a valid address by it's checks. 

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
November 17, 2010, 11:18:28 PM
 #13


Yeah, I think that is right. I was thinking more if you sent your generates to go to unowned addresses, but the point is the same, there is some obligation to know what you are doing, the network can't magically fix mistakes people make.

What if you modify your client so that the coins are sent to an address for which no private key was generated? Is the network still at fault?

I'm pretty sure that the standard client can send coins to an address that doesn't actually exist, if the address is entered by hand and is a valid address by it's checks.  

I'm not advocating that the standard client attempt to prevent people from their forseeable consequences of their own decisions. The blame for the "loss" of 50BTC in this case lies squarely with the standard client/protocol as I explain below.

The key point is the implied contract between the generator and the standard client. If the network accepts the new block then it should reward the miner with 50BTC that the miner can dispose of as they choose. If the miner wants to send it to an un-owned address then that's fine. In this case, the miner clearly made the effort to allocate the coins to himself and the uselessness of those coins is purely due to the fact that the network just happens to identify coins by their hash and there was a hash collision with some other coins.(Slight simplification of the real situation to save space). The assumption behind the design decision to identify transactions only by their hash was the expected uniqueness of hashes. Proper efforts are made in other areas of the code to ensure the truth of this assumption. The fact that no adequate efforts are made here is a flaw.

ByteCoin

PS I (and at least one more person) have sent coins to un-owned addresses. The fact that this is permitted is fine.
m0mchil
Full Member
***
Offline Offline

Activity: 171


View Profile
November 18, 2010, 07:54:39 AM
 #14

I am really worried about this. It's highly possible that the problem is in my getwork patch, now used by many.

I would really appreciate someone taking a look at the patch, specifically the CheckWork() and PrepareWork() functions in main.cpp

Yes, it is reusing a key from the pool, but if block is found the key is never used again. Both functions should be thread safe.

Theymos, are there other such generations?

theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
November 18, 2010, 03:01:48 PM
 #15

Theymos, are there other such generations?

On the main network:
http://theymos.ath.cx:64150/bbe/block/00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec
http://theymos.ath.cx:64150/bbe/block/00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721

On the test network:
http://theymos.ath.cx:64150/testnet/bbe/block/000000005c1f1c3665e253edf5ec4c05f7e61727c198648396410ace8f66a13f
http://theymos.ath.cx:64150/testnet/bbe/block/000000002c4e72e2210e634360d4121ea67192d7f14603c5dc9bcc2083bb6eaf
http://theymos.ath.cx:64150/testnet/bbe/block/000000003b2f59295ed671a4a7c33e605835584fa6c578aadb077787dc7b96f1

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!