AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 29 Bitcoin

Pipe channel node information through to `forward_broadcast_msg`

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Pipe channel node information through to `forward_broadcast_msg`

Sadly, the lightning gossip protocol operates by always flooding
peers with all the latest gossip they receive. For nodes with many
peers, this can result in lots of duplicative gossip as they
receive every message from every peer. As a results, some lightning
implementations disable gossip with new peers after some threshold.
This should mostly work as these peers expect to receive the latest
gossip from their many other peers.

However, in some cases an LDK node may wish to open public
channels but only has a single connection to the bulk of the rest
of the network - with one such peer which requests that it not
receive any gossip. In that case, LDK would dutifully never send
any gossip to its only connection to the outside world. We would
still send gossip for channels with that peer as it would be sent
as unicast gossip, but if we then open another connection to
another peer which doesn't have any connection to the outside world
any information on that channel wouldn't propagate.

We've seen this setup on some LSPs, where they have a public node
and then an LSP which only connects through that public node, but
expects to open public channels to its LSP clients.

In the next commit we'll start forwarding such gossip to all peers
by ignoring peer gossip limitations about all of our own channels.
Here we do the final prep work, passing the two sides of each
channel back from `handle_channel_update` calls and into
`forward_broadcast_msg`.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is preparatory plumbing for a future fix. It changes how Lightning gossip messages are internally forwarded so that the peer handler knows which two nodes are on each side of a channel. The commit itself does not change any forwarding rules, but the next commit is expected to use this information to ensure a node always forwards gossip about its own public channels, even to peers that have asked to stop receiving gossip. That addresses a real-world routing problem where LSPs could become isolated from the wider network, but it is not a direct security vulnerability and does not introduce one.

Recommended action

Review the follow-up commit that actually modifies `forward_broadcast_msg` to bypass gossip throttling for the node's own channels. Verify that the bypass is scoped strictly to channels where the local node is a counterparty and that it does not weaken DoS protections against excess-data or invalid gossip. No immediate action is required for this commit alone.

Security signals we found

01

Refactor of gossip broadcast forwarding path

02

New internal message enum carries channel endpoint node IDs

03

Return-type change exposes channel participants to peer handler

04

Commit message describes real-world LSP routing isolation scenario

05

No functional forwarding-rule change in this commit

Risk score

Why this scored 29/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 6/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.