Skip to content

Add a feature bit to allow nodes to opt-out of channel updates#218

Closed
Roasbeef wants to merge 2 commits intolightning:masterfrom
Roasbeef:no-chan-update
Closed

Add a feature bit to allow nodes to opt-out of channel updates#218
Roasbeef wants to merge 2 commits intolightning:masterfrom
Roasbeef:no-chan-update

Conversation

@Roasbeef
Copy link
Collaborator

@Roasbeef Roasbeef commented Aug 7, 2017

This PR adds a new section to the 7th BOLT document detailing a
mechanism that nodes can use to opt-out of dynamic channel updates.
Doing so is primarily a bandwidth optimization, as the node is able to
only receive announcements for new channels and nodes joining the
network, rather than announcements for each channel update within the
network.

Additionally, we propose the additional ability of a node to signal that
they don’t wish to receive any dynamic channel updates using an
unused feature bit in the init message.

This commit adds a new section to the 7th BOLT document detailing a
mechanism that nodes can use to opt-out of dynamic channel updates.
Doing so is primarily a bandwidth optimization, as the node is able to
only receive announcements for new channels and nodes joining the
network, rather than announcements for each channel update within the
network.
This commit adds the ability of a node to signal that they don’t wish
to receive any dynamic channel updates using an unused feature bit in
the init message.
@rustyrussell rustyrussell added this to the v1.1 milestone Aug 7, 2017
@rustyrussell
Copy link
Collaborator

Main points from discussion:

  1. This is a premature optimization.
  2. It's not something we want to encourage, as it's antisocial (such a node isn't useful for other nodes).
  3. We know we have to revisit syncing in 1.1 anyway ( @Roasbeef hates the term "dump"! )

So deferring until 1.1...

@cdecker
Copy link
Collaborator

cdecker commented Aug 17, 2017

I see the need to optimize bandwidth, however, if we go down this road, I'd like to broaden the bit to suppress all gossip messages, not just the updates. This could be used by slow/low-bandwidth nodes to designate a single node as source for its gossip data (by turning the bit off for that node) and suppress all other nodes.

@rustyrussell this concerns the gossip background noise during operation, not the dump-on-connect, for which we already have bit 3.

upon initial connection.

If a node receives an `init` message with the `no_channel_updates` flag set,
then the receiving not MUST NOT relay any channel update messages to the
Copy link

@jonathancross jonathancross Sep 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor typo: "...then the receiving node MUST NOT relay any..."

@t-bast
Copy link
Collaborator

t-bast commented Jan 21, 2020

Can we close this PR now that we have GossipTimestampFilters that achieve this (unless I'm missing something)?

@ysangkok
Copy link
Contributor

@Roasbeef, is this PR superseded by #641 ?

@t-bast t-bast closed this Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants