Wallet encryption could cause duplicate coinbase txes #482

Quote from https://github.com/bitcoin/bitcoin/commit/59ed5cb398f3817cebd8f5c6aeba3424de2acefe#commitcomment-562434

This edit states that the "default key" will be used as the target for payouts for mining. If this is correct, then it might be problematic and could result in a loss of funds to miners. When miners mine more than one block using the same payout address, the coinbase transactions in each block are identical, which results in them having an identical sha256 hash, which results in all but the first one being unidentifiable and hence unspendable. I suppose you might be aware of that, but wanted to point this out just to prevent the possibility of it being an expensive consequence for somebody else.

Can somebody double-check to see if I'm reading the code correctly?

Looks like both BitcoinMiner and getwork() call IncrementExtraNonce() to create unique coinbase transactions, so I don't think this is an issue.

They both call IncrementExtraNonce... which resets the extra nonce every second after overflowing. This guarantees unique block candidates, but not unique coinbase transactions. When an infinite supply of pubkeys are available, this isn't a problem, because after creating a block, the previous default pubkey will be in use, and a new one will be used.

My suggestion: add the current timestamp to the coinbase when no fresh pubkeys are available.

Also, the extra nonce used in IncrementExtraNonce isn't stored across restarts. This isn't normally an issue due to the timestamps in block headers - it's very unlikely a bitcoin restart will take less than a second - but it means that not resetting the extranonce isn't a solution.