Transactions with identical hashes

[theymos]

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.)

[ByteCoin]

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]

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.

[SmokeTooMuch]

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

[ByteCoin]

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]

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.)

[ByteCoin]

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]

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.

[ByteCoin]

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]

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.

[MoonShadow]

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. 

[FreeMoney]

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. 

[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.  

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]

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]

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