Home › Topics › Consensus › BIP 30

BIP 30: Duplicate transactions

Also known as: duplicate transactions rule, BIP30, BIP-0030.

In plain English: Added a rule forbidding a block from including a transaction with the same ID as an earlier one whose outputs are not fully spent. Such duplicates can overwrite earlier coins and make them unspendable, which had already happened twice.

Status
Deployed
Type
Specification
Layer
Consensus (soft fork)
Authors
Pieter Wuille
Assigned
Last changed
Topics
Consensus, Blocks, Mining
Source
bip-0030.mediawiki on GitHub · Markdown

Full specification

Abstract

This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementation has with them.

This BIP is licensed under the 2-clause BSD license.

Motivation

So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network.

Specification

To counter this problem, the following network rule is introduced:

  • Blocks are not allowed to contain a transaction whose identifier matches that of an earlier, not-fully-spent transaction in the same chain.

This rule initially applied to all blocks whose timestamp is after March 15, 2012, 00:00 UTC (testnet: February 20, 2012 00:00 UTC). It was later extended by Commit Apply BIP30 checks to all blocks except the two historic violations. to apply to all blocks except the two historic blocks at heights 91842 and 91880 on the main chain that had to be grandfathered in.

Rationale

Whatever solution is used, the following law must be obeyed to guarantee sane behaviour: the set of usable transactions outputs must not be modified by adding blocks to the chain and removing them again. This happens during a reorganisation, and the current Bitcoin reference implementation does not obey this law in case the temporarily added blocks contain a duplicate transaction.

There are several potential solutions to this problem:

  1. Guarantee that all coinbases are unique, making duplicate transactions very hard to create.
  1. Remember previous remaining outputs of a given transaction identifier, in case a new transaction with the same identifier is added.
  1. Only allow duplicate transactions in case the previous instance of the transaction had no spendable outputs left. Removing a block from the chain can then safely reset the removed transaction's outputs to nothing.

The first option is probably the most complete one, as it also guarantees transaction identifiers are unique. However, implementing it requires several changes that need to be accepted throughout the network. Furthermore, it does not prevent duplicate transactions based on earlier duplicate coinbases. The second option is impossible to implement in a forward-compatible way, as it potentially renders currently-invalid blocks valid. In this document we choose for the third option, because it only requires a trivial change.

Fully-spent transactions are allowed to be duplicated in order not to hinder pruning at some point in the future. Not allowing any transaction to be duplicated would require evidence to be kept for each transaction ever made.

Backward compatibility

The addition of this rule only makes some previously-valid blocks invalid. This implies that if the rule is implemented by a supermajority of miners, it is not possible to fork the block chain in a permanent way between nodes with and without the new rule.

Implementation

A patch for the reference client can be found on https://github.com/sipa/bitcoin/tree/nooverwritetx

This BIP was implemented in Commit Do not allow overwriting unspent transactions (BIP 30) There have been additional commits to refine the implementation of this BIP.

Acknowledgements

Thanks to Russell O'Connor for finding and demonstrating this problem, and helping test the patch.

Questions about BIP 30

What is BIP 30?

BIP 30, “Duplicate transactions”, is a specification Bitcoin Improvement Proposal written by Pieter Wuille and assigned in February 2012. Added a rule forbidding a block from including a transaction with the same ID as an earlier one whose outputs are not fully spent. Such duplicates can overwrite earlier coins and make them unspendable, which had already happened twice.

Is BIP 30 active?

Yes. BIP 30 has the status Deployed, which means it is live: adopted by the Bitcoin network or by widely used software.

Who wrote BIP 30?

BIP 30 was written by Pieter Wuille. Its number was assigned on February 22, 2012.

Which BIPs build on BIP 30?

3 other BIPs reference BIP 30: BIP 118 (SIGHASH_ANYPREVOUT for Taproot Scripts), BIP 123 (BIP Classification) and BIP 95 (Testnet 5).

Where can I read the full BIP 30 specification?

The complete text of BIP 30 is on this page, taken unchanged from the official bitcoin/bips repository on GitHub. It is also available as Markdown and JSON.

BIPs that build on BIP 30

  • BIP 118: SIGHASH_ANYPREVOUT for Taproot Scripts: Draft. Proposes SIGHASH_ANYPREVOUT, a signature type for Taproot scripts that does not commit to the exact coin being spent, so one signed transaction can be attached to any compatible coin. This would…
  • BIP 123: BIP Classification: Deployed. Sets out a way to classify BIPs into layers, such as consensus, peer services, APIs and applications, according to which part of the system they affect. This helps readers judge how widely a…
  • BIP 95: Testnet 5: Draft. Proposes Testnet 5 to replace Testnet 4, removing a special rule that let blocks be mined at minimum difficulty, which had been heavily abused. It also raises the minimum difficulty and applies the…

Learn more

Guides

Glossary

Related proposals

  • BIP 22: getblocktemplate - Fundamentals: Deployed. Defines getblocktemplate, a way for a node to give miners a full block template rather than just a header to hash. Miners can then see and optionally choose which transactions go into a block,…
  • BIP 23: getblocktemplate - Pooled Mining: Deployed. Extends getblocktemplate (BIP 22) with features for mining pools, such as letting participants propose their own blocks to the pool. It helps pooled miners build blocks themselves while still…
  • BIP 34 (block height in coinbase): Block v2, Height in Coinbase: Deployed. Upgraded blocks to version 2 and required each block's coinbase transaction (the one paying the miner) to include the block's height. This makes every coinbase unique, preventing duplicate…
  • BIP 42: A finite monetary supply for Bitcoin: Deployed. A tongue-in-cheek proposal fixing a software quirk that would have made the block reward reappear and coin issuance restart a couple of centuries from now. It ensures the roughly 21 million coin…
  • BIP 50: March 2013 Chain Fork Post-Mortem: Deployed. A post-mortem of the March 2013 incident in which a database limit in older Bitcoin software caused the blockchain to split temporarily. It explains what went wrong, how miners and developers…
  • BIP 52: Durable, Low Energy Bitcoin PoW: Closed. Proposed replacing Bitcoin's mining puzzle with one designed for optical computing chips, so mining costs would depend more on hardware than on electricity. The aim was to cut energy use and spread…