TERM_DEF // NETWORKING / MEMPOOL_POLICY
MEMPOOL
POLICY
POLICY
Mempool Policy. Per-node rules for accepting or evicting unconfirmed transactions, distinct from consensus.
This page sits in the Networking section — How nodes find peers, exchange transactions and blocks, and stay in sync. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
This page sits in the Networking section — How nodes find peers, exchange transactions and blocks, and stay in sync. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_MEMPOOL_POLICY_IS
Mempool Policy — at a glance
NETWORKING
Mempool Policy is part of the GOSSIP set of Bitcoin P2P messages. Ask a peer to send an inv for every tx in its mempool. Per-node rules for accepting or evicting unconfirmed transactions, distinct from consensus.
Why it exists
DESIGN
If Bitcoin had a central server, that server would be the system. It could be shut down, subpoenaed, censored, or compromised. The peer-to-peer architecture removes that single point of failure: any individual node can vanish and nothing happens; the rest of the network keeps going. This is the same insight as BitTorrent — but applied to money, with strict consensus rules layered on top.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
A new node bootstraps by querying hard-coded DNS seeds for a list of recent peers, then connecting to ~8–10 of them over TCP port 8333. Each connection exchanges a "version" handshake, then transactions and blocks flow as INV announcements followed by GETDATA requests. A node only fetches data it doesn't already have. Validation is local: each node re-checks every signature, every PoW, every consensus rule itself.
1. Bootstrap: node asks DNS seeds → receives a list of recent peer IPs.
2. Handshake: TCP connect to ~8 outbound peers + accept up to ~117 inbound; exchange "version" and "verack" messages.
3. Sync: download headers first (fast, ~80 bytes each), then blocks in parallel, validating as they arrive.
4. Steady state: relay new transactions / blocks via INV announcements; fetch via GETDATA only when needed.
5. Mempool: keep unconfirmed transactions waiting for inclusion; evict lowest-fee ones when full.
6. Validation: every full node enforces every consensus rule itself — no trust required.
WORKED_EXAMPLE
Mempool Policy — GOSSIP
EXAMPLE
Request : single mempool message (no payload)
Response: inv announcing every unconfirmed txid the peer holds
Use : wallet bootstrap, mempool monitoring
KEY_PROPERTIES
Anyone can run a node. No whitelist, no signup, no gatekeeper. Default port: 8333.
REDUNDANT
Tens of thousands of full nodes worldwide hold the entire chain. Taking any one offline changes nothing.
GOSSIP-BASED
Transactions and blocks propagate by INV → GETDATA → DATA, in seconds globally.
TRUSTLESS
Every full node validates every rule itself. No third party can lie to it about the chain state.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- "Light wallets" (SPV, Electrum, mobile) trust whatever upstream server they connect to for fee data, transaction history, and balance. A full node is the only way to verify.
- Running a node behind Tor is private but slower; behind a clearnet IP it can be enumerated and probed.
- Pruned nodes save disk but lose the ability to serve historical blocks. Choose based on whether you want to help bootstrap others.
- block-download-ibd/">Initial Block Download (IBD) is bandwidth-intensive — the first ~700 GB will saturate a residential connection for hours.
RELATED_CONCEPTS
Other terms from Networking — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
Mempool Policy
Per-node rules for accepting or evicting unconfirmed transactions, distinct from consensus.
Full Node
A node that downloads and verifies every block and transaction against consensus rules.
Light Node (SPV Node)
A node that downloads only headers and uses Merkle proofs to verify specific transactions.
SPV (Simplified Payment Verification)
Verifying inclusion of a tx by checking its Merkle proof against a downloaded header chain.
Bloom Filter
A probabilistic filter an SPV node sends so full nodes only forward potentially-relevant transactions.
Peer
Another node your node has an open connection to.
Peer Discovery
Finding new peers via DNS seeds, hard-coded seeds, or peer-exchange messages.
DNS Seed
A DNS hostname returning A-records of well-known node IPs; bootstrap mechanism.