<p>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.</p>

<p>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.</p>

<p>That was clearly ricidulous, so under <a href="https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki" rel="noreferrer">BIP 30</a>, including a second transaction with the same txid when <em>any output</em> from first is still unspent is invalid. It used to be enforced by the timestamp of the block, but it is now applied to <a href="https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514" rel="noreferrer">every block in the blockchain except for the two that break this rule</a>.</p>

CC BY-SA 3.0
2015-09-08T02:52:22.110Z
2015-09-08T02:52:22.110Z
Nick ODell
<p>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.</p>

<p>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?</p>

<p>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?</p>

CC BY-SA 3.0
2015-09-08T01:15:23.880Z
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
CC BY-SA 3.0
2015-09-08T01:16:07.127Z
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
CC BY-SA 3.0
2015-09-08T02:26:13.000Z
@Bitcoin Well, yes, but *supposing* that you used it to make duplicate transactions, what would happen?
Nick ODell
CC BY-SA 3.0
2015-09-08T02:30:01.167Z
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
CC BY-SA 3.0
2015-09-09T00:44:44.227Z
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
<transaction-id>
What happens when two txid's collide?
Nick ODell
# What happens when two txid's collide?

(Asked by: username_0 on 2015-09-07)

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?

**Tags:** transaction-id

> **Comments:**
> **username_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.  
> **username_2**: 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?  
> **username_0**: @Bitcoin Well, yes, but *supposing* that you used it to make duplicate transactions, what would happen?  
> **username_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.  
> **username_3**: 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.  

---

## 1 answers

### Answer by username_0 on 2015-09-08. Score: 5 | Accepted answer

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](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki), 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](https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514).


---

