How Nodes Propagate Transactions

When you click "Send" on your Bitcoin wallet, your transaction does not instantly land in a block. Instead, it must travel across the globe, hop by hop, through the decentralized peer-to-peer network.

To prevent network congestion, bandwidth exhaustion, and denial-of-service (DoS) spam attacks, Bitcoin nodes use a highly coordinated, three-way inventory handshake to propagate transactions.

---

🤝 The Three-Way Inventory Handshake

If nodes simply forwarded every transaction they received directly to all their peers, the network would collapse under the weight of redundant data. If a node has 10 peers, and all 10 peers receive a transaction, sending the full transaction back and forth among themselves would waste massive amounts of bandwidth.

To avoid this, Bitcoin nodes use a "pull-based" inventory notification system using three core message types:

1. inv (Inventory): "I have these items."
2. getdata: "Please send me these specific items."
3. tx (Transaction) / block: "Here is the requested item."

Node A                                                     Node B
  │                                                          │
  ├─────── inv (Contains hash of TX, e.g., TXID) ───────────►│ (Checks if already knows TXID)
  │                                                          │
  │◄────── getdata (Requests full TX data) ──────────────────┤
  │                                                          │
  ├─────── tx (Sends full transaction bytes) ───────────────►│ (Validates and adds to Mempool)
  ▼                                                          ▼

Step 1: The inv Message

When Node A receives or validates a new transaction, it does not send the full transaction bytes to Node B. Instead, it sends an inv message containing only the transaction hash (the TXID, which is 32 bytes). This is Node A saying, "I have a transaction with this ID. Do you want it?"

Step 2: The getdata Message

Node B receives the inv message and looks up the TXID in its local mempool (its memory storage of unconfirmed transactions) and its transaction cache. * If Node B already has this transaction, it ignores the inv message. * If Node B does not have this transaction, it sends a getdata message back to Node A requesting the full transaction data.

Step 3: The tx Message

Upon receiving the getdata request, Node A packages the full transaction (inputs, outputs, scripts, and signatures—typically 200 to 500 bytes) into a tx message and transmits it to Node B. Node B then validates the transaction against Bitcoin's consensus rules and, if successful, adds it to its own mempool.

---

🛡️ Mempool Validation Rules: The Guardrail of Propagation

A node will only relay a transaction if it passes rigorous validation checks. If a transaction fails even one rule, the node immediately discards it and refuses to send an inv message to its peers. This prevents malicious nodes from spamming the network with invalid transactions.

Each node checks the following before propagation:

1. Cryptographic Signatures: Are the unlocking scripts (signatures) valid for the UTXOs being spent?
2. Double-Spend Prevention: Are any of the inputs already spent in the blockchain or current mempool?
3. Minimum Fee Policy: Does the transaction include a transaction fee that meets the node's minimum relay fee (typically 1 sat/vByte)?
4. Standardness Rules: Is the transaction structured standardly? To prevent exploitation of untested script features, nodes only relay "standard" transaction types (like P2PKH, P2WPKH, or multisig).

---

🚀 Transaction Propagation Efficiency (Compact Blocks & BIP 152)

While the three-way handshake works beautifully for individual transactions, blocks of transactions are much larger (up to 4MB in weight). Relaying full blocks using a standard handshake would introduce critical network latency.

To optimize block relay times, Bitcoin Core uses BIP 152 (Compact Blocks):

Since a node's mempool already contains 99% of the transactions that get included in a newly mined block, sending the entire list of full transactions is wasteful. Under Compact Blocks, when a miner finds a block: 1. The propagating node sends a Compact Block message containing the block header and short transaction IDs (truncated 6-byte hashes of the transactions). 2. The receiving node reconstructs the block using the transactions already sitting in its own local mempool. 3. If any transactions are missing, the receiving node requests only those specific missing transactions.

This optimization reduces block propagation data by over 90%, keeping the network incredibly fast and reducing the rate of accidental blockchain splits (forks).