X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;ds=sidebyside;f=lightning%2Fsrc%2Fln%2Fmsgs.rs;h=073637413a82630866f8c7b3681683c883658375;hb=7a4a29ffe0dbfdd2fe82376024ae680401c74700;hp=9111a1ed657a544c9ca0709193e99c0069d967be;hpb=55e5aafcfe3b4d55df1fa500846e3a0f093f85c8;p=rust-lightning

diff --git a/lightning/src/ln/msgs.rs b/lightning/src/ln/msgs.rs
index 9111a1ed..07363741 100644
--- a/lightning/src/ln/msgs.rs
+++ b/lightning/src/ln/msgs.rs
@@ -827,27 +827,29 @@ pub trait RoutingMessageHandler : Send + Sync + events::MessageSendEventsProvide
 	fn get_next_node_announcements(&self, starting_point: Option<&PublicKey>, batch_amount: u8) -> Vec<NodeAnnouncement>;
 	/// Returns whether a full sync should be requested from a peer.
 	fn should_request_full_sync(&self, node_id: &PublicKey) -> bool;
-	/// Queries a peer for a list of channels with a funding UTXO in the requested
-	/// chain and range of blocks.
-	fn query_channel_range(&self, their_node_id: &PublicKey, chain_hash: BlockHash, first_blocknum: u32, number_of_blocks: u32) -> Result<(), LightningError>;
-	/// Queries a peer for routing gossip messages for a set of channels identified
-	/// by their short_channel_ids.
-	fn query_short_channel_ids(&self, their_node_id: &PublicKey, chain_hash: BlockHash, short_channel_ids: Vec<u64>) -> Result<(), LightningError>;
+	/// Initiates routing gossip sync by querying a peer to discover channels
+	/// and their associated routing gossip messages. This method will use a
+	/// sync strategy defined by the implementor.
+	fn sync_routing_table(&self, their_node_id: &PublicKey, init: &Init);
 	/// 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_channel_range(&self, their_node_id: &PublicKey, msg: &ReplyChannelRange) -> Result<(), LightningError>;
+	fn handle_reply_channel_range(&self, their_node_id: &PublicKey, msg: ReplyChannelRange) -> 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_reply_short_channel_ids_end(&self, their_node_id: &PublicKey, msg: &ReplyShortChannelIdsEnd) -> Result<(), LightningError>;
+	fn handle_reply_short_channel_ids_end(&self, their_node_id: &PublicKey, msg: ReplyShortChannelIdsEnd) -> Result<(), LightningError>;
 	/// Handles when a peer asks us to send a list of short_channel_ids
-	/// for the requested range of blocks.
-	fn handle_query_channel_range(&self, their_node_id: &PublicKey, msg: &QueryChannelRange) -> Result<(), LightningError>;
+	/// for the requested range of blocks. There are potential DoS vectors when
+	/// handling inbound queries. Handling requests with first_blocknum very far
+	/// away may trigger repeated disk I/O if the NetworkGraph is not fully in-memory.
+	fn handle_query_channel_range(&self, their_node_id: &PublicKey, msg: QueryChannelRange) -> Result<(), LightningError>;
 	/// Handles when a peer asks us to send routing gossip messages for a
-	/// list of short_channel_ids.
-	fn handle_query_short_channel_ids(&self, their_node_id: &PublicKey, msg: &QueryShortChannelIds) -> Result<(), LightningError>;
+	/// list of short_channel_ids. There are potential DoS vectors when handling
+	/// inbound queries. Handling requests with first_blocknum very far away may
+	/// trigger repeated disk I/O if the NetworkGraph is not fully in-memory.
+	fn handle_query_short_channel_ids(&self, their_node_id: &PublicKey, msg: QueryShortChannelIds) -> Result<(), LightningError>;
 }
 
 mod fuzzy_internal_msgs {