Bitcoin Magazine
Satoshi’s Exercise for the Reader
The Bitcoin whitepaper is clear about Bitcoin’s core feature: it is permissionless. Anyone in the world can pay anyone by joining the peer-to-peer network and broadcasting a transaction. Proof of Work consensus even empowers anybody to become a block producer, and means that the only way to reverse a payment is to overpower everyone else through hashpower.
But Proof of Work only defines how to choose a winner amongst competing chains; it does not help a node discover it. A 51% attack – or a 100% attack – is much easier if an attacker can prevent nodes from hearing about competing chains. The job of discovery belongs to the peer-to-peer module, which juggles many contradictory tasks: Find honest peers in a network where nodes constantly join and leave, but without authentication or reputation. Always be on the lookout for blocks and transactions, but don’t be surprised if most data is garbage. Be robust enough to survive extreme adversarial conditions, but lightweight enough to run on a Raspberry Pi.
The implementation details for a permissionless peer-to-peer network were left out of the whitepaper, but constitute the bulk of the complexity in Bitcoin node software today.
Filters are for Spam
The whitepaper acknowledges public transaction relay as the cornerstone of Bitcoin’s censorship resistance, but only says a few words about how it should operate: “New transactions are broadcast to all nodes. Each node collects new transactions into a block. Each node works on finding a difficult proof-of-work for its block.”1
Many find it amusing that Satoshi suggested every node would mine. Due to the centralizing pressure of mining variability, the vast majority of nodes on today’s network do not work on finding a proof-of-work. Perhaps that is an acceptable or even successful result of economic incentives; we traded a portion of decentralization for increased hashpower and thus security. However, Bitcoin’s censorship resistance will collapse if we also give up decentralized transaction relay.
Our desire for a wide pool of transaction relaying nodes must contend with the practicality of everyday computers exposing themselves to a permissionless network and processing data from anonymous peers. This threat model is unique and requires highly defensive programming.
In block download, a block’s proof-of-work elegantly serves as both Denial of Service (DoS) prevention and an unambiguous way to assess the utility of data. In contrast, unconfirmed transaction data is virtually free to create and might just be spam. For example, we cannot know whether the transaction meets its spending conditions until we have loaded the UTXO, which may require fetching from disk. It costs attackers absolutely nothing to trigger this relatively high latency activity: they can craft large transactions using inputs that do not belong to them or do not exist at all.
Validation steps s
