Gossip Protocol (Lightning)

What Is the Gossip Protocol?

The gossip protocol is the peer-to-peer messaging system that Lightning Network nodes use to share information about the network's topology. Defined in BOLT #7 (the "P2P Node and Channel Discovery" specification), it enables every node to build a local map of all public channels, their routing policies, and the nodes that operate them.

The name comes from how the protocol spreads information: like gossip in a social network, each node tells its peers about new channels and policy changes, who then tell their peers, until the entire network has the update. This flood-fill approach is simple and robust, but it means every node must process every public update, creating a bandwidth cost that scales with the size of the network.

Gossip serves a single critical purpose: enabling pathfinding. When a sender wants to pay a receiver, they need to find a route through the channel graph. Without gossip, nodes would have no knowledge of channels beyond their own, and multi-hop payments would be impossible.

How It Works

The gossip protocol revolves around three message types, each serving a distinct role in describing the network. Together they provide everything a node needs to construct its local channel graph and calculate payment routes.

channel_announcement (Type 256)

Announces a new public channel to the network. This message is approximately 430 bytes and requires cooperative signatures from both channel peers, plus signatures from their Bitcoin funding keys:

channel_announcement {
  node_signature_1    // ECDSA signature from node 1
  node_signature_2    // ECDSA signature from node 2
  bitcoin_signature_1 // signature from node 1's funding key
  bitcoin_signature_2 // signature from node 2's funding key
  features            // feature flags
  chain_hash          // identifies blockchain (mainnet, testnet)
  short_channel_id    // block_height:tx_index:output_index
  node_id_1           // public key (must be lexicographically smaller)
  node_id_2           // public key
  bitcoin_key_1       // funding key for node 1
  bitcoin_key_2       // funding key for node 2
}

Nodes validate channel announcements by checking that the referenced UTXO exists on-chain as a P2WSH output with at least 6 confirmations, and that all four signatures are valid. The requirement for on-chain proof prevents spam: you cannot announce a channel without locking real Bitcoin into it.

node_announcement (Type 257)

Advertises a node's alias, color, network addresses, and supported features. A node can only broadcast this message if it already has at least one channel_announcement referencing it, which prevents unauthenticated nodes from flooding the network:

node_announcement {
  signature   // signed by node_id
  features    // supported protocol features
  timestamp   // must exceed any prior announcement
  node_id     // 33-byte compressed public key
  rgb_color   // 3-byte color for graph visualization
  alias       // 32-byte UTF-8 node name
  addresses   // IPv4, IPv6, Tor v3, or DNS hostname
}

Each node_announcement supersedes the previous one from the same node. Nodes use the timestamp field to determine which announcement is current and discard older versions.

channel_update (Type 258)

The most frequently sent gossip message. Each channel peer independently broadcasts a channel_update for their direction of the channel, advertising their routing fees, CLTV delta, and HTLC size limits:

channel_update {
  signature                  // signed by the announcing node
  chain_hash                 // blockchain identifier
  short_channel_id           // which channel
  timestamp                  // must exceed prior update
  message_flags              // bit 0: must_be_one
  channel_flags              // bit 0: direction, bit 1: disabled
  cltv_expiry_delta          // timelock delta for this hop
  htlc_minimum_msat          // smallest HTLC accepted
  fee_base_msat              // base fee in millisatoshis
  fee_proportional_millionths // proportional fee rate
  htlc_maximum_msat          // largest HTLC accepted
}

Two channel_updates exist per channel (one per direction), and they change whenever a node adjusts its fee policy. Channel updates account for roughly 60% of all gossip traffic, with node announcements making up another 30%.

Propagation Mechanics

When a node receives a valid gossip message it has not seen before, it queues it for forwarding to all other peers. The specification recommends batching outgoing gossip and flushing once every 60 seconds, which provides natural rate limiting and reduces per-message overhead. Under this scheme, a new channel_update reaches approximately 75% of the network within 200 seconds.

Channels with no channel_update in either direction for two weeks (1,209,600 seconds) are considered stale and may be pruned from the graph. Nodes without any remaining channels are also pruned. This automatic cleanup prevents the graph from accumulating dead entries indefinitely.

Bandwidth and Scaling

Gossip bandwidth is one of the Lightning Network's most significant scaling challenges. Because every node must process every public gossip message, the cost grows with the network:

For desktop and server nodes, this bandwidth is manageable. For mobile devices on cellular connections, downloading and validating tens of megabytes of gossip on every startup is impractical. This has driven the development of optimization techniques described below.

Gossip Filtering

BOLT #7 defines several query messages that allow nodes to request only the gossip they need, rather than receiving the entire history:

• gossip_timestamp_filter: tells a peer to only send messages with timestamps in a specified range, avoiding full history replay on reconnection
• query_channel_range: requests channel IDs for a specific block height range, enabling incremental synchronization
• query_short_channel_ids: requests full gossip messages for specific channels, with optional zlib compression

