Height

Blocks are numbered in the order they were added. The first block, the genesis block, is number 0. Its child is 1, the next is 2, and so on. That number is the block’s height.

It’s the simplest idea in this codex, but a lot of rules hang on it: how many coins a block may create, which version of the rules applies, when mined coins can move.

Try it

The live tip of Pearl’s chain: its height, difficulty and pace.

Pearl, right now

Snapshot from Oct 20, 2026 · asking PRLScan…

Block height: 130,827
Difficulty: 40.16M
Avg block time · 144: 174.3s
Network rate: 64.9EMAC/s

Time between the last 20 blocks — 194 s target

Loading recent blocks…

Blocks arrive at random: gaps of a few seconds and of ten minutes are both normal. The average is what difficulty steers toward 194 s.

Network rate counts multiply-accumulates per second, not hashes PRLScan · refreshes every minute while visible

Where is the height stored?

Not in the header. Pearl’s 108-byte header has a version, the previous block’s hash, a Merkle root, a time, bits and a proof commitment. No height.

A node doesn’t need one there. It knows each block’s parent from the previous-block link, so it knows the parent’s height, and the child’s height is one more. Counting from genesis, every block’s height follows.

On 20 October 2026, the snapshot used across this site was taken at height 130,827. Right now the tip is 130,827.

Then why is it in the coinbase?

Because of an old Bitcoin bug. Two coinbase transactions with identical contents would have identical txids, and two outputs with the same name confuse the ledger. Bitcoin fixed this with BIP-34: the coinbase’s scriptSig must begin with the block height, so every coinbase is different.

Pearl enforces BIP-34 in every block from block 1. Here is block 1’s coinbase:

Coinbase of block 1 193 bytes

01000000 00 01 01 0000000000000000000000000000000000000000000000000000000000000000 ffffffff 10 51000d2f503253482f706561726c642f ffffffff 02 af9829324b000000 22 512054ff8eb1b3102b0f9517d00aa5f3d3c8a6253535c70d44e8fcdd83d0d9b1bf6a 0000000000000000 26 6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9 01 20 0000000000000000000000000000000000000000000000000000000000000000 00000000

Hover or focus the bytes to name each field Version bytes 0–3 1 Marker bytes 4 0x00 Flag bytes 5 0x01 Input count bytes 6 1 Previous txid bytes 7–38 0000000000000000000000000000000000000000000000000000000000000000 Output index bytes 39–42 0xffffffff scriptSig length bytes 43 16 Coinbase script bytes 44–59 51000d2f503253482f706561726c642f Sequence bytes 60–63 0xffffffff Output count bytes 64 2 Amount bytes 65–72 322,964,134,063 grains (3229.64134063 PRL) Script length bytes 73 34 Locking script bytes 74–107 prl1p2nlcavdnzq4sl9gh6q92tu7neznz2df4cux5f68umkpapkd3ha4qlknklv Amount bytes 108–115 0 grains (0.00000000 PRL) Script length bytes 116 38 Locking script bytes 117–154 witness commitment e2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9 Witness items bytes 155 1 Witness reserved value length bytes 156 32 Witness reserved value bytes 157–188 0000000000000000000000000000000000000000000000000000000000000000 Locktime bytes 189–192 0

