What Bitcoin's technology is not as important as cryptography, that's where signatures and hashing come in. The real innovation is that thousands of strangers, not organized by the central, concur that they share one history. In this post, we will go through the process of how that occurs: from a transaction in a mempool, to a validated block, to thousands of nodes coming together on the same chain.
From mempool to block
Each node keeps a personal mempool a holding area for transactions that it has received and validated, but not yet confirmed. A mining node periodically polls the mempool and attempts to assemble a block that can be added to the chain, and includes a special coinbase transaction that rewards the miner with the block reward (plus any fees attached to the transactions in the block). The vast majority of the nodes are not miners, but validators and relayers.
What's actually inside a block header
The header is designed to be small (only 80 bytes) so that it gets hashed over and over while being mined, and because it is what every other node has to check on a regular basis.
| Field | Size | Purpose |
|---|---|---|
| version | 4 bytes | signals which consensus rules this block follows |
| hashPrevBlock | 32 bytes | hash of the parent block — this is the actual "chain" link |
| hashMerkleRoot | 32 bytes | single hash representing every transaction in the block |
| timestamp | 4 bytes | seconds since and includes a special coinbase transaction that rewards the and includes a special coinbase transaction that rewards the the Unix epoch |
| bits (target) | 4 bytes | the difficulty target this block's hash must beat |
| nonce | 4 bytes | the number miners increment while searching for a valid hash |
The merkle root: proving inclusion cheaply
If each transaction was hashed directly into the header, it would be difficult to verify the headers and they would be large. Rather, transaction hashes are paired together, re-hashed, re-paired and re-hashed again and again and again, until a single 32-byte merkle root is left. That root is the hash of all the transactions in the block, but only a few hashes of intermediate transactions are necessary to prove that a particular transaction is part of the block (a "merkle proof"). This is how lightweight clients can verify a transaction is in the blockchain without having to download gigabytes of data.
hashPrevBlock: the actual chain
The one field that is 32 bytes long is what chains a pile of otherwise independent blocks together. Modify any value within a previous block, even one bit in one previous transaction, and they all have to be updated in subsequent blocks from the previous block, because the hash of the previous block will change. You don't have to do the "hard" thing when re-writing history, it's "the astronomical thing": you must redo the proof-of-work of that block, and basically redo the proof-of-work of the next block on top of it and all the subsequent blocks on top of that one.
Mining and proof-of-work
The "double-SHA256" hash of the block header is only valid if it is lower than the network-wide target. Its output is essentially a random number, so it takes a long time to find a hash that is less than the target, but once you find one it only takes one to verify it. That asymmetry – hard to create, easy to validate – is at the heart of it, and it makes it costly to send junk blocks through the network, while validating is cheap for everyone else.
The target adjusts automatically, every 2016 blocks (about 2 weeks at the intended 10 minutes/block rate), depending on the actual rate at which the blocks are being found. The more the number of participants (more hash power), the lower the target (harder), and the less the number of participants (less hash power), the higher the target (easier). This ensures constant production of blocks, even if miners log in or out.
The easiest possible target the network ever allowed divided by the present target is a common shorthand used here: difficulty. The starting point of difficulty 1 was the genesis difficulty; it's now many orders of magnitude greater, meaning that much more hashing power now is competing for each block.
How nodes agree without talking to a referee: Nakamoto consensus
Let's get to the pretty part. Every node constructs its own chain of blocks, simply based on the following rule: Always take the chain that has the longest valid chain with the most Proof-of-Work.
If two miners discover the same block at almost the same time, the network temporarily bifurcates, with some nodes discovering block A before block B, and mining on top of that, while the others discover block B before block A, and begin mining on top of block B. This is not a crisis as it will sort itself out when one of the two competing tips is extended by any miner. Each node then reevaluates, realizes that one chain is longer and moves to it, removing ("orphaning") the transactions from the losing chain back into its mempool for later re-evaluation.
A reorg of this kind occurs regularly (with the single-block reorgs, less than once per month) and is a normal and healthy process in how the network self-corrects. The more a transaction is buried in the subsequent blocks, the more computational effort an attacker would have to work to break the transaction — that's what “confirmations” represent. One confirmation means one block is added above the transaction, and six confirmations means six blocks are added above the transaction, placing a big barrier between the attacker and the ability to change the transaction.
This is also the theoretical basis behind the "51% attack" (which is largely theoretical, and economically self-defeating): in theory, if they have more than 50% of the network's hash power, they could be mining their own history while honest miners are on the other. The amount of hardware it would take to acquire and maintain that alone is why it is firmly in the "theoretically possible, but practically irrational" category.
Soft-forks and hard-forks, quickly
Upgrading a decentralized network without a central "update now" button requires care. The two failure modes:
- Soft-fork — new rules are a subset of the old rules. Old nodes still accept the new, stricter blocks (they just don't understand some of the extra restrictions), so the network stays in sync as long as enough hashing power adopts the change. Segregated Witness shipped this way, with considerable engineering effort to make a fairly invasive change backward-compatible.
- Hard-fork — new rules accept blocks the old rules would have rejected. Old and new nodes can no longer agree, and the network permanently splits into two unless everyone upgrades together.
Because hard-forks are disruptive and contentious, the Bitcoin community has strongly favored soft-forks for protocol changes, even when a hard-fork would have been the technically simpler path.
Types of nodes you'll encounter
A "full node" isn't one fixed thing — it's a bundle of optional roles:
- Routing/relay — propagates transactions and blocks to peers (almost every node does this).
- Archival — stores the entire blockchain from the genesis block forward. Some nodes opt to prune older block data to save disk space once it's been validated.
- Wallet — manages keys and lets the node's owner send/receive funds (optional; can be disabled).
- Mining — actually competes to produce new blocks. A small minority of nodes do this; the rest validate and relay what miners produce.
Summarizing
Remove the jargon and the consensus mechanism of bitcoin is summarized as follows: hash link blocks together, so blocks can be detected if they are tampered with, new blocks are expensive to create, making spam impractical, and each node independently agrees to follow the chain of blocks that has the most work put into it. No voting, no central authority; it is just a simple rule mechanically enforced by everyone who runs the software, and it is followed by everyone.
Top comments (1)
Great explanation! I especially liked the section on Nakamoto Consensus—it makes a complex idea much easier to understand. The analogy of nodes agreeing without a central authority really clicked for me.