<p>You aren't doing anything wrong. You just need to be able to handle those duplicate transaction ids. It actually happens a few times before BIP 30 went into effect making such duplicate txids invalid.</p>

<p>These duplicates happen because the coinbase transaction in two different blocks can be exactly the same, so they have exactly the same txid. This is because prior to BIP 34, there was not anything that makes each coinbase transaction unique; you could have a transaction which pays out to exactly the same address with exactly the same amount (the block subsidy) and if you don't set a coinbase string or use an extranonce in the coinbase, you will have two identical coinbase transactions.</p>

<p>To handle the two cases where transaction duplication happens, you should allow an exception to the BIP 30 rule for those blocks. The transaction that those duplicate txids reference when being spent can only be the most recent duplicate transaction. Any prior ones are completely unspendable.</p>

CC BY-SA 3.0
2017-10-14T23:27:36.570Z
OK, so what you are saying here is that the first transaction is basically lost, correct? I understand that this happens easily in the Coinbase, but what would the (new/current) way be to handle this if it was in a standard transaction, and just happened by accident?
AmbitiousScriptKiddy
CC BY-SA 3.0
2017-10-14T23:28:27.333Z
Yes. The first time you see a duplicate transaction, that transaction is gone.
Ava Chow
CC BY-SA 3.0
2017-10-14T16:01:16.937Z
2017-10-14T16:01:16.937Z
Ava Chow
<p>Maybe this question is utterly stupid, but I just don't get it:
I am doing some POC work to understand the BitCoin network a little better and chose C# and the NBitCoin library as my implementation for it. Now, I was trying to read through the blockchain (with a current version of BitCoinCore installed and running locally on my machine) when I hit an unexpected exception: A transaction hash seems to exist twice in the chain. 
The Hash looks like this: d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
I found it once at the Block 14.11.2010 17:59:48
and then again at 14.11.2010 21:04:51 
In both cases the entry is the same, a new coin generation transaction. 
Looking the hash up at blockexplorer.com I can find it at 14.11.2010 22:04:51 (they use a diffent date format there, I just converted it to match the others in this post.) </p>

<p>What am I doing wrong here? I mean... I guess that duplicate transaction IDs can happen throughout the chain, after all, they are just hashes, but how would I ever match the spending input to one of those if the Hash I am referencing it to is not unique?</p>

<p>I am really confused here right now and would appreciate good insights.</p>

<transactions><blockchain><nbitcoin>
NBitCoin Analyzing Blockchain
AmbitiousScriptKiddy
# NBitCoin Analyzing Blockchain

(Asked by: username_0 on 2017-10-14)

Maybe this question is utterly stupid, but I just don't get it:
I am doing some POC work to understand the BitCoin network a little better and chose C# and the NBitCoin library as my implementation for it. Now, I was trying to read through the blockchain (with a current version of BitCoinCore installed and running locally on my machine) when I hit an unexpected exception: A transaction hash seems to exist twice in the chain.
The Hash looks like this: d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
I found it once at the Block 14.11.2010 17:59:48
and then again at 14.11.2010 21:04:51
In both cases the entry is the same, a new coin generation transaction.
Looking the hash up at blockexplorer.com I can find it at 14.11.2010 22:04:51 (they use a diffent date format there, I just converted it to match the others in this post.)

What am I doing wrong here? I mean... I guess that duplicate transaction IDs can happen throughout the chain, after all, they are just hashes, but how would I ever match the spending input to one of those if the Hash I am referencing it to is not unique?

I am really confused here right now and would appreciate good insights.

**Tags:** transactions, blockchain, nbitcoin


---

## 1 answers

### Answer by username_1 on 2017-10-14. Score: 2 | Accepted answer

You aren't doing anything wrong. You just need to be able to handle those duplicate transaction ids. It actually happens a few times before BIP 30 went into effect making such duplicate txids invalid.

These duplicates happen because the coinbase transaction in two different blocks can be exactly the same, so they have exactly the same txid. This is because prior to BIP 34, there was not anything that makes each coinbase transaction unique; you could have a transaction which pays out to exactly the same address with exactly the same amount (the block subsidy) and if you don't set a coinbase string or use an extranonce in the coinbase, you will have two identical coinbase transactions.

To handle the two cases where transaction duplication happens, you should allow an exception to the BIP 30 rule for those blocks. The transaction that those duplicate txids reference when being spent can only be the most recent duplicate transaction. Any prior ones are completely unspendable.

> **Comments:**
> **username_0**: OK, so what you are saying here is that the first transaction is basically lost, correct? I understand that this happens easily in the Coinbase, but what would the (new/current) way be to handle this if it was in a standard transaction, and just happened by accident?  
> **username_1**: Yes. The first time you see a duplicate transaction, that transaction is gone.  

---

