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

Include both `node_id`s in `BroadcastChannelUpdate`

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Include both `node_id`s in `BroadcastChannelUpdate`

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 a coming commit we'll start forwarding such gossip to all peers
by ignoring peer gossip limitations about all of our own channels.
While other gossip has the `node_id`s of both sides of the channel
explicitly in the message, `ChannelUpdate`s do not, so here we add
the `node_id`s to `BroadcastChannelUpdate` giving us the
information we need when we go to broadcast updates.
✓ 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 a preparatory refactor for a future Lightning Dev Kit change. It adds the two node IDs of a channel to the internal `BroadcastChannelUpdate` message event, but does not yet change any actual gossip-sending behavior. The goal is to later allow LDK to forward gossip about its own public channels even to peers that normally ask not to receive gossip. As it stands, this commit only carries extra metadata and updates call sites; it does not by itself fix or break security.

Recommended action

No immediate security action required. Monitor the follow-up commit that actually changes gossip broadcast filtering to ensure it only exempts the node's own public channels and does not accidentally bypass peer gossip limits for third-party gossip.

Security signals we found

01

Preparatory refactor for future gossip propagation change

02

Adds channel endpoint node IDs to internal broadcast event metadata

03

No change to wire protocol or cryptographic validation

04

No immediate change to which peers receive gossip

Risk score

Why this scored 22/100

Our methodology →
Potential impact 5/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/15
Confidence 8/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.