Block

A block is a container for transactions.

At the top of every block is a block header, which summarizes all of the data inside in the block. This contains a fingerprint (merkle root) of all the transactions in the block, as well as a reference to a previous block.

Miners repeatedly hash this block header to try and get a result below the current target. If you can get a block hash below the target, the block can be added on to the blockchain. This process is called mining.

Newly mined blocks get sent between nodes on the bitcoin network, and are permanently stored on disk as part of the blockchain.

Example

This following is the raw block data for the genesis block. I've split up and highlighted the individual fields:

01000000 0000000000000000000000000000000000000000000000000000000000000000 3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a 29ab5f49 ffff001d 1dac2b7c 01 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

This block only contains one transaction, but the basic structure is the same for every block.

You may have noticed that the previous block hash for the genesis block is all zeros. This is because there are no blocks before it.

Structure

Note: Rows in highlighted in gray are part of the block header.

Block Header

Every raw block begins with a block header. It contains a summary of the block's contents, and is used when creating the block hash.

Version

• Size: 4 bytes
• Type: signed integer / bit field
• Format: little-endian
• Example: 00000020 (i.e. 0x20000000 in little-endian)

The version field is used to signal for upgrades to Bitcoin.

It was originally just a simple integer that marked an update to block structure after a soft fork, but now it's used by miners as a way to vote for upgrades to the software.

Previous Block

• Size: 32 bytes
• Type: plain bytes
• Format: natural byte order
• Current Tip: 00000000000000000001afbae6620aafab7ff926cd2af369e76dfff53b89c5ba (27 Apr 2024, 05:44:57) (this block hash is in natural byte order)

The previous block field contains the hash of an existing block, which is what the current block builds upon.

All miners want to extend the longest chain of blocks. This is because the longest chain of blocks is what all nodes adopt as the "correct" blockchain. So by adding a block to the "correct" chain, the miner will be able to collect the block reward if they're able to successfully mine their block.

If you built upon a block lower down in the chain, your block would not be part of the longest chain, so you would not be able to collect the block reward, and you efforts for mining the block would be wasted.

So in other words, when you create a new block, the previous block field contains the block hash of the block that's currently on the top of the blockchain (aka the "tip").

This previous block field in the block header is what connects blocks together in a chain, hence the term "block chain".

Merkle Root

• Size: 32 bytes
• Type: plain bytes
• Format: natural byte order
• Example: 160089f31ea9e90b602091310f463eb90ba4a988d44adb99e81e423d5405feca (this is in natural byte order)

The merkle root field contains a fingerprint for all the transaction data inside in the block.

You create a merkle root by hashing all of the transaction IDs together in pairs in a tree-like structure, until you end up with a single hash at the end. So the merkle root is ultimately a hash of the transaction data inside the block.

The merkle root prevents the block contents from being changed by someone else. All of the transaction data in the block gets "committed" to the block header via the merkle root, so if any transactions inside the block get modified at a later date, the merkle root will no longer match the contents of the block (and the block will be invalid).

So the merkle root is like putting a tamper-resistant seal on the block.

Time

• Size: 4 bytes
• Type: unsigned integer
• Format: little-endian
• Current Example: 17912c66 (i.e. 1714196759 or 0x662c9117)

The time field contains the time the block was constructed as a Unix timestamp.

This time does not have to be exact; it's just a rough indicator of when the block was constructed by the miner. However, the time in the block header must be within two hours either side of the median network time for nodes to accept the block as valid.

So it's possible that block higher up in the chain could have an earlier time than a block lower down in the chain. It doesn't matter though because the time field is not critical to the order of blocks.

Bits

• Size: 4 bytes
• Current Example: 170331db

The bits field is compact representation of the target at the time the block was mined.

Every block needs to get below a specific target value for it to be considered valid (i.e. for it to get added on to the blockchain). But instead of storing the full 32-byte target value in the block header, we use the compact 4-byte "bits" encoding instead.

The basic format of the bits field is:

• The last 3 bytes contain the rough precision of the full target.
• The first byte indicates "how many bytes to the left" those 3 bytes sit in a full 32-byte field.

I don't know why this field is named "bits". It's a confusing name seeing as we already have the terms bits for measurements of data (i.e. 8 bits in a byte), but that's what it's called anyway.

This compact representation of the target is the actual value the block hash needs to get below when mining. The full target itself does have more precision when it's initially calculated, but this compact bits field with lower precision is the actual threshold the block hash needs to get below.

Nonce

• Size: 4 bytes
• Type: unsigned integer
• Format: little-endian
• Example: 00000000

This field is short for "number used once". It's basically a spare field in block header that you can increment to get different hash results for the block header.

I like to call it the "mining field".

So when you're trying to mine a block, instead of having to reconstruct the entire block for every attempt, you can just increment the nonce field and get a completely different hash result for the same block of transactions.

Every block you see in the blockchain shows the "magic" nonce value that just so happened to produce a block hash that was below the target at the time. There is no skill to finding the right nonce; it's just about trying different nonces as fast as you can and hoping to get lucky.

Transactions

