Struct P2PGossipSync

pub struct P2PGossipSync<G: Deref<Target = NetworkGraph<L>>, U: Deref, L: Deref>
where
    U::Target: UtxoLookup,
    L::Target: Logger,
{ /* private fields */ }

Receives and validates network updates from peers, stores authentic and relevant data as a network graph. This network graph is then used for routing payments. Provides interface to help with initial routing sync by serving historical announcements.

Implementations

impl<G: Deref<Target = NetworkGraph<L>>, U: Deref, L: Deref> P2PGossipSync<G, U, L>

where U::Target: UtxoLookup, L::Target: Logger,

pub fn new(network_graph: G, utxo_lookup: Option<U>, logger: L) -> Self

Creates a new tracker of the actual state of the network of channels and nodes, assuming an existing NetworkGraph. UTXO lookup is used to make sure announced channels exist on-chain, channel data is correct, and the announcement is signed with channel owners’ keys.

pub fn add_utxo_lookup(&self, utxo_lookup: Option<U>)

Adds a provider used to check new announcements. Does not affect existing announcements unless they are updated. Add, update or remove the provider would replace the current one.

pub fn network_graph(&self) -> &G

Gets a reference to the underlying NetworkGraph which was provided in P2PGossipSync::new.

This is not exported to bindings users as bindings don’t support a reference-to-a-reference yet

Trait Implementations

impl<G: Deref<Target = NetworkGraph<L>>, U: Deref, L: Deref> MessageSendEventsProvider for P2PGossipSync<G, U, L>

where U::Target: UtxoLookup, L::Target: Logger,

fn get_and_clear_pending_msg_events(&self) -> Vec<MessageSendEvent>

Gets the list of pending events which were generated by previous actions, clearing the list in the process.

impl<G: Deref<Target = NetworkGraph<L>>, U: Deref, L: Deref> RoutingMessageHandler for P2PGossipSync<G, U, L>

where U::Target: UtxoLookup, L::Target: Logger,

fn peer_connected( &self, their_node_id: &PublicKey, init_msg: &Init, _inbound: bool, ) -> Result<(), ()>

Initiates a stateless sync of routing gossip information with a peer using gossip_queries. The default strategy used by this implementation is to sync the full block range with several peers.

We should expect one or more reply_channel_range messages in response to our query_channel_range. Each reply will enqueue a query_scid message to request gossip messages for each channel. The sync is considered complete when the final reply_scids_end message is received, though we are not tracking this directly.

fn handle_query_channel_range( &self, their_node_id: &PublicKey, msg: QueryChannelRange, ) -> Result<(), LightningError>

Processes a query from a peer by finding announced/public channels whose funding UTXOs are in the specified block range. Due to message size limits, large range queries may result in several reply messages. This implementation enqueues all reply messages into pending events. Each message will allocate just under 65KiB. A full sync of the public routing table with 128k channels will generated 16 messages and allocate ~1MB. Logic can be changed to reduce allocation if/when a full sync of the routing table impacts memory constrained systems.

fn handle_node_announcement( &self, msg: &NodeAnnouncement, ) -> Result<bool, LightningError>

Handle an incoming node_announcement message, returning true if it should be forwarded on, false or returning an Err otherwise.

fn handle_channel_announcement( &self, msg: &ChannelAnnouncement, ) -> Result<bool, LightningError>

Handle a channel_announcement message, returning true if it should be forwarded on, false or returning an Err otherwise.

fn handle_channel_update( &self, msg: &ChannelUpdate, ) -> Result<bool, LightningError>

Handle an incoming channel_update message, returning true if it should be forwarded on, false or returning an Err otherwise.

fn get_next_channel_announcement( &self, starting_point: u64, ) -> Option<(ChannelAnnouncement, Option<ChannelUpdate>, Option<ChannelUpdate>)>

Gets channel announcements and updates required to dump our routing table to a remote node, starting at the short_channel_id indicated by starting_point and including announcements for a single channel.

fn get_next_node_announcement( &self, starting_point: Option<&NodeId>, ) -> Option<NodeAnnouncement>

Gets a node announcement required to dump our routing table to a remote node, starting at the node after the provided pubkey and including up to one announcement immediately higher (as defined by <PublicKey as Ord>::cmp) than starting_point. If None is provided for starting_point, we start at the first node.

fn handle_reply_channel_range( &self, _their_node_id: &PublicKey, _msg: ReplyChannelRange, ) -> Result<(), LightningError>

Handles the reply of a query we initiated to learn about channels for a given range of blocks. We can expect to receive one or more replies to a single query.

fn handle_reply_short_channel_ids_end( &self, _their_node_id: &PublicKey, _msg: ReplyShortChannelIdsEnd, ) -> Result<(), LightningError>

Handles the reply of a query we initiated asking for routing gossip messages for a list of channels. We should receive this message when a node has completed its best effort to send us the pertaining routing gossip messages.

fn handle_query_short_channel_ids( &self, _their_node_id: &PublicKey, _msg: QueryShortChannelIds, ) -> Result<(), LightningError>

Handles when a peer asks us to send routing gossip messages for a list of short_channel_ids.

fn provided_node_features(&self) -> NodeFeatures

Gets the node feature flags which this handler itself supports. All available handlers are queried similarly and their feature flags are OR’d together to form the NodeFeatures which are broadcasted in our NodeAnnouncement message.

fn provided_init_features(&self, _their_node_id: &PublicKey) -> InitFeatures

Gets the init feature flags which should be sent to the given peer. All available handlers are queried similarly and their feature flags are OR’d together to form the InitFeatures which are sent in our Init message.

fn processing_queue_high(&self) -> bool

Indicates that there are a large number of ChannelAnnouncement (or other) messages pending some async action. While there is no guarantee of the rate of future messages, the caller should seek to reduce the rate of new gossip messages handled, especially ChannelAnnouncements.