BIP 34
Block v2, Height in Coinbase
Original title: Block v2, Height in Coinbase
- Status
- Deployed
- Type / Layer
- Specification / Consensus (soft fork)
- Author
- Gavin Andresen
- Assigned
- Status verified
- Source
- github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
Summary
Introduces version numbers for blocks and transactions as an upgrade path for future structural changes, and requires the coinbase transaction to carry the block's own height as the first item of its scriptSig. Two goals are stated. One is to have a mechanism by which the network can agree to change these structures at all. The other is to make every block unique: with identical coinbase contents the same coinbase transaction id could appear twice, which cannot happen once a distinct height is embedded. It also helps validate blocks received while disconnected from the chain, since the height can be read from the block itself. The height is encoded as a minimally encoded CScript — one length byte followed by the value in little-endian, counting the genesis block as zero. Deployment used two thresholds over a 1000-block window: once 750 blocks were version 2 or higher, invalid version 2 blocks were rejected; once 950 were, version 1 blocks were rejected outright.
Why it matters
It is the origin of deploying soft forks through block version numbers — the idea BIP9 later generalised into parallel deployments. The height in the coinbase is still present in every block, and the property that a block states its own height is relied on routinely in validation and indexing.
Related BIPs
Related articles
This page carries a summary, not a translation. The original document is authoritative, and the metadata above — including Status — was transcribed from the bips repository on the verification date shown. Always consult the original when implementing or verifying.