BIP 30 duplicate transactions explained: learn why overwriting unspent outputs was unsafe, how nodes enforce uniqueness and what miners must validate.
This guide explains BIP 30 duplicate transactions in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
BIP 30 duplicate transactions: A transaction identifier commits to transaction serialisation, not to the block height in which it appears. Coinbase transactions historically could repeat when their fields were identical.
A node operator is checking BIP 30 duplicate transactions. If a later transaction had the same TXID as an earlier one, outputs would share the same outpoint identifiers.
A transaction identifier commits to transaction serialisation, not to the block height in which it appears. Coinbase transactions historically could repeat when their fields were identical. If a later transaction had the same TXID as an earlier one, outputs would share the same outpoint identifiers. The state model then needed an explicit rule to stop live outputs being overwritten.
BIP 30 requires that a block must not contain a transaction whose identifier matches an earlier transaction when any outputs from the earlier transaction remain unspent. Once every earlier output is spent, the duplicate no longer destroys an accessible UTXO under that narrow rule. Modern coinbase-height commitments make accidental duplicates substantially harder.
If one node overwrites the earlier outputs while another preserves or rejects them, their UTXO sets diverge. They can disagree about later spends even though both parsed the same block bytes. The validity rule therefore belongs in block connection, and a database schema with a unique index cannot substitute for the defined historical consensus behaviour.
Bitcoin’s chain contains two pre-enforcement duplicate-transaction cases that modern validation must recognise when replaying history. Implementations commonly encode exceptions for their specific block hashes. The exceptions do not grant miners a general permission to reuse TXIDs; they allow the established chain to remain valid while enforcing the rule elsewhere.
BIP 34 places the current height at the start of the coinbase input script, making each height’s coinbase transaction different under normal construction. This reduces the route to duplicate coinbase TXIDs, but BIP 30 remains part of historical validation and defence in depth. One proposal does not erase the earlier consensus history.
A pool template builder must construct a height-correct unique coinbase and fully validate the candidate. Extranonce normally adds further uniqueness, but it is not the consensus definition. Restored nodes, custom chains and template proxies must not bypass duplicate checks for speed. A solved header cannot rescue a block whose transactions corrupt the UTXO transition.
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
BIP 30 duplicate transactions: A transaction identifier commits to transaction serialisation, not to the block height in which it appears.
A transaction identifier commits to transaction serialisation, not to the block height in which it appears.
BIP 30 requires that a block must not contain a transaction whose identifier matches an earlier transaction when any outputs from the earlier transaction remain unspent.
If one node overwrites the earlier outputs while another preserves or rejects them, their UTXO sets diverge.
BIP 30 protects Bitcoin’s UTXO state from destructive transaction-identifier reuse and preserves two precise historical exceptions. Mining infrastructure should enforce it through a fully validating node and construct unique, height-correct coinbase transactions on every template.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 441 guide to the Draft tapleaf 0xC2 script-restoration proposal, varops, stack limits, unsigned arithmetic, restored opcodes and safety testing.
BIP 440 guide to the Draft transaction-wide variable-operation budget, weight scaling, opcode cost classes, benchmarks, validation and soft-fork status.
BIP 361 guide to the Draft informational post-quantum migration and legacy-signature sunset proposal, phases, prerequisites, risks and readiness planning.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.