Design Bitcoin

Expert45 min
1 / 30
understanding9 min read

Problem Statement: Bitcoin as a Permissionless Ledger

Problem Statement: Bitcoin as a Permissionless Ledger — Bitcoin system design interview depth

Bitcoin as a Permissionless Ledger

Bitcoin is a replicated, append-only ledger that lets mutually distrusting strangers agree on who owns what — without a bank, a clearing house, or any central operator who can be subpoenaed, bribed, or taken offline. That one sentence hides every hard problem in the system. There is no admin to authorize a payment, so authorization becomes a digital signature. There is no master database, so the database is replicated in full onto roughly 17,000 independent machines that must converge on identical state. And there is no trusted clock, so the question of which transaction came first is settled by burning electricity rather than by a timestamp anyone could forge.

At its core the design rests on three load-bearing ideas, and the interviewer is listening for whether you can name them precisely. First, ownership is modeled as UTXOs — unspent transaction outputs — not account balances. A coin is a specific output identified by (txid, vout); you spend it by referencing it and signing over it, which destroys it and creates new outputs in its place. Nothing is mutated in place, which is exactly what makes the ledger cheap to verify in parallel and hard to double-spend. Second, the canonical history is chosen by proof-of-work: the valid chain is the one with the most cumulative work — not the most blocks, and never the newest timestamp. Third, transactions and blocks spread by gossip across a flat peer-to-peer mesh, so there is no coordinator whose failure can halt the network.

The task here is not to reinvent cryptography. It is to design the node software and the infrastructure around it — the components that ingest transactions, validate them against consensus rules, propagate them, assemble candidate blocks, and serve queries — at a scale where being wrong by a single satoshi, or accepting one invalid block, is a protocol failure rather than a bug ticket. Concretely we size for roughly 400k transactions/day, a ~600 GB archival chain growing ~50 GB/year, a mempool capped near 300 MB, and merchants who wait six confirmations (about 60 minutes) before treating a large payment as final.

This question separates strong candidates because Bitcoin punishes hand-waving. "It is decentralized" is not a design. What earns signal is precision: strong consistency on the UTXO set the moment a block connects, eventual consistency on propagation across the gossip layer, and a concrete failure story — a chain reorg rewinding the UTXO view, or an eclipse attack feeding a victim a counterfeit chain — that shows you treat the system as something that fails and recovers, not a diagram that only runs forward.

Key Highlights

  • UTXO model: outputs spent once; no account balances mutated in place
  • Proof-of-work chain tip chosen by cumulative work, not timestamp
  • P2P gossip for tx/block propagation without central coordinator
  • Fixed monetary policy: 21M cap, halving schedule, fee market for block space
Staff+ signal
Open with the UTXO-versus-account distinction and a number — 400k tx/day, a 600 GB chain. Anchoring on measurable chain state instead of the word 'decentralized' is the fastest way to signal you have actually run a node, not just read about one.
Avoid this
Calling Bitcoin an account-balance database or ignoring reorg/UTXO rewind.

Section Rescue Kit

Buzzwords to use:

UTXOProof-of-Work

Safe statements:

  • "For Problem Statement: Bitcoin as a Permissionless Ledger, I'll separate mempool policy from consensus validation."
  • "Let me quantify tx/s and UTXO disk before picking cloud SKUs."
Design Bitcoin - System Design | WinJob | WinJob