By 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 such as signature verification and mempool dependency management can be computationally expensive. Famously, transactions with a large number of legacy (pre-segwit) signatures can take minutes to validate on some hardware2, so most nodes filter out large transactions. Resource usage is not only local to the node either: accepted transactions are typically gossiped to other peers, using bandwidth proportional to the number of nodes on the network.
Nodes protect themselves by limiting the memory used for unconfirmed transactions and validation queues, throttling transaction processing per peer, and enforcing policy rules in addition to consensus. Yet these limits can also create censorship vectors when not designed carefully. The simple logic of not downloading a transaction that has already been rejected before, limiting the size of the transaction queue for a single peer, or dropping requests after failed download attempts can lead to nodes blinding themselves to a transaction. These bugs become accidental censorship vectors when exploited by the right attacker.
In this vein, while it is entirely logical to not keep unconfirmed transactions that are double-spends of each other (only one version can be valid), rejection of a double-spend means that an earlier broadcast precludes a later one from being mined. A double-spend could be an intentional attempt to fake a payment or, when a UTXO is owned by multiple parties, a pinning attack that exploits mempool policy to delay or prevent second layer settlement transactions from being mined. How should nodes choose?
This question brings us to the second element of transaction relay: incentive compatibility3. While fees are not relevant to consensus beyond limiting what a miner can claim as a block reward, they play a huge role in node policy as a utility metric. Assuming miners are driven by economic incentives, nodes can approximate which transactions are most attractive to mine and discard the least attractive ones. When transactions spend the same UTXO, the node can keep the more profitable one. While nodes do not collect fees, they can consider zero fee transactions as spam: they are likely to use up network resources but never be mined, yet cost virtually nothing to create.
These two design goals — DoS resistance and incentive compatibility — are in constant tension. While it is attractive to replace a transaction with a higher feerate-version, allowing repeated replacements with tiny fee bumps could waste the network’s bandwidth. Accounting for dependencies between unconfirmed transactions can create more profitable blocks (and enable CPFP), but can be expensive for complex topologies.
Historically, nodes relied on heuristics and dependency limits, which caused user friction and opened new pinning vectors. Mempools that track clusters can assess incentive compatibility more accurately but still must limit mempool dependencies. These types of restrictions create pinning vectors for transactions involving multiple parties that don’t trust each other: an attacker can prevent their co-transactor from employing CPFP by monopolizing the limit.
It is easy to trivialize these issues: pinning attacks are a niche type of censorship that only apply to shared transactions and typically only result in temporary transaction delays. Is it worth the effort to help non-mining nodes squeeze a few extra satoshis of fees?
A Deal with the Mevil
Shared transactions are the backbone of UTXO-mixing privacy solutions and second layer protocols. Much of Bitcoin development is focused on creating scalable, private, feature-rich applications in a second layer that falls back to settling on-chain. A common pattern is to temporarily delay withdrawals or settlement, allowing parties to respond to misbehavior within a time window. But many designs – including ones that are used to motivate consensus changes – gloss over fee-bumping in these scenarios.
A time window to prevent misbehavior is also a window of opportunity for attackers. These two conditions – shared transactions and confirmation deadlines to prevent misbehavior – create the perfect storm that upgrades the severity of pinning attacks from temporary transaction delays (meh) to potential theft (oh no!).
Pinning has been the subject of years of research and development effort resulting in the Topologically Restricted Until Confirmation (TRUC) transaction format4, Pay to Anchor (P2A) output type5, Ephemeral Dust policy6, Cluster Mempool7, limited relay of packages8, and various improvements to transaction relay reliability. These features are designed to provide stronger guarantees for propagating higher fee replacements of shared transactions.
Still, proper fee management involves overhead in the form of larger transactions, more complex wallet logic, and handling unlikely edge cases. An easy shortcut is to strike a deal with a miner: in exchange for a fee, the miner guarantees that their transactions will be mined promptly. This solution may prove more reliable than using the peer-to-peer network, which can have high latency and poor propagation due to heterogenous mempool policies.
Adoption of direct-to-miner submission can grow quickly when there is commercial interest. Exchanges represent a large proportion of transaction volume and probably prefer predictable timing over optimizing fees. Popular applications may be plagued with pinning attacks or want to use nonstandard transactions that common node policies prohibit. Companies and custodians concerned about quantum short-range attacks may create a private channel with a miner.
As private Miner Extractable Value (MEVil)9 becomes necessary to stay competitive, the network can snowball toward a model of centralized blockspace brokers. These services can become chokepoints for attackers and government mandates and undermine the premise that becoming a miner is permissionless.
If the transaction relay network becomes irrelevant for node operation, then participating in it may also feel unnecessary. In this hypothetical future, will we chuckle at the idea of every node on the network relaying unconfirmed transactions, the way we think it’s funny that Satoshi envisioned every node to be a miner?
The irony is that mining centralization does not begin with overt collusion or regulatory capture. It begins with a few rational shortcuts: more efficient agreements, custom relay paths, or performance optimizations that are beneficial to their participants. Nobody can stop these agreements from taking place. But we can try to reduce the competitive edge that private services have over the public network: iron out mempool pinning vectors before considering proposals for consensus changes that increase the potential for Mevil; make the public transaction relay network an efficient marketplace to bid (and update bids) for block space.
The peer-to-peer network is where many of Bitcoin’s core ideologies come to life. It is also an engineering challenge with painful tradeoffs between efficient node operation, censorship resistance, incentive alignment, and protocol complexity. It will only get harder as Bitcoin grows. How it should choose to reconcile these competing design goals is left as an exercise to the reader.
Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!
This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.
[1] https://bitcoin.org/bitcoin.pdf
[2] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710
[3] https://delvingbitcoin.org/t/mempool-incentive-compatibility/553
[4] https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki
[5] https://github.com/bitcoin/bitcoin/pull/30352
[6] https://bitcoinops.org/en/topics/ephemeral-anchors/
[7] https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393?u=glozow
[8] https://bitcoinops.org/en/topics/package-relay/
[9] https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev/
