Bitcoin Whitepaper Explained

Definition

The paper targets the double-spending problem for online cash without relying on a mint, bank, or payment processor.

Example

• Without a shared ordering system, Alice can sign two valid-looking transactions that spend the same output to Bob and Carol.
• Bitcoin resolves this by making the network converge on one ordered history of transactions.

Do not overread

The whitepaper is not a full node implementation spec; it leaves networking, serialization, script details, and many consensus limits to later software and BIPs.

Design goals restored from the original blueprint

• Peer-to-peer: payments move directly between participants instead of through a financial intermediary.
• Cryptographic proof over trust: signatures prove authorization and proof-of-work makes history costly to rewrite.
• Public transaction order: the network needs one visible ordering so conflicting spends cannot both settle.
• Computational irreversibility: a recipient waits for confirmations until rewriting the payment is economically impractical for the payment value.
• Honest-majority assumption: security relies on honest nodes controlling more hash power than an attacker.

• Reversibility: merchants must price in fraud and chargebacks.
• Minimum practical size: mediation overhead makes tiny payments hard.
• Trust burden: buyers and sellers depend on a third party to adjudicate finality.

When not to use this model: If a transaction intentionally needs consumer dispute resolution, trusted mediation may be a feature rather than a defect.

Ownership and verification

• Definition: a recipient verifies the chain of signatures back to an unspent prior output and checks that the spender can satisfy the locking condition.
• Example: if Alice pays Bob, Alice signs a digest committing to the previous output and Bob's receiving condition; Bob can verify the signature against Alice's public key.
• Limit: signature verification proves authorization, not uniqueness. Bob still needs the network's ordering mechanism to know Alice did not also spend the same input elsewhere.

Conceptual modern transaction

Transaction {
  version         // 4 bytes
  inputs[] {
    prev_txid     // 32-byte previous transaction hash
    vout          // output index being spent
    script_sig    // unlocking data for legacy inputs
    sequence
  }
  outputs[] {
    value         // satoshis
    script_pubkey // locking condition
  }
  locktime
}

• Example: a 0.015 BTC UTXO can be spent into one 0.010 BTC payment output and one change output, minus the miner fee.
• Gotcha: the whitepaper does not specify today's full Script system, SegWit witness data, or Taproot spending paths.

Hash commitments

txid = SHA256(SHA256(serialized_transaction))
legacy_p2pkh_hash = RIPEMD160(SHA256(public_key))

Double-spend caveat: two transactions can both carry valid signatures for the same previous output. Consensus accepts only the spend that lands in the valid accumulated-work history.

• Definition: a timestamp proves that the block data existed before the next block was created.
• Example: changing a transaction in block N changes its Merkle root, which changes block N's hash and invalidates every descendant hash link.
• Mechanism: each timestamp includes the previous timestamp's hash, so every later block reinforces the chronological order before it.
• Gotcha: Bitcoin timestamps are not trusted clock records; nodes enforce validity windows, while proof-of-work establishes ordering.

// Valid block condition
SHA256(SHA256(block_header)) < current_target

BlockHeader {
  version        // 4 bytes
  prev_block     // 32 bytes
  merkle_root    // 32 bytes
  time           // 4 bytes
  bits           // compact target
  nonce          // 4 bytes
}

• Expensive forward, cheap backward check: finding a valid nonce requires repeated hashing; validating the found hash is one deterministic comparison.
• Rewriting history: changing a past block requires recalculating proof-of-work for that block and every successor, then overtaking the honest branch.
• Consensus rule: nodes follow the valid branch with the most cumulative proof-of-work; this is the whitepaper's "longest chain" rule in operational form.

Gotcha: miners also vary transaction selection and extra nonce data in the coinbase transaction because the 32-bit header nonce alone can be exhausted.

1. New transactions are broadcast to nodes.
2. Nodes collect valid transactions into a candidate block.
3. Miners search for proof-of-work.
4. A valid block is broadcast to the network.
5. Nodes accept it only if all included transactions are valid and unspent.
6. Nodes express acceptance by building the next block on top of it.

Fork handling: if two valid blocks appear at the same height, nodes keep the competing branch in view and build on the branch they saw first until one side gains more cumulative work.

Gotcha: network messages, peer discovery, mempool policy, compact block relay, and DoS limits are implementation details beyond the paper.

initial_subsidy = 50 BTC
halving_interval = 210000 blocks
subsidy(height) = initial_subsidy / 2^floor(height / halving_interval)
fee = sum(input_values) - sum(output_values)

• Example: height 0 pays 50 BTC; height 210,000 pays 25 BTC; height 420,000 pays 12.5 BTC.
• Supply shape: repeated halving makes issuance a convergent series approaching 21 million BTC rather than an uncapped mint.
• Fee rule: transaction fee equals the sum of spent input values minus the sum of created output values.
• Gotcha: miners cannot claim arbitrary fees; full nodes reject blocks whose coinbase output exceeds allowed subsidy plus actual fees.

