Home › Topics › Consensus › BIP 34

BIP 34 (block height in coinbase): Block v2, Height in Coinbase

Also known as: block height in coinbase, BIP34, BIP-0034.

In plain English: 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 transactions, and set a pattern for rolling out later upgrades.

Status
Deployed
Type
Specification
Layer
Consensus (soft fork)
Authors
Gavin Andresen
Assigned
Last changed
Activated
Block 227,931 (2013-03)
Topics
Consensus, Blocks, Validation
Source
bip-0034.mediawiki on GitHub · Markdown

Full specification

Abstract

Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2.

Motivation

  1. Clarify and exercise the mechanism whereby the bitcoin network collectively consents to upgrade transaction or block binary structures, rules and behaviors.
  1. Enforce block and transaction uniqueness, and assist unconnected block validation.

Specification

  1. Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them).
  1. Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "minimally encoded serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 223-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
  1. 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)
  1. 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100)

Backward compatibility

All older clients are compatible with this change. Users and merchants should not be impacted. Miners are strongly recommended to upgrade to version 2 blocks. Once 95% of the miners have upgraded to version 2, the remainder will be orphaned if they fail to upgrade.

Implementation

https://github.com/bitcoin/bitcoin/pull/1526

Result

Block number 227,835 (timestamp 2013-03-24 15:49:13 GMT) was the last version 1 block.

Questions about BIP 34

What is BIP 34?

BIP 34, “Block v2, Height in Coinbase”, also known as block height in coinbase, is a specification Bitcoin Improvement Proposal written by Gavin Andresen and assigned in July 2012. 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 transactions, and set a pattern for rolling out later upgrades.

Is BIP 34 active?

Yes. BIP 34 has the status Deployed, which means it is live: adopted by the Bitcoin network or by widely used software. It activated on Bitcoin's main network at block 227,931 in March 2013.

Who wrote BIP 34?

BIP 34 was written by Gavin Andresen. Its number was assigned on July 6, 2012.

Which BIPs build on BIP 34?

4 other BIPs reference BIP 34: BIP 9 (Version bits with timeout and delay), BIP 22 (getblocktemplate - Fundamentals), BIP 123 (BIP Classification) and BIP 105 (Consensus based block size retargeting algorithm).

Where can I read the full BIP 34 specification?

The complete text of BIP 34 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 34

  • BIP 9: Version bits with timeout and delay: Deployed. Lets miners signal readiness for several soft forks (backward-compatible rule upgrades) at once by setting individual bits in each block's version number. An upgrade locks in once enough blocks…
  • 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 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 105: Consensus based block size retargeting algorithm: Closed. Proposed a mechanism for changing the maximum block size based on votes or consensus among network participants rather than a fixed number. It aimed to let the limit adapt over time without repeated…

Learn more

Guides

Glossary

Related proposals

  • BIP 30: Duplicate transactions: Deployed. 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…
  • 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 54: Consensus Cleanup: Complete. Bundles fixes for several long-standing protocol weaknesses: the timewarp attack (manipulating block timestamps to speed up coin issuance), blocks that take extremely long to validate, Merkle tree…
  • BIP 62: Dealing with malleability: Closed. Proposed a set of rules to stop third parties from altering a transaction's ID without changing what it does, a problem called malleability. It was withdrawn after Segregated Witness (SegWit) solved…
  • BIP 65: OP_CHECKLOCKTIMEVERIFY: Deployed. Adds OP_CHECKLOCKTIMEVERIFY, a script command that keeps coins unspendable until a chosen date or block height. It enables time-locked savings, escrow with deadlines, and payment channels such as…