Gossip: How Transactions & Blocks Propagate

A transaction created on a laptop in Lagos can reach a miner in Texas in a second or two, with no router, no broker, no central exchange in the middle. It happens by gossip: each node tells its handful of neighbors about new data, they tell their neighbors, and within a couple of hops the whole network knows. This page traces exactly how that flood works — and why making it fast is not a nicety but a security property.

The flood, step by step

Recall the announce-then-request split from the P2P protocol. Propagation is that pattern repeated outward:

You broadcast a new tx (hash = X):

  YOU ──inv(X)──► peer1 ──inv(X)──► peer4
   │              peer1 ──getdata(X)──► YOU
   │              YOU ──tx(X)──► peer1   (peer1 now has it, validates it)
   ├──inv(X)──► peer2 ...                 (peer1 then inv(X)'s ITS peers)
   └──inv(X)──► peer3 ...

  A peer that ALREADY has X just ignores the inv. No duplicate downloads.

Three moves repeat at every hop:

1. inv — “I have item X” (just the 32-byte hash). Cheap to send to all neighbors.
2. getdata — a peer who lacks X replies “send me X.”
3. tx / block — the full item arrives; the receiver validates it, and only if it passes does it inv X onward. Invalid data dies at the first honest node.

Because each node forwards only to neighbors who don’t already have the item, the same block isn’t shipped twice down the same link, and the flood reaches everyone in roughly log(N) hops.

Validate before you relay

A node never relays a transaction or block it hasn’t checked. This is what stops garbage and attacks from spreading: a malformed tx or an invalid block is dropped at the first honest hop and never propagates. The gossip network is self-cleaning because every relay point is also a verifier.

Relay policy vs consensus rules — a crucial distinction

There are two different rulebooks at work, and conflating them causes endless confusion:

• Consensus rules decide whether a transaction or block is valid — whether it can ever be in the chain. These are identical for every node and can never change without a fork. (Covered in block validation.)
• Relay / standardness policy decides whether a node will gossip an unconfirmed transaction to its peers. This is a local, conservative filter — minimum fee rate, no weird script forms, no dust — and nodes may legitimately differ on it.

A transaction can be fully valid yet non-standard: a miner could include it in a block, but most nodes won’t relay it across the network on its own. Relay policy is about what the mempool will carry, not about what’s allowed in a block. This split feeds directly into the mempool and the fee market.

Why block propagation speed is a security property

When a miner finds a block, they want every other miner to hear about it immediately. Here’s the stakes: if two miners find blocks at nearly the same height before the news spreads, the network temporarily splits and one block becomes an orphan/stale block — wasted work, and a brief disagreement about the tip (see orphans & reorgs).

Slow propagation:  miner A finds block ──(delay)──► miner B hasn't heard,
                   finds a COMPETING block at same height  →  ORPHAN risk ↑

Fast propagation:  miner A finds block ──(instant)──► everyone builds on it
                                                       →  ORPHAN risk ↓

So fast propagation shrinks the window for accidental forks, which keeps more honest work on the canonical chain and, importantly, reduces an advantage that large/well-connected miners would otherwise have over small ones. Speed here is fairness.

Compact blocks (BIP 152)

The naive flood ships the entire block — every transaction — to each peer. But most of those transactions are already sitting in the receiver’s mempool! Re-sending them is wasteful and slow.

Compact blocks (BIP 152) exploit this. Instead of the full block, a node sends a tiny sketch:

Full block:     ~1.5 MB of transactions, all re-sent.

Compact block:  header + short IDs of each tx (a few KB).
   Receiver reconstructs the block from its OWN mempool,
   and only requests the few txs it was missing (getblocktxn).

Since the receiver already has nearly all the transactions, it rebuilds the block locally from short IDs and asks for just the gaps. This cuts block-relay bandwidth and latency dramatically — directly attacking the orphan problem above. (A related “high-bandwidth” mode forwards blocks with even less round-tripping.)

A glance at Erlay and Dandelion

Two further refinements, at a high level:

• Erlay reduces the bandwidth of transaction announcements. Flooding invs to every peer is redundant; Erlay uses efficient set reconciliation so two peers cheaply figure out which transactions each is missing, rather than naively announcing everything. This makes it affordable for a node to maintain more connections — which, as network attacks explains, improves resistance to eclipse.
• Dandelion(++) improves transaction privacy. Instead of immediately flooding a new tx in all directions (which can reveal the origin to a watching adversary), the tx is first passed quietly along a random single path (the “stem”) for a few hops, and only then diffused widely (the “fluff”). This obscures which node actually created the transaction.

Propagation is best-effort, not a guarantee

Gossip makes no promise that every node sees every transaction in the same order, or at all. Nodes have different mempools, different policies, and different connectivity. The only thing the network truly agrees on is the chain of blocks — propagation just gives consensus its raw material.

The thread

How does this help untrusting strangers agree on one ledger? Gossip is the nervous system that carries proposals to every verifier. It assumes no honesty — bad data is filtered at each hop by validation — and it strives to deliver new blocks fast so that the honest majority’s work converges on a single tip instead of fragmenting into competing forks. Without rapid, validate-then-relay propagation, “the most-work chain” would be a different chain for different people.

Check your understanding

1. Trace the inv → getdata → tx/block sequence. Why does a node validate an item before relaying it onward?
2. Give an example of a transaction that is consensus-valid but non-standard. Which rulebook stops it from being relayed, and which would let it into a block?
3. Why does slow block propagation increase the rate of orphan/stale blocks, and why is that also a fairness issue between miners?
4. How do compact blocks (BIP 152) use the receiver’s existing mempool to shrink block-relay traffic?
5. In one line each, what problem does Erlay address, and what problem does Dandelion address?