Version

The version is the first field of every Pearl header: 4 bytes holding a number.

In Bitcoin, that number is how miners vote for upgrades. Pearl copied the format along with the rest of Bitcoin’s header, but it never uses it for anything. No rule checks it, and none of Pearl’s upgrades was voted in this way.

So this page is short, and mostly a history lesson. It’s still worth knowing, because explorers show the version on every block, and one stretch of Pearl’s history has an odd value that looks meaningful but isn’t.

Try it

The converter starts at 536,870,912, which is 0x20000000. Look at its 4 bytes in little-endian order: they’re the first 4 bytes of almost every Pearl header.

What does it look like?

Size

4 bytes

Type

Signed integer (int32)

Format

Little-endian

Range

Any value; not checked

Block 130,827’s header starts with 00 00 00 20. Integers are stored little-endian, smallest byte first, so you read the bytes backwards: 20 00 00 00, the number 0x20000000 (536,870,912 in decimal).

Pearl’s chain has used three values:

Why 0x20000000?

Because of Bitcoin’s version bits scheme, BIP 9. Written in binary, the version splits into two parts:

• The top three bits are 001. That says “this block uses version bits”. It’s what makes every version start with hex digit 2.
• The other 29 bits are signals. Each proposed upgrade (a deployment) is given one bit. A miner who supports it sets that bit. If enough blocks in a 2,016-block window signal, the upgrade locks in.

With no signals set, you get exactly 0x20000000. Pearl’s node builds every block template’s version this way, starting from those top bits and adding the bit of any deployment currently being voted on.

What was 0x20400000 about?

For most of Pearl’s first 100,000 blocks, the version was 0x20400000: the same number plus bit 22. It looked like a vote for something. It wasn’t, really.

Pearl’s mainnet settings define only three deployments, all test dummies left in from the btcd code Pearl is built on, on bits 28, 22 and 30. Nothing in the code depends on any of them. The bit-22 dummy is a “speedy trial” deployment that can only activate after block 100,000.

The chain data fits this story, though the exact history is an inference, not something the code records. The dummy was switched on soon after launch, so templates set bit 22 from roughly block 2,100. It then locked in and waited for its minimum height. It became active at block 100,800, the first 2,016-block boundary after 100,000. Once active, a deployment stops being signalled, so templates went back to plain 0x20000000.

The bit never had any consensus effect.

Does anything check the version?

No. Pearl’s node has an error code for “block version too old”, inherited from btcd, but the block validation code never raises it. As far as Pearl’s consensus rules go, the version can be any 4 bytes.

That makes the version a rare thing in a Pearl header: data that is hashed into the block’s ID, but means nothing.

How does Pearl upgrade instead?

At fixed heights, written into the node software. Each fork switches on at a set block number, and the two hard forks also changed the certificate version that blocks must carry:

vbTopBits = 0x20000000

expectedVersion := uint32(vbTopBits)
for id := 0; id < len(b.chainParams.Deployments); id++ {
	deployment := &b.chainParams.Deployments[id]
	state, err := b.thresholdState(prevNode, checker, cache)
	if state == ThresholdStarted || state == ThresholdLockedIn {
		expectedVersion |= uint32(1) << deployment.BitNumber
	}
}