Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

track: Split private from public gossip #6981

Closed
cdecker opened this issue Jan 8, 2024 · 1 comment
Closed

track: Split private from public gossip #6981

cdecker opened this issue Jan 8, 2024 · 1 comment
Assignees

Comments

@cdecker
Copy link
Member

cdecker commented Jan 8, 2024

CLN uses the gossip_store file as an append-only log of gossip
messages, public and private, which is managed by gossipd and is
used by a variety of plugins using the gossmap
infrastructure. gossmap reconstructs the network topology from the
stored messages, and manages lifecycle management of edges and
vertices in the graph.

The messages contained within gossip_store are fundamentally of two
types: public messages relating to publicly announced channels and
nodes, and private messages relating to unannounced or not yet
announced channels and nodes.

The private messages are necessary for things such as routing before
the channel reaches the 6 confirmations required by the spec,
or to provide routehints to hint at an unannounced incoming channel. While it is not really dangerous to leak these messages to other nodes, they wouldn't be of much use to them.

Mixing the private and public messages in gossip_store has a number of disadvantages:

  • Metadata on local channels is bound to the underlying channel only
    through the short_channel_id, which may be an alias with
    option_scid_alias. Restoring an old gossip_store can revive a
    channel that has since been closed, just because it still is in the
    store.
  • Sharing a gossip_store file among multiple nodes is not possible
    as long as it contains private messages. This is interesting for
    either a large fleet of nodes, that could share a single store, or
    in case nodes need to quickly start up, it'd be possible to copy
    another node's store to quickly sync up.

The goal therefore is to either create two stores, one private and one
public, or store the private messages alongside the entities they
describe in the main daemon's DB.

@cdecker
Copy link
Member Author

cdecker commented Jun 13, 2024

This has been released with v24.05

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

No branches or pull requests

3 participants