Skip to content
buybitcoinsmart

Glossary / Mining & consensus

Version 2 block

Also known as V2 block.

Definition
A version 2 block is a block whose header version field is 2, the upgrade that made BIP34 require the block's own height as the first item in its coinbase script.

Specified in BIP-34.

Block version numbers used to mean something simple: 1 was the original format, 2 added a rule, and each new number made the older format unmineable. Version 2 arrived with BIP34 and Bitcoin Core enforces it from block 227,931 onward. Nothing you do as a buyer depends on it, but every explorer displays it, and it explains why coinbase scripts begin with a number.

How it works

Status: the version field stopped being a counter in 2016, when BIP9 redefined its upper bits as a signalling bitfield, so a modern block shows a value such as 0x20000000 rather than 2, 3, or 4. The BIP34 rule that version 2 introduced is permanent and still checked on every block.

Version 2 blocks exist to solve a duplicate identity problem. A coinbase transaction has no inputs to make it unique, so two miners who happened to use the same output script and the same arbitrary coinbase bytes could produce byte identical transactions with the same transaction id. That is not hypothetical: blocks 91,842 and 91,880 each contained a coinbase transaction identical to one from an earlier block, and the later copy overwrote the earlier entry in the unspent output set, destroying spendable coins. BIP30 banned duplicates outright as a stopgap, and BIP34 removed the possibility at the source.

The mechanism is small. A version 2 block must start its coinbase script with the block's own height, written as a minimally encoded script number. Since no two blocks share a height, no two coinbase transactions can ever collide again. Deployment used a threshold rather than a flag day: once a supermajority of recent blocks carried version 2, version 1 blocks became invalid, and the network passed that point in March 2013.

The same pattern ran twice more. Version 3 blocks made strict DER signature encoding mandatory at block 363,725, and version 4 blocks brought OP_CHECKLOCKTIMEVERIFY at block 388,381. After that the sequence stopped, because treating a 32 bit field as a counter wasted 31 bits that BIP9 turned into parallel upgrade signals.

Where you see it

The version appears on any explorer's block page and in the getblock RPC as both version and versionHex. Look at a block from 2011 and you see 1; look at one from mid 2013 and you see 2; look at one from today and you see a bitfield.

The BIP34 height is easier to spot than the version itself. Decode any recent coinbase script and the first bytes are the height, usually followed by a pool's identifying text and the extra nonce space mining hardware iterates through. Explorers often print that tail as ASCII, which is how the coinbase of a block reveals which pool mined it.

Version 2 block vs version 2 transaction

A version 2 block and a version 2 transaction share a number and nothing else. Transaction version 2 comes from BIP68 and switches on relative locktimes, letting an input require that its parent output be a given age before it can be spent. Lightning depends on it for channel timeouts. Block version 2 comes from BIP34 and concerns coinbase uniqueness. Different object, different BIP, different year, and no relationship beyond the coincidence of both counters reaching 2.

Not to be confused with

Frequently asked questions

What block version does bitcoin use now?

None in the old counting sense. Since BIP9 the version field is a bitfield used to signal upgrade support, so blocks report values such as 0x20000000 instead of a sequential number.

Why does a coinbase script start with a number?

Because BIP34 requires the block height there. It guarantees that no two coinbase transactions are ever byte identical, which had already caused two duplicate transaction ids in 2010.

Related terms

More in Mining & consensus