Gossip protocol

Lightning has no directory, so nodes tell each other what exists and every node keeps its own copy. BOLT 7 defines three messages for that, and a receiving node should ignore a channel whose funding output has fewer than 6 confirmations. Your wallet finds a route because it, or a node it trusts, listened to that chatter first.

How it works

The gossip protocol carries three message types, and each one has to prove something on chain or by signature before a peer will pass it along.

channel_announcement (type 256) claims a channel exists. A receiving node looks up the funding output on the blockchain: a message whose output is not the expected P2WSH script, or is already spent, must be ignored, and one whose output has fewer than 6 confirmations should be ignored unless it is close enough that the node may simply be behind on blocks. Announcing a channel therefore costs a real on-chain transaction, which is the entire anti-spam design: nobody can invent a thousand channels for free.

node_announcement (type 257) carries the operator's own details. Nodes not associated with an already known channel are ignored, "to avoid trivial denial of service attacks", so an operator with nothing at stake never reaches anyone's map.

channel_update (type 258) carries the prices, one per direction, and it is the message that actually changes. Fees and the expiry delta live here, and when an operator raises a fee the spec recommends that same operator keep accepting the old parameters for at least 10 minutes, because the new one has to travel.

Propagation is deliberately unhurried. A node stores what it receives, replaces older updates from the same origin, and flushes the batch once every 60 seconds; the spec calls that a staggered broadcast, and it stops one busy operator from filling everybody's bandwidth.

Forgetting is specified too. Once a channel's funding output is spent, a node waits 72 block confirmations before dropping the channel, so a splice has time to announce itself rather than looking like a close. Separately, if the newest channel_update in either direction is older than two weeks (1,209,600 seconds), a node may prune the channel outright.

Where you see it

Gossip is the reason a freshly started Lightning node is useless for a while and then suddenly is not.

On connecting, a node asks for what it is missing: query_channel_range (type 263) to learn which channels exist across a span of blocks, query_short_channel_ids (261) to pull the specific ones it has never seen, and gossip_timestamp_filter (265) to set a time window on everything sent afterwards. That last message is a switch rather than a preference: until you send it, a peer forwards you nothing it did not generate itself, which is how a small device stays small.

The consequences reach your wallet as fees. A route quote is assembled from the channel_update messages your wallet happens to hold, so a stale view produces failed attempts and prices that do not match what you were shown. Phone wallets lean on somebody else's map: Phoenix runs a genuine self-custodial node on the handset but connects through ACINQ's own nodes, at the cost our review records, that ACINQ knows the destination and amount of your payments. A custodial account skips gossip completely, because the company routes for you.

Gossip protocol vs P2P messages

The gossip protocol runs between Lightning nodes; bitcoin's P2P messages run between bitcoin nodes, and the two share nothing beyond a habit of flooding.

A bitcoin node relays transactions and blocks with commands such as inv, getdata and tx, and knows nothing about anybody's channels. Lightning gossip is a separate conversation carrying message types 256 through 265, and it reaches into the blockchain only to check that an announced funding output is real and unspent. No payment is ever gossiped: amounts and destinations ride inside onion packets that intermediate nodes cannot read, so the public map says where channels are, never what moved through them.