These mechanisms reduce redundant data transfer but do not fundamentally change the flood-fill model: every node still eventually receives every update.

Rapid Gossip Sync

The LDK project introduced Rapid Gossip Sync, a semi-trusted optimization for mobile and resource-constrained nodes. A server pre-validates gossip signatures and provides compressed delta snapshots. This reduces the initial graph download from ~53 MB to approximately 2 MB (with gzip compression) and processes in under 0.4 seconds on mobile devices.

The tradeoff is trust: a malicious Rapid Gossip Sync server could omit channels or manipulate fee data to influence routing decisions. For this reason, full nodes still rely on standard gossip for authoritative graph construction.

Rate Limiting

The specification requires that timestamps be strictly increasing for each message type per channel or node, limiting updates to at most one per second. In practice, implementations enforce tighter limits:

• LND limits keep-alive updates (timestamp-only changes) to one per 24 hours and policy changes to one per block (~10 minutes) per direction
• Core Lightning applies similar constraints through its gossip store compaction
• Outgoing gossip bandwidth in LND defaults to 1 MB/s with a 2 MB burst capacity

Role in Pathfinding

Gossip is the sole input to Lightning pathfinding algorithms. Each node assembles a weighted directed graph where channels are edges and nodes are vertices. The edge weights derive from channel_update fields: base fee, proportional fee, and CLTV delta. Pathfinding algorithms (typically modified Dijkstra or Yen's K-shortest paths) search this graph for the lowest-cost route to the destination.

A critical limitation: gossip does not include channel liquidity information. A channel_update reveals the maximum and minimum HTLC sizes, but not how much balance is available in each direction at any given moment. Senders must estimate liquidity through probing or probabilistic models, and retry with alternative paths when payments fail. For a deeper look at how routing algorithms handle this uncertainty, see the Lightning routing deep dive.

Private channels are excluded from gossip entirely. Nodes with only private channels include routing hints in their invoices so payers can construct the final hop of the route without needing gossip data for those channels.

Why It Matters

The gossip protocol determines how well the Lightning Network can scale as a payment system. Every public channel and policy change must reach every node, which means gossip bandwidth grows linearly with the number of channels. For a network aspiring to support millions of users, this is a fundamental bottleneck.

For node operators, gossip quality directly affects routing success rates and revenue. A node with a stale or incomplete graph will attempt routes through disabled channels or use outdated fee estimates, leading to payment failures. Conversely, a well-connected node with fresh gossip data can find efficient routes consistently.

Layer-2 protocols like Spark take a different approach to network coordination. Rather than requiring every participant to maintain a full graph of the network, Spark uses a statechain-based architecture where transfers happen directly between parties without multi-hop routing, eliminating the need for gossip-driven pathfinding entirely.

Future Developments

Taproot Gossip (Gossip 1.75)

A proposed upgrade introduces four new message types (channel_announcement_2, node_announcement_2, channel_update_2, and announcement_signatures_2) designed for Taproot channels. Key changes include replacing Unix timestamps with block heights for better spam prevention, using BIP-340 Schnorr signatures with MuSig2 aggregation (one signature instead of four), and adopting pure TLV encoding for extensibility.

Set Reconciliation

Inspired by the Erlay proposal for Bitcoin's transaction relay, researchers are exploring minisketch-based set reconciliation for gossip. Instead of flood-filling every message, nodes would exchange compact sketches (~64 KB) to identify differences in their gossip sets, then request only the missing data. This could dramatically reduce bandwidth for a network with 100,000+ channels but faces challenges with rate-limiting inconsistencies across implementations. For more on Lightning's scaling trajectory, see the scalability limits analysis.

Risks and Considerations

Bandwidth Scaling

The flood-fill model means gossip bandwidth grows linearly with the number of public channels. A network with 500,000 channels would require roughly 10x the current gossip volume. Mobile nodes and nodes in bandwidth-constrained environments (emerging markets, satellite links) face increasingly difficult tradeoffs between graph freshness and data costs.

Graph Inconsistency

The gossip graph is not a consensus data structure. Different nodes may have different views of the network depending on which messages they have received, when they last synced, and which peers they connect to. This means two nodes attempting to route a payment may calculate completely different paths, and routing failures caused by stale data are common.

Privacy Implications

All public channels are visible to every node on the network, including the node IDs and on-chain funding transactions. This creates a transparency tradeoff: gossip enables efficient routing but exposes channel relationships and on-chain footprints. Nodes concerned about privacy can use private channels or blinded paths to reduce their gossip footprint. For a detailed analysis, see the Lightning privacy analysis.

Eclipse Attacks

If an attacker controls all of a node's peers, they can feed it a manipulated gossip graph: omitting channels, injecting false fee data, or hiding parts of the network. This eclipse attack could force the victim to route all payments through attacker-controlled nodes. The mitigation is connecting to diverse, trusted peers and cross-referencing gossip data from multiple sources.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.