After the block header we have the actual transaction data. This is just a series of transactions one after the other.

Transaction Count

• Size: variable
• Type: compact size
• Example: 01

The first piece of data after the block header is actually a transaction count indicating the number of upcoming transactions in the block. It's a compact size field, so it's usually either 1 or 3 bytes in size (depending on how many transactions are in the block).

Coinbase Transaction

The first transaction in every block is the coinbase transaction. This is a special transaction that miners place inside the block to collect the block reward (block subsidy + transaction fees).

The main technical difference between a coinbase transaction and a "regular" transaction is that a coinbase transaction doesn't "spend" any existing bitcoins. Instead, the input to a coinbase transaction is blank (all zeros), and the amount of the output is the value of the block reward.

A coinbase transaction is a requirement for every block. Without one the block would be invalid.

Miner's often put custom signatures and messages in the scriptsig of their coinbase transaction. This is because a coinbase transaction doesn't need to unlock any existing coins, so miners are free to put any kind of data they like in to the scriptsig.

Regular Transactions

Following the coinbase transaction we have all the "regular" transactions, concatenated one after the other.

These transactions are selected from the memory pool when the miner constructs the block. A miner can include as many or as few transactions in their block as they like (up to the block size limit). However, miners are incentivized to include as many transactions as they can so that they can maximize the amount they can earn if they are successful in mining the block.

Miners are responsible for checking that each transaction in their block must be valid, otherwise the entire block will be considered invalid and cannot be added to the blockchain.

Parent transactions must always come before child transactions in a block. So if a transaction spends an output, that output must have been created by a transaction in a previous block or earlier on in the same block.

Block Hash

A block hash is created by double-SHA256'ing the block header. The block hash is a unique identifier for a block, which has two benefits:

• The block hash can be used for referencing a previous block to build on, which is what chains the blocks together.
• The block hash can be used for looking up a block in a block explorer.

The block hash is in reverse byte order when searching for a block in a block explorer.

And as mentioned, during the process of mining the block hash must get below the current target for the block to get added on to the blockchain. That's why all block hashes start with a bunch of zeros.

Weight

What is the maximum size of a block?

A block has a maximum capacity of 4,000,000 weight units.

• The block header is a fixed size of 320 weight units (80 bytes).
• Each transaction then has its own weight, typically around 550-850 weight units each (but this can vary significantly).

Location

Where can you find raw block data?

If you're running a Bitcoin Core node, the raw block data for the blockchain is stored in the blkXXXXX.dat files in the blocks/ directory:

Linux:   ~/.bitcoin/blocks/
Mac:     ~/Library/Application Support/Bitcoin/blocks/
Windows: %APPDATA%\Bitcoin\blocks\

The blocks are stored in raw bytes, so you will need to use something like the hexdump command to be able to print them. This is the genesis block for example:

$ hexdump -C -s 8 -n 285 blk00000.dat

00000008  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000018  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000028  00 00 00 00 3b a3 ed fd  7a 7b 12 b2 7a c7 2c 3e  |....;...z{..z.,>|
00000038  67 76 8f 61 7f c8 1b c3  88 8a 51 32 3a 9f b8 aa  |gv.a......Q2:...|
00000048  4b 1e 5e 4a 29 ab 5f 49  ff ff 00 1d 1d ac 2b 7c  |K.^J}._I......+||
00000058  01 01 00 00 00 01 00 00  00 00 00 00 00 00 00 00  |................|
00000068  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000078  00 00 00 00 00 00 ff ff  ff ff 4d 04 ff ff 00 1d  |..........M.....|
00000088  01 04 45 54 68 65 20 54  69 6d 65 73 20 30 33 2f  |..EThe Times 03/|
00000098  4a 61 6e 2f 32 30 30 39  20 43 68 61 6e 63 65 6c  |Jan/2009 Chancel|
000000a8  6c 6f 72 20 6f 6e 20 62  72 69 6e 6b 20 6f 66 20  |lor on brink of |
000000b8  73 65 63 6f 6e 64 20 62  61 69 6c 6f 75 74 20 66  |second bailout f|
000000c8  6f 72 20 62 61 6e 6b 73  ff ff ff ff 01 00 f2 05  |or banks........|
000000d8  2a 01 00 00 00 43 41 04  67 8a fd b0 fe 55 48 27  |*....CA.g....UH'|
000000e8  19 67 f1 a6 71 30 b7 10  5c d6 a8 28 e0 39 09 a6  |.g..q0..\..(.9..|
000000f8  79 62 e0 ea 1f 61 de b6  49 f6 bc 3f 4c ef 38 c4  |yb...a..I..?L.8.|
00000108  f3 55 04 e5 1e c1 12 de  5c 38 4d f7 ba 0b 8d 57  |.U......\8M....W|
00000118  8a 4c 70 2b 6b f1 1d 5f  ac 00 00 00 00           |.Lp+k.._.....|)
0000125

More simply, you can request the same raw blocks from your local Bitcoin Core node using bitcoin-cli commands:

$ bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f false

0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

Alternatively, you can receive the latest blocks that have been mined by connecting to a node on the network.