You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
CLN uses the
gossip_store
file as an append-only log of gossipmessages, public and private, which is managed by
gossipd
and isused by a variety of plugins using the
gossmap
infrastructure.
gossmap
reconstructs the network topology from thestored messages, and manages lifecycle management of edges and
vertices in the graph.
The messages contained within
gossip_store
are fundamentally of twotypes: 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:through the
short_channel_id
, which may be an alias withoption_scid_alias
. Restoring an oldgossip_store
can revive achannel that has since been closed, just because it still is in the
store.
gossip_store
file among multiple nodes is not possibleas 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.
The text was updated successfully, but these errors were encountered: