BIP 0030

This page describes a BIP (Bitcoin Improvement Proposal). Please see BIP 2 for more information about BIPs and creating them. Please do not just create a wiki page.

  BIP: 30
  Title: Duplicate transactions
  Author: Pieter Wuille <pieter.wuille@gmail.com>
  Status: Draft
  Type: Standards Track
  Created: 22-02-2012

Abstract

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

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 is to be applied to all blocks whose timestamp is after a point in time that is yet to be decided.

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.
2. Remember previous remaining outputs of a given transaction identifier, in case a new transaction with the same identifier is added.
3. 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

Acknowledgements

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