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?

5
  • 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
    Commented Sep 8, 2015 at 1: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? Commented Sep 8, 2015 at 1:16
  • @Bitcoin Well, yes, but supposing that you used it to make duplicate transactions, what would happen?
    – Nick ODell
    Commented Sep 8, 2015 at 2: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
    Commented Sep 8, 2015 at 2: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
    Commented Sep 9, 2015 at 0:44

1 Answer 1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.