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. (Unlike compact blocks, neither is deployed in Bitcoin Core as of the mid-2020s — Erlay is a proposal still in development, and Dandelion was never adopted — but both are worth knowing as designs.)

• 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.

It actually happened — the relay networks that made blocks fly (2015–2016)

Before compact blocks were a standard, fast propagation was a hand-built arms race. Around 2015 Matt Corallo ran the Bitcoin Relay Network, a set of relay nodes that forwarded blocks with minimal round-tripping to cut the seconds that cause orphans. It evolved into FIBRE (Fast Internet Bitcoin Relay Engine), which used UDP and forward error correction to push blocks across the planet in well under a second. Those ideas were then folded into the protocol itself as compact blocks (BIP 152) in 2016, so every node — not just peers of a special relay network — got most of the benefit. The lesson: shrinking propagation time isn’t cosmetic tuning; it directly reduces orphans and reorgs and levels the field between large and small miners.

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.

The architect’s lens

Gossip looks like plumbing, but every choice in it is load-bearing:

• Why does it exist? To flood a transaction or block to the whole network in log(N) hops with no broker — each node tells its neighbors, who tell theirs — so data created on a laptop in Lagos reaches a miner in Texas in a second or two.
• What problem does it solve? Reaching every verifier cheaply and safely: the validate-then-relay rule makes the network self-cleaning (bad data dies at the first honest hop), and compact blocks (BIP 152) exploit the receiver’s existing mempool to send a few-KB sketch instead of a ~1.5 MB block.
• What are the trade-offs? It’s best-effort, not a guarantee — nodes have different mempools, policies, and connectivity, so no two see the same transactions in the same order; the only thing the network truly agrees on is the chain of blocks.
• When should I avoid it? Flooding is the wrong design when you need deterministic ordering or privacy — which is exactly why refinements layer on top: Erlay swaps flooding for set reconciliation, and Dandelion routes a tx along a quiet stem before fluffing it to hide the origin.
• What breaks if I remove it? Slow or absent propagation widens the window for two miners to find competing blocks at the same height, spiking orphans/reorgs — wasted honest work, and an unfair edge for large, well-connected miners over small ones. Speed here is fairness.

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?

Show answers

1. A peer sends inv (“I have item X”, just the hash); a peer lacking X replies getdata; the full tx/block then arrives. A node validates before relaying because that makes the gossip network self-cleaning — a malformed tx or invalid block is dropped at the first honest hop and never propagates, so garbage and attacks can’t spread.
2. Example: a fully valid but non-standard transaction (e.g. a bizarre or oversized script form). The relay/standardness policy — a local, conservative filter (min fee, no weird scripts, no dust) — stops most nodes from gossiping it, while the consensus rules would still let a miner include it in a block.
3. Slow propagation widens the window in which two miners find blocks at the same height before the news spreads, so one becomes an orphan/stale block — wasted work and a brief disagreement about the tip. It’s a fairness issue because large, well-connected miners hear blocks sooner and orphan small miners’ work less often, an advantage fast propagation erases.
4. Most transactions in a new block are already in the receiver’s mempool, so a compact block (BIP 152) sends only the header plus short transaction IDs (a few KB). The receiver reconstructs the block from its own mempool and uses getblocktxn to request just the few transactions it was missing — cutting relay bandwidth and latency dramatically.
5. Erlay reduces the bandwidth of transaction announcements using efficient set reconciliation (making it affordable to keep more peers, which helps resist eclipse). Dandelion(++) improves transaction privacy by passing a new tx quietly along a random single “stem” path before diffusing it widely (“fluff”), obscuring the origin.