Block structure

A Bitcoin block is a container for transactions. At its top sits the block header, a fixed 80-byte summary of the whole block. Miners hash that header again and again, and a block counts only when its hash falls below the target. This page takes the header one field at a time, then the transactions that follow it.

For the plain definition, read the short page on what a block is first. Here you will see what a block holds, byte by byte.

What does a block contain?

Every block has the same three parts, in this order:

1. The block header, always 80 bytes.
2. The transaction count, a number that says how many transactions follow.
3. The transactions, one after another, starting with the coinbase transaction.

Only the header has a fixed size. The transactions part grows and shrinks with every block.

What are the six fields of the block header?

The header is six fields packed one after another with no gaps. Each field has its own page in this section.

Field	Size	Byte order	What it holds
Version	4 bytes	little-endian	Bits that signal support for upgrades
Previous block hash	32 bytes	natural	The hash of the block this one builds on
Merkle root	32 bytes	natural	A fingerprint of every transaction in the block
Time	4 bytes	little-endian	A Unix timestamp, set by the miner
Bits	4 bytes	little-endian	The target, in a compact form
Nonce	4 bytes	little-endian	A spare number that miners change to try new hashes

Add the sizes and you get 4 + 32 + 32 + 4 + 4 + 4 = 80 bytes.

Two terms come up often in this section. Little-endian means the least significant byte is stored first, so the number 1 in four bytes is 01000000. Natural byte order is the order in which a hash function outputs its bytes. Block explorers show hashes the other way round. Byte order and little-endian explain both.

What does a real block header look like?

Block 974,000 was mined on 31 October 2026. Its header is 160 hex characters, which is 80 bytes. Open the block at /block/974000 to see the same fields in our explorer.

These are the raw bytes, exactly as they sit in the header:

version       00c00820
previous      8042e76820f82d605498e609240e207b0d1559982ce800000000000000000000
merkle root   c1541910c988f1a6421f0a04ae5a053ac3e1f126f0f4c6738ff7c98a96513e0a
time          8721e66a
bits          ace50117
nonce         6f002e09

Decoded, the six fields say this:

• Version: 00c00820 in little-endian is 0x2008c000. The number is a bit field, so read it bit by bit (see version).
• Previous block hash: 00000000000000000000e82c9859150d7b200e2409e69854602df82068e74280, the hash of block 973,999.
• Merkle root: 0a3e51968ac9f78f73c6f4f026f1e1c33a055aae040a1f42a6f188c9101954c1, in explorer order.
• Time: 8721e66a is 1,793,466,759, which is 31 October 2026 at 17:12:39 UTC.
• Bits: ace50117 is 0x1701e5ac, the target in its compact form.
• Nonce: 6f002e09 is 154,009,711.

Hashing these 80 bytes gives the block hash, 00000000000000000000d7d13f5ac024052cad9613d9a6608f76df081d74e865. It starts with 20 zero hex digits, so it sits below the target. The block hash page shows how that hash is made.

How is the transaction count stored?

The count uses the compact size format. Small numbers take one byte, and bigger numbers take a marker byte followed by more bytes:

First byte	Bytes that follow	Numbers it covers
00 to fc	none, the byte is the number	0 to 252
fd	two bytes, little-endian	253 to 65,535
fe	four bytes, little-endian	65,536 to 4,294,967,295
ff	eight bytes, little-endian	larger than that

Block 974,000 holds 3,468 transactions, so its count is fd8c0d. The fd says two bytes follow, and 8c0d is 3,468 in little-endian. The genesis block holds one transaction, so its count is just 01.

What comes after the transaction count?

The transactions follow one after another with no separators. Their order matters:

• The coinbase transaction comes first. Its input points at no earlier output, and its outputs pay the miner the block reward, which is the new coins plus the fees. The subsidy has been 3.125 BTC per block since block 840,000, see halving.
• A transaction that spends an output must come after the transaction that created it. That earlier transaction sits in an earlier block, or earlier in the same block.
• Since block 227,931, the coinbase transaction must begin with the block height (BIP 34).
• Coinbase outputs cannot be spent until 100 blocks later. Bitcoin Core enforces this with a constant called COINBASE_MATURITY in its consensus code.

The miner picks the other transactions from the memory pool, the waiting room of transactions on the node.

Block size is counted in weight units. A block may hold up to 4,000,000 of them, as BIP 141 sets out. The header uses 320 units, because its 80 bytes count four times over. Block 974,000 weighs 3,994,804 units, close to that limit.

Where do the raw blocks live?

Your node keeps every block as raw bytes in blk*.dat files, in the blocks folder of its data directory. The blk.dat files page shows how a record is laid out and how to find it.

Which order should you read this section in?

Read the pages in the order the header lists its fields. Each page builds on the one before it.

1. Version: the bit field that signals upgrades.
2. Previous block: the hash that links one block to the next.
3. Merkle root: the fingerprint of the transactions.
4. Time: the timestamp and the rules that keep it honest.
5. Bits: the target in its compact form.
6. Nonce: the field miners change to search for a valid hash.
7. Block hash: the 80 bytes, hashed twice.
8. blk.dat files: the raw blocks on your disk.

Once the header makes sense, try it on the first block of all. Block 0, the genesis block, shows the same six fields with the simplest values you will find.