<p>In Bitcoin, it was originally an assumption that miners producing blocks would use a unique address per transaction, making sure that the coinbase of each block had a unique TXID. As this was not enforced, users accidentally made duplicate transactions by setting the same destination address for multiple solved blocks. BIP34 simply adds a new field to be validated to the block, requiring that the height is also part of the hash, ensuring uniqueness for all future blocks.</p>
<p>For the two special cased BIP34 blocks, the outcome is rather simple. The first instance of the TXID creates the UTXO, the second invocation does nothing at all because the output already exists, and if they were ever spent the UTXO can only be removed from the database a single time. The money involved in the second instance of the TXID was destroyed, causing a loss of 100 BTC total.</p>

CC BY-SA 4.0
2020-09-02T13:31:34.203Z
thanks for answer. So coinbase outputs for the same public address naturally hashed the same. But is it the case that still - after Bip34 change - two very different transactions can hash to the same hash causing a loss of unspent bitcoin (because sha256 isn't injective after all)?
zaabson
CC BY-SA 4.0
2020-09-02T21:15:26.493Z
The chance is effectively zero. We don't design software with the assumption that duplicate TXID could exist, as we would have significant other issues if collisions where commonplace.
Claris
CC BY-SA 4.0
2020-09-02T12:59:11.847Z
2020-09-02T12:59:11.847Z
Claris
<p>I'm writing my own simple crypto and wondering whether input in a transaction should refer to unspend output only by it's TXID and vout (index in outputs vector in a transaction) OR by it's TXID and full address in a blockchain - that is block height, transaction index in a block and output index in a transaction.</p>
<p>The first approach seems to have a flaw - it's unlikely but possible for two different outputs to have the same TXID and vout.</p>
<p>But in the second approach I don't even need TXID when I have the full blockchain address right? I don't want to double on bookeeping - when there's duplicate data you need to make sure it's consistent.</p>
<p>So my two question's are:</p>
<ol>
<li>How to avoid the problem with two transaction's accidentally having the same hashes in an elegant way that - ideally - doesn't require storing full addresses?</li>
<li>How is it done in Bitcoin? (here I guess that bitcoin's Bip34 update was addressing this flaw I mentioned - but I don't understand how)</li>
</ol>
<p>General advices on solutions are very welcome. Thanks in advance!</p>

<development><output><transaction-id><utxo-set>
Refer to UTXO by output index or output full address in blockchain?
zaabson
# Refer to UTXO by output index or output full address in blockchain?

(Asked by: username_0 on 2020-09-02)

I'm writing my own simple crypto and wondering whether input in a transaction should refer to unspend output only by it's TXID and vout (index in outputs vector in a transaction) OR by it's TXID and full address in a blockchain - that is block height, transaction index in a block and output index in a transaction.

The first approach seems to have a flaw - it's unlikely but possible for two different outputs to have the same TXID and vout.

But in the second approach I don't even need TXID when I have the full blockchain address right? I don't want to double on bookeeping - when there's duplicate data you need to make sure it's consistent.

So my two question's are:

1. How to avoid the problem with two transaction's accidentally having the same hashes in an elegant way that - ideally - doesn't require storing full addresses?
2. How is it done in Bitcoin? (here I guess that bitcoin's Bip34 update was addressing this flaw I mentioned - but I don't understand how)

General advices on solutions are very welcome. Thanks in advance!

**Tags:** development, output, transaction-id, utxo-set


---

## 1 answers

### Answer by username_1 on 2020-09-02. Score: 2

In Bitcoin, it was originally an assumption that miners producing blocks would use a unique address per transaction, making sure that the coinbase of each block had a unique TXID. As this was not enforced, users accidentally made duplicate transactions by setting the same destination address for multiple solved blocks. BIP34 simply adds a new field to be validated to the block, requiring that the height is also part of the hash, ensuring uniqueness for all future blocks.

For the two special cased BIP34 blocks, the outcome is rather simple. The first instance of the TXID creates the UTXO, the second invocation does nothing at all because the output already exists, and if they were ever spent the UTXO can only be removed from the database a single time. The money involved in the second instance of the TXID was destroyed, causing a loss of 100 BTC total.

> **Comments:**
> **username_0**: thanks for answer. So coinbase outputs for the same public address naturally hashed the same. But is it the case that still - after Bip34 change - two very different transactions can hash to the same hash causing a loss of unspent bitcoin (because sha256 isn't injective after all)?  
> **username_1**: The chance is effectively zero. We don't design software with the assumption that duplicate TXID could exist, as we would have significant other issues if collisions where commonplace.  

---

