What Is Nakamoto Consensus? How Bitcoin Solved the Byzantine Generals Problem

Picture thousands of computers spread across the world, run by strangers who have never met. Some are honest, some are buggy, and a few may be actively trying to cheat.

Somehow they all have to agree on a single list of payments, in the same order, without anyone in charge. That is the puzzle Bitcoin solved in 2009, and the method it uses is called Nakamoto consensus.

It is worth understanding because almost every argument about blockchains, from confirmation times to proof of stake, comes back to how a network reaches agreement and how final that agreement really is.

The Byzantine generals problem in plain terms

The puzzle has a name that predates Bitcoin by decades. In 1982, computer scientists Leslie Lamport, Robert Shostak and Marshall Pease published a paper called "The Byzantine Generals Problem."

They framed it as a story. Several divisions of an army surround a city, each led by a general who can only communicate with the others by messenger. They must all attack together or all retreat together. A half-hearted attack ends in defeat.

The catch is that some generals may be traitors. A traitor can tell one colleague "attack" and another "retreat," deliberately splitting the loyal generals into groups that act differently.

The question is whether the loyal generals can still agree on one plan. The paper showed that with ordinary messages, agreement is only guaranteed if more than two thirds of the generals are loyal. Put another way, tolerating f traitors needs at least 3f + 1 participants in total.

What Byzantine fault tolerance means

In computing, a "Byzantine" fault is the worst kind of failure. A machine does not just crash or go quiet; it may send wrong, contradictory or deliberately misleading information.

A system that keeps working correctly despite some participants behaving this way is called Byzantine fault tolerant, or BFT. Aircraft control systems and other safety-critical machines were early users of the idea.

Practical BFT protocols arrived later. Miguel Castro and Barbara Liskov's PBFT, published in 1999, showed that replicated servers could tolerate Byzantine faults efficiently enough for real use.

There was a limitation, though. Classic BFT assumes a known, fixed list of participants. Everyone knows who the generals are and can count votes. An open network where anyone can join anonymously breaks that assumption, because one attacker could simply spin up thousands of fake identities and win every vote.

How Nakamoto consensus works

Bitcoin's white paper, published by Satoshi Nakamoto in October 2008, sidestepped the identity problem. Instead of counting votes per participant, the network effectively counts computing power.

Here is the basic loop:

• Miners collect pending transactions into a candidate block.
• To publish that block, a miner must find a hash below a target, which takes enormous numbers of guesses. This is proof of work.
• When a valid block is found, it is broadcast, and other nodes check it and add it to their copy of the chain.
• Miners then start building on top of the newest block they consider valid.

The final rule is the one that does the agreeing. When nodes see competing versions of history, they follow the valid chain with the most accumulated proof of work, often loosely called the longest chain.

You do not need permission to mine, and you do not need to know who else is mining. Faking a thousand identities gains nothing, because what counts is real work, and real work costs electricity and hardware. Our guide to Bitcoin mining covers that side in more detail.

Shortly after releasing the white paper, Nakamoto wrote on the cryptography mailing list that the proof-of-work chain was a solution to the Byzantine generals problem. The generals no longer need to trust each other's messages; they only need to see which plan has the most work behind it.

Why blocks get orphaned

Because blocks propagate across the internet with small delays, two miners sometimes find valid blocks at nearly the same moment. For a short while, part of the network sees one block as the tip and part sees the other.

Nakamoto consensus resolves this without any vote. Miners keep building on whichever block they saw first. As soon as one branch gets the next block, it holds more work, and every honest node switches to it.

The losing block is dropped. It is commonly called an orphan block, though developers often prefer the more precise term stale block. Its miner loses the block reward, and any transactions it contained that are not in the winning branch go back to waiting.

This is also why one confirmation is not treated as permanent. A payment in a block that later goes stale has, for a moment, appeared confirmed and then not.

Bitcoin targets one block roughly every ten minutes and adjusts mining difficulty every 2,016 blocks. That spacing is long compared with the time blocks take to spread, which keeps stale blocks relatively rare.

Blockchain finality: probabilistic vs. absolute

Finality is the point at which a transaction can no longer be reversed. Nakamoto consensus offers what is called probabilistic finality.

Every new block on top of yours makes reversal harder, because an attacker would need to redo all that work and then overtake the honest chain. The Bitcoin white paper calculates that the attacker's odds fall exponentially as blocks pile up, as long as they control less than half of the hash power.

That is where the familiar rule of thumb of waiting for six confirmations comes from. It is a convention, not a protocol rule, and many services accept fewer for small amounts.

The guarantee does not hold against an attacker with majority hash power, which is how smaller proof-of-work coins have suffered reorganizations. We cover those incidents in our explainer on the double spend problem and 51% attacks.

Classic BFT protocols work differently. Once a block gathers votes from more than two thirds of the known validators, it is final immediately, with no waiting period and no chance of an ordinary reorganization.

Safety vs. liveness: the real trade-off

The two families of consensus make opposite choices when the network misbehaves.

Nakamoto consensus favors liveness. If the network splits or many miners go offline, blocks keep coming on every side. The cost is that history might later be rewritten when the sides reconnect.

BFT-style systems favor safety. Networks built on Tendermint, now maintained as CometBFT, finalize each block in one round of voting. If more than a third of validators go offline, the chain stops producing blocks rather than risk two conflicting histories.

Neither choice is simply better. A payments network that occasionally pauses behaves very differently from one that never pauses but can, rarely, reshuffle recent blocks.

How proof of stake blends the two

Ethereum's move to proof of stake in 2022 combined ideas from both camps.

New blocks are proposed every 12-second slot, and the chain keeps growing much like a longest-chain system. On top of that sits a finality layer called Casper FFG. When validators holding at least two thirds of the staked ETH attest to checkpoints, those checkpoints become finalized, which normally takes about two epochs, or roughly 13 minutes.

Reversing a finalized block would require at least a third of all staked ETH to break the rules in a provable way, and that stake would be slashed. Instead of counting electricity, the system makes attacks expensive by putting capital at risk. Our comparison of proof of work vs. proof of stake goes deeper into those economics.

Weak spots worth knowing

Nakamoto consensus rests on an honest majority of hash power. Concentration in a few large mining pools is therefore a recurring concern, even if pools are made up of many individual miners who can switch.

Researchers have also shown that the incentives are not perfectly tight. In a 2013 paper, Ittay Eyal and Emin Gün Sirer described "selfish mining," a strategy in which a well-connected minority miner withholds blocks to earn more than its fair share.

Finally, probabilistic finality is a poor fit for applications that need instant certainty. That is one reason exchanges wait for multiple confirmations on deposits and why many newer chains chose BFT-style designs.

Why it still matters

Before 2009, the Byzantine generals problem had good solutions only for closed groups whose members were known in advance. Nakamoto consensus showed that strangers on an open network could agree, provided agreement was tied to something costly to fake.

When you look at any blockchain, the useful questions follow directly from that idea. Who gets to add blocks, what does cheating cost, and when is a transaction truly final?

The answers explain far more about a network's security than its marketing ever will.