target_timespan = 14 * 24 * 60 * 60 seconds
interval = 2016 blocks
actual_timespan = last_block_time - first_block_time
clamped = clamp(actual_timespan, target_timespan / 4, target_timespan * 4)
new_target = old_target * clamped / target_timespan

Gotcha: this is a consensus-critical calculation; real implementations must match integer arithmetic and compact target encoding exactly.

• Definition: leaf hashes are transaction IDs; parent hashes combine pairs until one root remains.
• Example: a wallet can verify a transaction is in a block using a branch of sibling hashes plus the block header.
• Pruning: once all transactions before a point are fully spent, old transaction bodies can be discarded while keeping block headers and Merkle commitments.
• Gotcha: Merkle inclusion proves a transaction is in a block, not that the block itself obeys every consensus rule.

1. Download the chain of block headers.
2. Request a Merkle branch for the transaction of interest.
3. Check that the branch commits to the header's Merkle root.
4. Wait for enough confirmations for the payment value and risk profile.

• What SPV checks: accumulated proof-of-work and inclusion of the target transaction in a block on that work chain.
• What SPV does not check: every script, every input value, inflation rules, and every consensus edge case across the full block history.

When not to rely on SPV: high-value validation, policy-sensitive receiving, and adversarial environments call for full validation.

• Example: to pay 0.30 BTC, a wallet might spend 0.18 BTC and 0.14 BTC UTXOs, create a 0.30 BTC recipient output, and return the remainder as change after fees.
• Gotcha: combining inputs often links them to the same wallet owner, reducing privacy.
• Decision guidance: use fewer inputs for lower fees; use careful coin selection when privacy matters more than fee minimization.

private_key -> public_key
hash160 = RIPEMD160(SHA256(public_key))
legacy_address = Base58Check(version_byte + hash160)

• Whitepaper model: the public can see that someone sent an amount to someone else, but the identities behind public keys are not inherently published.
• Example: reusing one donation address makes every inbound payment to that address publicly clusterable.
• Best practice from the paper: use a new key or address for each transaction to avoid linking payments to a common owner.
• Gotcha: SegWit and Taproot use different address encodings, but they do not erase transaction graph analysis.

p = honest probability of finding next block
q = attacker probability of finding next block
z = confirmations the attacker is behind

if p > q:
  P_catchup = (q / p)^z
else:
  P_catchup = 1

// Whitepaper's confirmation model also accounts for attacker progress while honest nodes mine z blocks.
lambda = z * (q / p)
P_success = sum over k attacker blocks found during the wait:
  Poisson(k, lambda) * min(1, (q / p)^(z - k))

• Example: with small attacker share, each added confirmation sharply lowers catch-up probability; with attacker share near or above 50%, waiting does not provide the same assurance.
• Decision guidance: wait longer for larger payments, low-trust counterparties, or signs of network instability.

Gotcha: confirmations are probabilistic risk reduction, not absolute finality. Risk depends on attacker hash share, network conditions, and payment value.

• P2SH / BIP 16: moves complex script conditions behind a script hash, simplifying receiving addresses.
• SegWit / BIPs 141-144: separates witness data, fixes third-party transaction malleability, and introduces block weight accounting.
• Taproot / BIPs 340-342: adds Schnorr signatures and taproot script paths for better efficiency and privacy properties.
• Timelocks / BIPs 65 and 112: CLTV and CSV added consensus-enforced time conditions that became important for payment-channel designs.

Gotcha: these are not in the 2008 paper; they are later consensus changes layered onto the base design.

• Soft fork: restricts valid behavior, so upgraded and non-upgraded nodes can remain on one chain if activation succeeds.
• Hard fork: expands or changes validity rules in a way old nodes reject, requiring broad explicit migration.
• Gotcha: activation mechanisms are social and technical; the whitepaper does not define governance.

• Dependencies: practical channels depend on timelocks, multisig-style conditions, and malleability fixes.
• Example: two parties can update a channel balance many times while broadcasting only opening and closing transactions on-chain.
• Gotcha: Lightning changes payment workflow, not Bitcoin's base-layer consensus mechanism.

• Benefit: specialized hardware raises the capital cost of attacking accumulated proof-of-work.
• Tradeoff: ASIC supply chains and cheap power access can centralize mining advantages.
• Gotcha: "one CPU, one vote" is the whitepaper framing; modern Bitcoin is better described as one unit of hash work, one probabilistic chance to extend the chain.

• P2P message formats, peer discovery, inv/getdata behavior, and relay policy.
• Script opcodes, standardness policy, sighash modes, witness serialization, and Taproot validation.
• Consensus limits such as block weight, coinbase maturity, locktime semantics, and difficulty edge cases.
• Exact signature curve choices such as ECDSA over secp256k1 for legacy signatures.
• Fork activation rules and operational deployment process.

Practical rule: implement from Bitcoin Core consensus behavior and BIPs, not from the whitepaper alone.