Bitcoin in Practice: Blocks
By Kurt Wuckert Jr.
Blocks
When people say “blockchain,” they usually mean a public ledger that keeps growing over time. The growth happens in chunks called blocks. Each block is a container that holds a batch of transactions, and it links to the block before it using cryptography. That link is what turns a pile of blocks into a chain.
A simple way to remember it is this: the chain is written forward as new blocks are added, but you can always read it backward because every block points to its parent.
Block Structure
A block has two big parts:
Transactions, the actual list of events being recorded.
A block header, a compact summary that identifies the block and ties it to the chain.
The header is where the “glue” lives. It includes the previous block’s ID, which is how the chain stays continuous.
What’s in the Block Header
Here are the main fields you’ll see in a Bitcoin block header, and what they do:
Version: A 4-byte, little-endian value that signals which version of the Bitcoin protocol rules the block is being published under.
Previous Block Hash: A 32-byte, little-endian value that is the double SHA-256 hash of the previous block’s header. This is the pointer that links blocks together.
Merkle Root: A single hash that commits to all the transactions in the block. Change any transaction, and the Merkle Root changes.
Timestamp: A 4-byte Unix epoch time value. Network policy allows it to be “close enough,” within a couple hours of the validating node’s local time, and it has 1-second precision.
Bits (Difficulty): A 4-byte field encoding the proof-of-work difficulty target under the network rules.
Nonce: A 4-byte “number used once” that miners vary during proof-of-work to search for a valid block hash.
This header is small, but it represents the identity of the whole block. It is the summary that miners grind on and nodes verify.
Merkle Tree
Inside the block, transactions are organized into a structure called a Merkle Tree, which is a kind of hash tree. The key idea is that you can take a lot of individual pieces of data and roll them up into one final fingerprint called the Merkle Root.
Here’s the flow:
Start with the transactions.
Hash each transaction to get a transaction ID. These hashes are the leaf nodes at the bottom of the tree.
Pair up leaf hashes in order, concatenate each pair, then hash the result. Those become the next layer up.
Repeat that pairing and hashing step layer by layer until there is one hash left at the top. That final value is the Merkle Root.
So you can think of it like compressing a long list into a single tamper-evident seal. If any transaction changes, its hash changes. That change cascades upward, and the Merkle Root comes out completely different.
Odd Number of Transactions
Merkle trees usually combine hashes in pairs. So what happens if there’s an odd number of transactions at some level?
The common approach is to duplicate the last hash so there’s an even count. For example, if you have three transactions at the leaf layer, you end up pairing hash3 with itself to create the final pair at that level.
Merkle Proofs
A Merkle tree is not just about compression. It’s also about efficient proof.
If you want to prove that a specific transaction is included in a block, you do not need every transaction in the block. You only need:
The transaction’s hash (the leaf), and
The “neighbor” hashes required to rebuild the path up to the Merkle Root.
That set of required hashes is called a Merkle proof. With it, someone can recompute the Merkle Root and check that it matches the Merkle Root in the block header. If it matches, the transaction is included. If it doesn’t, it isn’t.
Hash Functions
All of this depends on cryptographic hash functions.
A hash function takes an input of any size and produces an output of fixed size. In Bitcoin, SHA-256 is used heavily. The important properties highlighted here are:
It’s one-way: easy to compute a hash from data, but infeasible to reconstruct the original data from the hash.
It’s sensitive: change even one character in the input, and the output hash changes drastically.
That sensitivity is what makes Merkle Roots so useful. The Merkle Root acts like a checksum for the entire transaction set, except it is cryptographic, not just a basic error check.
Public-Key Cryptography and Key Pairs
Another major building block in Bitcoin is the public-private key pair.
A public key is shared, and a private key is kept secret. Bitcoin uses these keys to control who can spend tokens. The practical pattern described here is:
Tokens are “locked” to a public key (or something derived from it, in common usage).
Only someone who has the corresponding private key can “unlock” and spend them.
One nuance worth keeping straight is the difference between possession and ownership. Ownership is a legal concept about rightful title. Possession, in the Bitcoin sense, is about control of the keys that can unlock the tokens under the rules encoded in the locking script.
Transfers Create New Locks
When tokens move in Bitcoin, the transfer creates new outputs. Those outputs specify new locking conditions, typically tied to the recipient’s public key (or a derived form). So each handoff creates a new “lock” that only the next holder can open with the matching private key.
That is how the ledger can show who can spend what, without needing a central authority to approve the update.
ELI5(ish...)
Think of Bitcoin like a huge public notebook where every page is a block. Each page has a list of receipts (transactions) plus a short summary at the top (the block header) that says, “This page comes after the last page.”
The header has a special fingerprint of the page before it, so nobody can secretly swap pages without everyone noticing. It also has a fingerprint of all the receipts on the page, made using a Merkle tree, which is basically a way to combine a bunch of small fingerprints into one big fingerprint. If you change even one receipt, the big fingerprint changes, and the page no longer matches.
A hash is that fingerprint. It is easy to make, but basically impossible to reverse.
And the “who can spend this money?” part is handled by keys. A public key is like your mailbox slot label, it can be public. A private key is like the only key that opens that mailbox. When someone sends you bitcoin, they lock it to your public key, and only your private key can unlock it later.