8

Let's suppose that I can create SHA256d collisions, and I use this ability to create two transactions that have the same hash, A and B. These transactions are not the same, but they hash to the same value.

I submit transaction A to the network, and wait until it has a few confirmations. Then, I submit transaction B. Will it get included into the chain? Will it overwrite transaction A?

If the answer to the previous two questions is yes, then what will happen if the block containing transaction B is reorganized out of the chain? Will transaction A be un-overwritten?

Nick ODell
  • 29,184
  • 11
  • 69
  • 129
  • 1
    If you could generate SHA256 collisions easily I think you would probably want to go for the merkle tree first rather than TXID, being able to produce two blocks that have the same hash but different transactions would be extremely destructive and probably not noticed for a long time. – Claris Sep 08 '15 at 01:15
  • Another question: if you then create a transaction which spends A, and get it included in a block, will nodes randomly consider this block as valid/invalid depending on whether they resolve the input txid to A or B? – Nate Eldredge Sep 08 '15 at 01:16
  • @Bitcoin Well, yes, but *supposing* that you used it to make duplicate transactions, what would happen? – Nick ODell Sep 08 '15 at 02:26
  • 1
    I don't have the time to research it right now so I'm not going to put it in as an answer, but I guess it would follow the same rules as the two BIP30/34 duplicate TXID, if one is spent the other one is just destroyed. I think they are special cased in the source though so that might only apply to them specifically. – Claris Sep 08 '15 at 02:30
  • Remark: TXID collisions have happened in the past before. This is due to the coinbase transaction being identical, and derived transactions can be made to be identical too. This has been fixed by BIP 34 which forces every coinbase script to be different. – Nayuki Sep 09 '15 at 00:44

1 Answers1

5

No. After transaction A is included into the chain, transaction B is invalid, and will not be mined. If it does show up in a mined block, the entire block is invalid.

It wasn't always like this. Initially, if a transaction had the same txid as a previous transaction, it would overwrite the first one. Then, if that block was reorganized out of the chain, the second transaction would be removed, but the first transaction would not be added. In other words, adding and removing the block would change the state of the unspent transaction set.

That was clearly ricidulous, so under BIP 30, including a second transaction with the same txid when any output from first is still unspent is invalid. It used to be enforced by the timestamp of the block, but it is now applied to every block in the blockchain except for the two that break this rule.

Nick ODell
  • 29,184
  • 11
  • 69
  • 129