Field	Bytes	Value
Version version	4 @0	1 int32 little-endian. Pearl wallets and pearld coinbases use version 1; relay policy accepts 1-2.
Marker marker	1 @4	0x00 Segwit marker (BIP-144): says witness data follows the outputs.
Flag flag	1 @5	0x01 Witness flag; 0x01 is the only value Pearl accepts.
Input count vin.length	1 @6	1 CompactSize number of inputs.
Previous txid vin[0].txid	32 @7	0000000000000000000000000000000000000000000000000000000000000000 All zeros: this input creates new coins (coinbase).
Output index vin[0].vout	4 @39	0xffffffff 0xffffffff together with a zero txid marks a coinbase.
scriptSig length vin[0].scriptSig.length	1 @43	16 CompactSize length of the scriptSig.
Coinbase script vin[0].scriptSig	16 @44	51000d2f503253482f706561726c642f Coinbase data. It starts with the block height 1 (BIP-34, required in every Pearl block), then anything the miner likes.
Sequence vin[0].sequence	4 @60	0xffffffff Final (0xffffffff): no RBF signal, no relative locktime, and locktime is ignored for this input. Pearl wallets use this.
Output count vout.length	1 @64	2 CompactSize number of outputs.
Amount vout[0].value	8 @65	322,964,134,063 grains (3229.64134063 PRL) int64 little-endian, in grains (1 PRL = 100,000,000 grains).
Script length vout[0].scriptPubKey.length	1 @73	34 CompactSize length of the locking script.
Locking script vout[0].scriptPubKey	34 @74	prl1p2nlcavdnzq4sl9gh6q92tu7neznz2df4cux5f68umkpapkd3ha4qlknklv OP_1 OP_PUSHBYTES_32 <output key Q>: a Taproot output.
Amount vout[1].value	8 @108	0 grains (0.00000000 PRL) int64 little-endian, in grains (1 PRL = 100,000,000 grains).
Script length vout[1].scriptPubKey.length	1 @116	38 CompactSize length of the locking script.
Locking script vout[1].scriptPubKey	38 @117	witness commitment e2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9 OP_RETURN aa21a9ed ‖ SHA256d(witness Merkle root ‖ nonce): the BIP-141 witness commitment.
Witness items witness[0].length	1 @155	1 Number of witness stack items for input 0.
Witness reserved value length witness[0][0].length	1 @156	32 CompactSize length of this witness item.
Witness reserved value witness[0][0]	32 @157	0000000000000000000000000000000000000000000000000000000000000000 The coinbase witness is one 32-byte value (the witness-commitment nonce); pearld uses zeros.
Locktime locktime	4 @189	0 0: no time lock.

txid: 36b18b26fba6b71149951d88904945c64137e74b250de8d76c4beded90560be2
Size: 193 bytes · 166 vbytes
Block: 1

Its scriptSig is 51 00 0d 2f503253482f706561726c642f. The first byte, 51, is OP_1: the number 1, block 1’s height. (Then OP_0, then the text “/P2SH/pearld/”.) Heights 1 to 16 use the one-byte opcodes OP_1 to OP_16.

Bigger heights are pushed as little-endian numbers. Block 130,825’s coinbase starts 03 09 ff 01: push 3 bytes, 09 ff 01, which read backwards is 0x01ff09 = 130,825.

What do the rules use the height for?

Many things. Here are the main ones:

Rule	How the height is used
Subsidy	The new-coin amount is computed from the height alone.
Forks	Each rule change starts at a fixed height: 71,935, 91,630, 96,251, 99,000.
Checkpoints	Known block hashes at heights 10,000, 20,000, … 120,000.
Coinbase maturity	Mined coins can be spent at height h + 100 or later.
Lock times	A locktime below 500,000,000 is a height; relative locks can count blocks too.

Can two blocks have the same height?

Yes, briefly. If two miners each find a block on the same parent at about the same time, both blocks have the same height. Nodes eventually follow one branch and drop the other; see the most-work chain.

So a height alone doesn’t name a block. “Block 130,825 on the chain my node follows” does, and the block hash always does: 3fc85176…ee5533ae is block 130,825 and nothing else.

Your transaction’s block counts as one confirmation, and each block on top adds one:

\text{confirmations} = \text{tip height} - \text{block height} + 1

The deeper a block is, the more work an attacker would need to redo to replace it.

How fast do heights grow?

At the target pace of 194 seconds, about 445 blocks a day. On 20 October 2026 the chain was a little faster, about 514 blocks in the previous 24 hours, because blocks had averaged 174.3 seconds.

Make a guess

Heights are stored as 32-bit signed integers. How long until Pearl runs out?

Think of your answer first, then check it.

Answer About 13,211 years at 194 seconds a block.

The largest 32-bit signed integer is 2,147,483,647. At 194 seconds per block that’s 13,210.7 years of 365 days. Even there, the emission formula would still pay 29,591 grains per block.

Code: the BIP-34 check

In validate.go (node/blockchain/validate.go:783-787 at v1.5.2, on GitHub) the check runs for every block that is fully validated (it is skipped only when catching up below a checkpoint):

node/blockchain/validate.go Go

coinbaseTx := block.Transactions()[0]
// BIP-34 is enforced for all blocks; this validates correct height encoding.
if err := CheckSerializedHeight(coinbaseTx, blockHeight); err != nil {
	return err
}

CheckSerializedHeight (node/blockchain/validate.go:564-651 at v1.5.2, on GitHub) reads the first push of the scriptSig as a script number and compares it with the block’s height.