Mastering Bitcoin — 11.7: Mempool, Orphan Pool, and Tor
A look beneath Bitcoin's surface at three under-discussed parts of how a node actually operates: the plaintext peer-to-peer gossip layer, the local transaction waiting rooms, and the global state that all honest nodes agree on. We trace what travels between nodes, how Tor changes that, and why two nodes can hold very different views of pending transactions while still sharing the same consensus.
Key concepts covered:
Why Bitcoin Core's P2P protocol sends traffic in plaintext by default and what metadata leaks
How Tor's three-relay onion routing protects transport, and the outbound, hidden service, and combined modes
Automatic hidden service setup via the local Tor daemon and authentication cookie since Bitcoin Core 0.12
The mempool: a node's local, in-memory list of validated but unconfirmed transactions
The orphan pool: transactions whose parent has not yet arrived, parked rather than rejected
The orphan cascade: how arriving parents trigger recursive promotion of children into the mempool
Why there is no global mempool — every node's view diverges based on uptime, peers, and policy
The UTXO set as the shared, on-disk, consensus-consistent state contrasted with ephemeral pools
The layered model: transport (P2P/Tor), local node state (pools), and consensus (UTXO + blockchain)
Privacy at the network layer versus consistency at the consensus layer