Home › Browse › BIP 30

BIP 30: Duplicate transactions

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

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.

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 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…