Blog
The Byzantine Generals Problem

Dispatches from D47K

November 3, 2025

Posts and notes on trust, blockchains, and the messy history in between.

ConsensusFault toleranceSecurity

The problem in one sentence

How do many parties agree on a plan when some may lie, be offline, or try to sabotage the outcome? That’s the Byzantine Generals Problem. In blockchains, the “plan” is the next block; the liars are malicious or faulty nodes.

The crux: honest participants need a way to converge on one story, even if some mess with the messages. If they don’t, double-spend and censorship become easy.

Honest vs. faulty (illustrative)
Role Behavior Consensus impact
Honest node Follows rules, relays messages Helps convergence
Faulty node Offline or misconfigured May slow convergence
Malicious node Sends conflicting messages Attempts to fork/confuse
Goal: honest majority still lands on one history even if some shout noise.

Why it matters for money

If honest nodes can’t agree on the same ledger, attackers can double-spend or censor. The network needs a way for honest participants to converge even if some peers are malicious or sending conflicting messages.

Money without a referee only works if conflicting versions of history get resolved the same way everywhere. Consensus rules are the script; the network plays it out every block.

Classic BFT vs. open networks

Traditional Byzantine Fault Tolerance (BFT) assumes a known set of validators and can tolerate up to ~1/3 bad actors with fast finality. Great for permissioned systems; less suited to open, anonymous networks with unknown participants.

Open networks need sybil resistance: proof that a participant has skin in the game (work or stake) so one actor can’t spin up thousands of fake identities for free.

Classical BFT vs. open consensus
Aspect Classic BFT Open (PoW/PoS)
Validator set Known, fixed Open, permissionless
Fault tolerance ~1/3 by count Depends on hash/stake weight
Sybil resistance Identity/PKI Work or stake cost
Finality Fast (round-based) Probabilistic or economic

Proof-of-Work’s approach

PoW doesn’t ask nodes to vote; it asks them to burn energy. The longest (most work) valid chain wins. An attacker needs majority hashpower to consistently override honest miners. There’s no fixed validator list; sybil resistance comes from cost.

Proof-of-Stake’s approach

PoS bonds capital instead of energy. Validators propose and attest; misbehavior can be slashed. Finality gadgets let nodes agree that certain blocks are locked in. Sybil resistance comes from stake weight and economic penalties.

Faults and attacks

Eclipse: Isolate a node so it only sees attacker-controlled peers, feeding it a fake view. Mitigation: diverse peers, multiple connections, checkpoints.

Equivocation: A validator/miner builds conflicting blocks. PoW wastes their hashpower; PoS can slash equivocations if detected.

51%/finality attacks: Majority hashpower (PoW) or supermajority stake (PoS) can reorder recent history. Visible, expensive, and reputationally costly, but possible if control concentrates.

Attack surface (quick map)
Attack What it does Mitigation
Eclipse Isolate victim’s view Peer diversity, checkpoints
Equivocation Build conflicting blocks Waste (PoW) or slash (PoS)
51% / finality flip Reorg or censor Avoid concentration; make it costly

Finality and confidence

In PoW, more confirmations lower the probability of a successful reorg. In PoS with finality gadgets, finalized blocks require slashing to revert, making deep changes economically painful.

“Byzantine fault tolerance in the wild means honest nodes agree despite liars, because cheating costs real resources or gets you slashed.”
— On practical consensus

Limits to remember

No consensus is magic. If the majority of work or stake is malicious, they can misbehave—though they pay in energy or capital and leave evidence. Users rely on open verification, diverse peers, and, in PoS, honest checkpoints.