# Duplicate transaction IDs and the BIP 30 rule

Explore Bitcoin’s historical duplicate coinbase transactions, the UTXO overwrite problem, and why archival records need block context.

Canonical page: https://mybitcoinexplorer.com/learn/duplicate-transactions-bip30
Topic: Blocks and the blockchain
Published: 2026-10-31
Updated: 2026-10-31

> Implementation examples refer to Bitcoin Core 30.0. File layouts and operational behavior can change; check the documentation for your installed version.

## A transaction hash is not a random serial number
A transaction ID is calculated from serialized transaction data. Repeating the same relevant bytes produces the same identifier; this does not require finding a cryptographic hash collision. Historical coinbase transactions make this distinction particularly important.

A coinbase creates the block's mining reward rather than spending ordinary previous outputs. Before additional uniqueness rules, two blocks could contain coinbases with identical transaction data. An archive designed around the slogan “one txid, one occurrence” can mishandle these old records even when its hashing code is correct.

> Diagram: Historical occurrence and spendable state are separate records — Block: transaction occurrence → Txid: content identifier → Outpoint: txid plus index → UTXO state: currently spendable

## Why overwriting state is dangerous
An outpoint identifies an output by transaction ID and output index. If a later duplicate replaces an earlier record while some earlier outputs remain unspent, the node can lose the information needed to represent the original coins correctly. Disconnecting the later block during a reorganization makes the bookkeeping problem more serious.

BIP 30 addresses this by prohibiting a new transaction from duplicating an earlier transaction with unspent outputs in the same chain. Mainnet preserves two historical exception blocks, at heights 91,842 and 91,880. Those exceptions belong to historical consensus handling; they are not an invitation to treat duplicate identifiers as normal new payments.

## Height makes new coinbases different
BIP 34 adds the block height at the start of the coinbase input script. Because different heights contribute different data, coinbases constructed under this rule differ across heights. This explains the relationship between the uniqueness problem and the extra data visible in a decoded coinbase.

Do not describe the change as replacing a weak hash with a stronger one. The historical issue involved identical transaction content, not a practical attack on SHA-256. The hash continued to do its job of giving identical content the same identifier.

### Worked example: Design a historical explorer record
Suppose an archive encounters the same txid in two historical blocks. Keep transaction content identifiable by txid, but preserve each inclusion with its block hash and position. A receipt requested for one occurrence should display that block context. Silently overwriting the first inclusion with the second makes dates and confirmations ambiguous.


## Separate display totals from spendable coins
Adding every historical output amount is not a safe way to reconstruct a current balance. A balance depends on the chain's valid spendable state, including spends and consensus exceptions. Reorganizations also change which block inclusions belong to the active chain.

When researching an unusual old transaction, preserve the block hash, height and transaction position alongside the txid. Compare the inclusion with current chain status before drawing conclusions about availability to spend. An interesting historical duplicate does not prove that somebody received the same money twice in today's UTXO set.

This is one reason explorer URLs may carry a block reference even when they already contain a transaction ID. Context can resolve a historical occurrence; it does not reveal the real-world identity behind the transaction.

## Key takeaways

- Identical transaction data can repeat a txid without a hash collision.
- BIP 30 protects unspent-output state; BIP 34 adds height to new coinbases.
- Archival inclusions need block context in addition to transaction content identifiers.

## Common questions

### Were these SHA-256 collisions?

No. The historical duplicates involved repeated transaction data, not different data successfully colliding under the hash.

### Should a balance simply count both historical rewards?

No. Reconstruct valid UTXO state with the historical consensus rules rather than summing displayed records.

## Sources and further reading

- [BIP 30: duplicate transactions and exceptions](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki)
- [BIP 34: height in the coinbase](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki)

## Related lessons

- [The coinbase transaction](https://mybitcoinexplorer.com/learn/coinbase-transaction)
- [Transaction IDs (txid)](https://mybitcoinexplorer.com/learn/transaction-id-txid)
- [Stale blocks and chain reorganizations](https://mybitcoinexplorer.com/learn/stale-blocks-and-reorgs)