Bitcoin: A Peer-to-Peer Electronic Cash System

Authorization does not choose one history

The white paper combines signatures, hash-linked records, proof of work, and a chain-selection rule to address conflicting spends without a central mint. A signature can authorize two incompatible transactions from the same owner; it does not choose which transaction belongs in the accepted history. The security argument also depends on a model of computational participation and communication. This lesson studies that model and does not make a claim about asset value or investment merit.

Original reconstruction: two valid signatures, one spendable output

Imagine an unspent output U controlled by Alice. Alice signs transaction T1 spending U to Bob and separately signs T2 spending U to Carol. Both signatures verify. A node that checks only signatures can accept both, creating value that the ledger’s spend-once rule was meant to prevent.

A validating node checks transaction conditions against a particular ledger state. After applying T1, U is spent, so T2 cannot also be applied to that same history. Another branch may contain T2 first and reject T1. The remaining question is which valid branch participants converge on. Proof of work makes extending a branch require computational effort; accumulated work, together with validation rules, guides branch selection. A chain with more work does not make an invalid transaction valid.

Consider two branches with equal difficulty per block. Branch X contains six new blocks and branch Y contains five, so X has more accumulated work under this simplifying assumption. If difficulties differ, counting blocks alone is insufficient. Keep validity, work calculation, and branch preference as separate checks in a toy implementation.

Calculate catch-up under a deliberately narrow model

Suppose an attacker controls fraction q=0.2 of the block-production rate, while honest participants control p=0.8. Assume independent discoveries, constant rates, and a known current deficit of z=3 blocks. In the biased random-walk model, the probability of ever catching up from that deficit is (q/p)^z=(0.2/0.8)^3=1/64, approximately 0.015625.

This is not the complete probability that a merchant is attacked successfully after waiting for three confirmations. During the merchant’s waiting interval, the attacker may already have produced private blocks. The paper’s later calculation accounts for uncertainty about that hidden progress using an approximation. Reporting the simple deficit formula as the complete confirmation risk would change the event being measured.

The model also idealizes network propagation, hash-power stability, attacker strategy, and what counts as catching up or succeeding. A numerical result is only as applicable as those assumptions. It is useful for understanding exponential decline in a simplified setting, not for promising certainty after a fixed number of blocks.

Test state and evidence separately

Build a local ledger with explicit output identities and deterministic validation. Test a valid spend, a repeated spend on the same branch, two competing branches, and a later branch switch. Recompute the unspent state from the selected valid history rather than merging incompatible branch states.

A Merkle inclusion proof can show that a transaction hash is committed by a particular block header. It does not independently prove that the transaction satisfies every ledger rule or that the header belongs to the ultimately selected history. Likewise, a network with many apparent identities does not gain independent security votes merely by counting those identities under a work-based model.

The paper is best read as a composition of mechanisms with separate responsibilities. Track authorization, ordering, inclusion, work, and finality claims individually. That discipline exposes both the ingenuity of the construction and the assumptions that a short description of a decentralized ledger can hide.

from hashlib import sha256
def leaf(x): return sha256(b'\x00' + x).digest()
def parent(a,b): return sha256(b'\x01' + a + b).digest()
a,b,c,d = map(leaf, [b'A',b'B',b'C',b'D'])
ab = parent(a,b)
root = parent(ab,parent(c,d))
proof = [('right',d),('left',ab)]
def verify(payload, path, expected):
    current = leaf(payload)
    for side, sibling in path:
        if side == 'right': current = parent(current,sibling)
        elif side == 'left': current = parent(sibling,current)
        else: return False
    return current == expected
assert verify(b'C',proof,root)
assert not verify(b'X',proof,root)
assert not verify(b'C',[('left',d),('left',ab)],root)

• Bitcoin: A Peer-to-Peer Electronic Cash System: Bitcoin.org