From 963d6c4a51bdbbd1598d85d4657fe9f8d81f3cb5 Mon Sep 17 00:00:00 2001 From: "Allan Douglas R. de Oliveira" Date: Tue, 14 Mar 2023 19:54:44 +0000 Subject: [PATCH] Docs improvements --- fuzz/src/full_stack.rs | 2 +- lightning-invoice/src/utils.rs | 8 +- lightning/src/ln/chan_utils.rs | 2 +- lightning/src/ln/channelmanager.rs | 144 +++++++++++++++++------------ lightning/src/ln/mod.rs | 14 +-- lightning/src/ln/peer_handler.rs | 29 +++--- lightning/src/ln/wire.rs | 2 +- lightning/src/routing/gossip.rs | 16 +++- 8 files changed, 119 insertions(+), 98 deletions(-) diff --git a/fuzz/src/full_stack.rs b/fuzz/src/full_stack.rs index 05ae32e4c..c520d99fd 100644 --- a/fuzz/src/full_stack.rs +++ b/fuzz/src/full_stack.rs @@ -861,7 +861,7 @@ mod tests { // 0085 3d00000000000000000000000000000000000000000000000000000000000000 0900000000000000000000000000000000000000000000000000000000000000 020b00000000000000000000000000000000000000000000000000000000000000 03000000000000000000000000000000 - revoke_and_ack and mac // // 07 - process the now-pending HTLC forward - // - client now sends id 1 update_add_htlc and commitment_signed (CHECK 7: SendHTLCs event for node 03020000 with 1 HTLCs for channel 3f000000) + // - client now sends id 1 update_add_htlc and commitment_signed (CHECK 7: UpdateHTLCs event for node 03020000 with 1 HTLCs for channel 3f000000) // // - we respond with commitment_signed then revoke_and_ack (a weird, but valid, order) // 030112 - inbound read from peer id 1 of len 18 diff --git a/lightning-invoice/src/utils.rs b/lightning-invoice/src/utils.rs index f837502e3..2a328f7a1 100644 --- a/lightning-invoice/src/utils.rs +++ b/lightning-invoice/src/utils.rs @@ -38,7 +38,7 @@ use core::time::Duration; /// /// `invoice_expiry_delta_secs` describes the number of seconds that the invoice is valid for /// in excess of the current time. -/// +/// /// `duration_since_epoch` is the current time since epoch in seconds. /// /// You can specify a custom `min_final_cltv_expiry_delta`, or let LDK default it to @@ -56,7 +56,7 @@ use core::time::Duration; /// [`ChannelManager::create_inbound_payment_for_hash`]: lightning::ln::channelmanager::ChannelManager::create_inbound_payment_for_hash /// [`PhantomRouteHints::channels`]: lightning::ln::channelmanager::PhantomRouteHints::channels /// [`MIN_FINAL_CLTV_EXPIRY_DETLA`]: lightning::ln::channelmanager::MIN_FINAL_CLTV_EXPIRY_DELTA -/// +/// /// This can be used in a `no_std` environment, where [`std::time::SystemTime`] is not /// available and the current time is supplied by the caller. pub fn create_phantom_invoice( @@ -98,7 +98,7 @@ where /// /// `invoice_expiry_delta_secs` describes the number of seconds that the invoice is valid for /// in excess of the current time. -/// +/// /// `duration_since_epoch` is the current time since epoch in seconds. /// /// Note that the provided `keys_manager`'s `NodeSigner` implementation must support phantom @@ -110,7 +110,7 @@ where /// [`ChannelManager::create_inbound_payment`]: lightning::ln::channelmanager::ChannelManager::create_inbound_payment /// [`ChannelManager::create_inbound_payment_for_hash`]: lightning::ln::channelmanager::ChannelManager::create_inbound_payment_for_hash /// [`PhantomRouteHints::channels`]: lightning::ln::channelmanager::PhantomRouteHints::channels -/// +/// /// This can be used in a `no_std` environment, where [`std::time::SystemTime`] is not /// available and the current time is supplied by the caller. pub fn create_phantom_invoice_with_description_hash( diff --git a/lightning/src/ln/chan_utils.rs b/lightning/src/ln/chan_utils.rs index 378b4d794..acf9539d7 100644 --- a/lightning/src/ln/chan_utils.rs +++ b/lightning/src/ln/chan_utils.rs @@ -8,7 +8,7 @@ // licenses. //! Various utilities for building scripts and deriving keys related to channels. These are -//! largely of interest for those implementing chain::keysinterface::Sign message signing by hand. +//! largely of interest for those implementing the traits on [`chain::keysinterface`] by hand. use bitcoin::blockdata::script::{Script,Builder}; use bitcoin::blockdata::opcodes; diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs index c4ebc8bc3..89cb317dc 100644 --- a/lightning/src/ln/channelmanager.rs +++ b/lightning/src/ln/channelmanager.rs @@ -9,7 +9,7 @@ //! The top-level channel management and payment tracking stuff lives here. //! -//! The ChannelManager is the main chunk of logic implementing the lightning protocol and is +//! The [`ChannelManager`] is the main chunk of logic implementing the lightning protocol and is //! responsible for tracking which channels are open, HTLCs are in flight and reestablishing those //! upon reconnect to the relevant peer(s). //! @@ -559,13 +559,14 @@ struct PendingInboundPayment { min_value_msat: Option, } -/// SimpleArcChannelManager is useful when you need a ChannelManager with a static lifetime, e.g. -/// when you're using lightning-net-tokio (since tokio::spawn requires parameters with static +/// [`SimpleArcChannelManager`] is useful when you need a [`ChannelManager`] with a static lifetime, e.g. +/// when you're using `lightning-net-tokio` (since `tokio::spawn` requires parameters with static /// lifetimes). Other times you can afford a reference, which is more efficient, in which case -/// SimpleRefChannelManager is the more appropriate type. Defining these type aliases prevents -/// issues such as overly long function definitions. Note that the ChannelManager can take any type -/// that implements KeysInterface or Router for its keys manager and router, respectively, but this -/// type alias chooses the concrete types of KeysManager and DefaultRouter. +/// [`SimpleRefChannelManager`] is the more appropriate type. Defining these type aliases prevents +/// issues such as overly long function definitions. Note that the `ChannelManager` can take any type +/// that implements [`NodeSigner`], [`EntropySource`], and [`SignerProvider`] for its keys manager, +/// or, respectively, [`Router`] for its router, but this type alias chooses the concrete types +/// of [`KeysManager`] and [`DefaultRouter`]. /// /// (C-not exported) as Arcs don't make sense in bindings pub type SimpleArcChannelManager = ChannelManager< @@ -583,14 +584,15 @@ pub type SimpleArcChannelManager = ChannelManager< Arc >; -/// SimpleRefChannelManager is a type alias for a ChannelManager reference, and is the reference -/// counterpart to the SimpleArcChannelManager type alias. Use this type by default when you don't +/// [`SimpleRefChannelManager`] is a type alias for a ChannelManager reference, and is the reference +/// counterpart to the [`SimpleArcChannelManager`] type alias. Use this type by default when you don't /// need a ChannelManager with a static lifetime. You'll need a static lifetime in cases such as -/// usage of lightning-net-tokio (since tokio::spawn requires parameters with static lifetimes). +/// usage of lightning-net-tokio (since `tokio::spawn` requires parameters with static lifetimes). /// But if this is not necessary, using a reference is more efficient. Defining these type aliases /// issues such as overly long function definitions. Note that the ChannelManager can take any type -/// that implements KeysInterface or Router for its keys manager and router, respectively, but this -/// type alias chooses the concrete types of KeysManager and DefaultRouter. +/// that implements [`NodeSigner`], [`EntropySource`], and [`SignerProvider`] for its keys manager, +/// or, respectively, [`Router`] for its router, but this type alias chooses the concrete types +/// of [`KeysManager`] and [`DefaultRouter`]. /// /// (C-not exported) as Arcs don't make sense in bindings pub type SimpleRefChannelManager<'a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, M, T, F, L> = ChannelManager<&'a M, &'b T, &'c KeysManager, &'c KeysManager, &'c KeysManager, &'d F, &'e DefaultRouter<&'f NetworkGraph<&'g L>, &'g L, &'h Mutex, &'g L>>>, &'g L>; @@ -598,35 +600,33 @@ pub type SimpleRefChannelManager<'a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, M, T, F, L> = C /// Manager which keeps track of a number of channels and sends messages to the appropriate /// channel, also tracking HTLC preimages and forwarding onion packets appropriately. /// -/// Implements ChannelMessageHandler, handling the multi-channel parts and passing things through +/// Implements [`ChannelMessageHandler`], handling the multi-channel parts and passing things through /// to individual Channels. /// -/// Implements Writeable to write out all channel state to disk. Implies peer_disconnected() for +/// Implements [`Writeable`] to write out all channel state to disk. Implies [`peer_disconnected`] for /// all peers during write/read (though does not modify this instance, only the instance being -/// serialized). This will result in any channels which have not yet exchanged funding_created (ie -/// called funding_transaction_generated for outbound channels). +/// serialized). This will result in any channels which have not yet exchanged [`funding_created`] (i.e., +/// called [`funding_transaction_generated`] for outbound channels) being closed. /// -/// Note that you can be a bit lazier about writing out ChannelManager than you can be with -/// ChannelMonitors. With ChannelMonitors you MUST write each monitor update out to disk before -/// returning from chain::Watch::watch_/update_channel, with ChannelManagers, writing updates -/// happens out-of-band (and will prevent any other ChannelManager operations from occurring during +/// Note that you can be a bit lazier about writing out `ChannelManager` than you can be with +/// [`ChannelMonitor`]. With [`ChannelMonitor`] you MUST write each monitor update out to disk before +/// returning from [`chain::Watch::watch_channel`]/[`update_channel`], with ChannelManagers, writing updates +/// happens out-of-band (and will prevent any other `ChannelManager` operations from occurring during /// the serialization process). If the deserialized version is out-of-date compared to the -/// ChannelMonitors passed by reference to read(), those channels will be force-closed based on the -/// ChannelMonitor state and no funds will be lost (mod on-chain transaction fees). +/// [`ChannelMonitor`] passed by reference to [`read`], those channels will be force-closed based on the +/// `ChannelMonitor` state and no funds will be lost (mod on-chain transaction fees). /// -/// Note that the deserializer is only implemented for (BlockHash, ChannelManager), which -/// tells you the last block hash which was block_connect()ed. You MUST rescan any blocks along -/// the "reorg path" (ie call block_disconnected() until you get to a common block and then call -/// block_connected() to step towards your best block) upon deserialization before using the -/// object! +/// Note that the deserializer is only implemented for `(`[`BlockHash`]`, `[`ChannelManager`]`)`, which +/// tells you the last block hash which was connected. You should get the best block tip before using the manager. +/// See [`chain::Listen`] and [`chain::Confirm`] for more details. /// -/// Note that ChannelManager is responsible for tracking liveness of its channels and generating -/// ChannelUpdate messages informing peers that the channel is temporarily disabled. To avoid +/// Note that `ChannelManager` is responsible for tracking liveness of its channels and generating +/// [`ChannelUpdate`] messages informing peers that the channel is temporarily disabled. To avoid /// spam due to quick disconnection/reconnection, updates are not sent until the channel has been /// offline for a full minute. In order to track this, you must call -/// timer_tick_occurred roughly once per minute, though it doesn't have to be perfect. +/// [`timer_tick_occurred`] roughly once per minute, though it doesn't have to be perfect. /// -/// To avoid trivial DoS issues, ChannelManager limits the number of inbound connections and +/// To avoid trivial DoS issues, `ChannelManager` limits the number of inbound connections and /// inbound channels without confirmed funding transactions. This may result in nodes which we do /// not have a channel with being unable to connect to us or open new channels with us if we have /// many peers with unfunded channels. @@ -635,11 +635,20 @@ pub type SimpleRefChannelManager<'a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, M, T, F, L> = C /// exempted from the count of unfunded channels. Similarly, outbound channels and connections are /// never limited. Please ensure you limit the count of such channels yourself. /// -/// Rather than using a plain ChannelManager, it is preferable to use either a SimpleArcChannelManager -/// a SimpleRefChannelManager, for conciseness. See their documentation for more details, but -/// essentially you should default to using a SimpleRefChannelManager, and use a -/// SimpleArcChannelManager when you require a ChannelManager with a static lifetime, such as when +/// Rather than using a plain `ChannelManager`, it is preferable to use either a [`SimpleArcChannelManager`] +/// a [`SimpleRefChannelManager`], for conciseness. See their documentation for more details, but +/// essentially you should default to using a [`SimpleRefChannelManager`], and use a +/// [`SimpleArcChannelManager`] when you require a `ChannelManager` with a static lifetime, such as when /// you're using lightning-net-tokio. +/// +/// [`peer_disconnected`]: msgs::ChannelMessageHandler::peer_disconnected +/// [`funding_created`]: msgs::FundingCreated +/// [`funding_transaction_generated`]: Self::funding_transaction_generated +/// [`BlockHash`]: bitcoin::hash_types::BlockHash +/// [`update_channel`]: chain::Watch::update_channel +/// [`ChannelUpdate`]: msgs::ChannelUpdate +/// [`timer_tick_occurred`]: Self::timer_tick_occurred +/// [`read`]: ReadableArgs::read // // Lock order: // The tree structure below illustrates the lock order requirements for the different locks of the @@ -1040,7 +1049,7 @@ pub struct ChannelCounterparty { pub outbound_htlc_maximum_msat: Option, } -/// Details of a channel, as returned by ChannelManager::list_channels and ChannelManager::list_usable_channels +/// Details of a channel, as returned by [`ChannelManager::list_channels`] and [`ChannelManager::list_usable_channels`] #[derive(Clone, Debug, PartialEq)] pub struct ChannelDetails { /// The channel's ID (prior to funding transaction generation, this is a random 32 bytes, @@ -1585,16 +1594,21 @@ where R::Target: Router, L::Target: Logger, { - /// Constructs a new ChannelManager to hold several channels and route between them. + /// Constructs a new `ChannelManager` to hold several channels and route between them. /// /// This is the main "logic hub" for all channel-related actions, and implements - /// ChannelMessageHandler. + /// [`ChannelMessageHandler`]. /// /// Non-proportional fees are fixed according to our risk using the provided fee estimator. /// - /// Users need to notify the new ChannelManager when a new block is connected or - /// disconnected using its `block_connected` and `block_disconnected` methods, starting - /// from after `params.latest_hash`. + /// Users need to notify the new `ChannelManager` when a new block is connected or + /// disconnected using its [`block_connected`] and [`block_disconnected`] methods, starting + /// from after [`params.best_block.block_hash`]. See [`chain::Listen`] and [`chain::Confirm`] for + /// more details. + /// + /// [`block_connected`]: chain::Listen::block_connected + /// [`block_disconnected`]: chain::Listen::block_disconnected + /// [`params.best_block.block_hash`]: chain::BestBlock::block_hash pub fn new(fee_est: F, chain_monitor: M, tx_broadcaster: T, router: R, logger: L, entropy_source: ES, node_signer: NS, signer_provider: SP, config: UserConfig, params: ChainParameters) -> Self { let mut secp_ctx = Secp256k1::new(); secp_ctx.seeded_randomize(&entropy_source.get_secure_random_bytes()); @@ -1768,7 +1782,7 @@ where res } - /// Gets the list of open channels, in random order. See ChannelDetail field documentation for + /// Gets the list of open channels, in random order. See [`ChannelDetails`] field documentation for /// more information. pub fn list_channels(&self) -> Vec { self.list_channels_with_filter(|_| true) @@ -1921,11 +1935,12 @@ where /// would appear on a force-closure transaction, whichever is lower. We will allow our /// counterparty to pay as much fee as they'd like, however. /// - /// May generate a SendShutdown message event on success, which should be relayed. + /// May generate a [`SendShutdown`] message event on success, which should be relayed. /// /// [`ChannelConfig::force_close_avoidance_max_fee_satoshis`]: crate::util::config::ChannelConfig::force_close_avoidance_max_fee_satoshis /// [`Background`]: crate::chain::chaininterface::ConfirmationTarget::Background /// [`Normal`]: crate::chain::chaininterface::ConfirmationTarget::Normal + /// [`SendShutdown`]: crate::util::events::MessageSendEvent::SendShutdown pub fn close_channel(&self, channel_id: &[u8; 32], counterparty_node_id: &PublicKey) -> Result<(), APIError> { self.close_channel_internal(channel_id, counterparty_node_id, None) } @@ -1944,11 +1959,12 @@ where /// transaction feerate below `target_feerate_sat_per_1000_weight` (or the feerate which /// will appear on a force-closure transaction, whichever is lower). /// - /// May generate a SendShutdown message event on success, which should be relayed. + /// May generate a [`SendShutdown`] message event on success, which should be relayed. /// /// [`ChannelConfig::force_close_avoidance_max_fee_satoshis`]: crate::util::config::ChannelConfig::force_close_avoidance_max_fee_satoshis /// [`Background`]: crate::chain::chaininterface::ConfirmationTarget::Background /// [`Normal`]: crate::chain::chaininterface::ConfirmationTarget::Normal + /// [`SendShutdown`]: crate::util::events::MessageSendEvent::SendShutdown pub fn close_channel_with_target_feerate(&self, channel_id: &[u8; 32], counterparty_node_id: &PublicKey, target_feerate_sats_per_1000_weight: u32) -> Result<(), APIError> { self.close_channel_internal(channel_id, counterparty_node_id, Some(target_feerate_sats_per_1000_weight)) } @@ -2393,13 +2409,16 @@ where pending_forward_info } - /// Gets the current channel_update for the given channel. This first checks if the channel is + /// Gets the current [`channel_update`] for the given channel. This first checks if the channel is /// public, and thus should be called whenever the result is going to be passed out in a /// [`MessageSendEvent::BroadcastChannelUpdate`] event. /// - /// Note that in `internal_closing_signed`, this function is called without the `peer_state` + /// Note that in [`internal_closing_signed`], this function is called without the `peer_state` /// corresponding to the channel's counterparty locked, as the channel been removed from the /// storage and the `peer_state` lock has been dropped. + /// + /// [`channel_update`]: msgs::ChannelUpdate + /// [`internal_closing_signed`]: Self::internal_closing_signed fn get_channel_update_for_broadcast(&self, chan: &Channel<::Signer>) -> Result { if !chan.should_announce() { return Err(LightningError { @@ -2414,14 +2433,17 @@ where self.get_channel_update_for_unicast(chan) } - /// Gets the current channel_update for the given channel. This does not check if the channel - /// is public (only returning an Err if the channel does not yet have an assigned short_id), + /// Gets the current [`channel_update`] for the given channel. This does not check if the channel + /// is public (only returning an `Err` if the channel does not yet have an assigned SCID), /// and thus MUST NOT be called unless the recipient of the resulting message has already /// provided evidence that they know about the existence of the channel. /// - /// Note that through `internal_closing_signed`, this function is called without the + /// Note that through [`internal_closing_signed`], this function is called without the /// `peer_state` corresponding to the channel's counterparty locked, as the channel been /// removed from the storage and the `peer_state` lock has been dropped. + /// + /// [`channel_update`]: msgs::ChannelUpdate + /// [`internal_closing_signed`]: Self::internal_closing_signed fn get_channel_update_for_unicast(&self, chan: &Channel<::Signer>) -> Result { log_trace!(self.logger, "Attempting to generate channel update for channel {}", log_bytes!(chan.channel_id())); let short_channel_id = match chan.get_short_channel_id().or(chan.latest_inbound_scid_alias()) { @@ -2547,7 +2569,7 @@ where /// Value parameters are provided via the last hop in route, see documentation for [`RouteHop`] /// fields for more info. /// - /// May generate SendHTLCs message(s) event on success, which should be relayed (e.g. via + /// May generate [`UpdateHTLCs`] message(s) event on success, which should be relayed (e.g. via /// [`PeerManager::process_events`]). /// /// # Avoiding Duplicate Payments @@ -2571,7 +2593,7 @@ where /// /// # Possible Error States on [`PaymentSendFailure`] /// - /// Each path may have a different return value, and PaymentSendValue may return a Vec with + /// Each path may have a different return value, and [`PaymentSendFailure`] may return a `Vec` with /// each entry matching the corresponding-index entry in the route paths, see /// [`PaymentSendFailure`] for more info. /// @@ -2584,7 +2606,7 @@ where /// * [`APIError::MonitorUpdateInProgress`] if a new monitor update failure prevented sending the /// relevant updates. /// - /// Note that depending on the type of the PaymentSendFailure the HTLC may have been + /// Note that depending on the type of the [`PaymentSendFailure`] the HTLC may have been /// irrevocably committed to on our end. In such a case, do NOT retry the payment with a /// different route unless you intend to pay twice! /// @@ -2602,6 +2624,7 @@ where /// /// [`Event::PaymentSent`]: events::Event::PaymentSent /// [`Event::PaymentFailed`]: events::Event::PaymentFailed + /// [`UpdateHTLCs`]: events::MessageSendEvent::UpdateHTLCs /// [`PeerManager::process_events`]: crate::ln::peer_handler::PeerManager::process_events /// [`ChannelMonitorUpdateStatus::InProgress`]: crate::chain::ChannelMonitorUpdateStatus::InProgress pub fn send_payment(&self, route: &Route, payment_hash: PaymentHash, payment_secret: &Option, payment_id: PaymentId) -> Result<(), PaymentSendFailure> { @@ -3538,15 +3561,18 @@ where /// /// This currently includes: /// * Increasing or decreasing the on-chain feerate estimates for our outbound channels, - /// * Broadcasting `ChannelUpdate` messages if we've been disconnected from our peer for more + /// * Broadcasting [`ChannelUpdate`] messages if we've been disconnected from our peer for more /// than a minute, informing the network that they should no longer attempt to route over /// the channel. - /// * Expiring a channel's previous `ChannelConfig` if necessary to only allow forwarding HTLCs - /// with the current `ChannelConfig`. + /// * Expiring a channel's previous [`ChannelConfig`] if necessary to only allow forwarding HTLCs + /// with the current [`ChannelConfig`]. /// * Removing peers which have disconnected but and no longer have any channels. /// - /// Note that this may cause reentrancy through `chain::Watch::update_channel` calls or feerate + /// Note that this may cause reentrancy through [`chain::Watch::update_channel`] calls or feerate /// estimate fetches. + /// + /// [`ChannelUpdate`]: msgs::ChannelUpdate + /// [`ChannelConfig`]: crate::util::config::ChannelConfig pub fn timer_tick_occurred(&self) { PersistenceNotifierGuard::optionally_notify(&self.total_consistency_lock, &self.persistence_notifier, || { let mut should_persist = NotifyOption::SkipPersist; @@ -5160,7 +5186,7 @@ where Ok(()) } - /// Process pending events from the `chain::Watch`, returning whether any events were processed. + /// Process pending events from the [`chain::Watch`], returning whether any events were processed. fn process_pending_monitor_events(&self) -> bool { debug_assert!(self.total_consistency_lock.try_write().is_err()); // Caller holds read lock @@ -6487,8 +6513,8 @@ pub(crate) fn provided_channel_type_features(config: &UserConfig) -> ChannelType /// [`ChannelManager`]. pub fn provided_init_features(_config: &UserConfig) -> InitFeatures { // Note that if new features are added here which other peers may (eventually) require, we - // should also add the corresponding (optional) bit to the ChannelMessageHandler impl for - // ErroringMessageHandler. + // should also add the corresponding (optional) bit to the [`ChannelMessageHandler`] impl for + // [`ErroringMessageHandler`]. let mut features = InitFeatures::empty(); features.set_data_loss_protect_optional(); features.set_upfront_shutdown_script_optional(); diff --git a/lightning/src/ln/mod.rs b/lightning/src/ln/mod.rs index bc2806314..f328f6b9c 100644 --- a/lightning/src/ln/mod.rs +++ b/lightning/src/ln/mod.rs @@ -7,19 +7,7 @@ // You may not use this file except in accordance with one or both of these // licenses. -//! High level lightning structs and impls live here. -//! -//! You probably want to create a [`ChannelManager`], and a [`P2PGossipSync`] first. -//! Then, you probably want to pass them both on to a peer_handler::PeerManager and use that to -//! create/manage connections and call get_and_clear_pending_events after each action, handling -//! them appropriately. -//! -//! When you want to open/close a channel or send a payment, call into your [`ChannelManager`] and -//! when you want to learn things about the network topology (eg get a route for sending a payment), -//! call into your [`P2PGossipSync`]. -//! -//! [`ChannelManager`]: channelmanager::ChannelManager -//! [`P2PGossipSync`]: crate::routing::gossip::P2PGossipSync +//! Implementations of various parts of the Lightning protocol are in this module. #[cfg(any(test, feature = "_test_utils"))] #[macro_use] diff --git a/lightning/src/ln/peer_handler.rs b/lightning/src/ln/peer_handler.rs index edc9c68a5..913ece646 100644 --- a/lightning/src/ln/peer_handler.rs +++ b/lightning/src/ln/peer_handler.rs @@ -284,7 +284,7 @@ pub struct MessageHandler where /// to a remote host. You will need to be able to generate multiple of these which meet Eq and /// implement Hash to meet the PeerManager API. /// -/// For efficiency, Clone should be relatively cheap for this type. +/// For efficiency, [`Clone`] should be relatively cheap for this type. /// /// Two descriptors may compare equal (by [`cmp::Eq`] and [`hash::Hash`]) as long as the original /// has been disconnected, the [`PeerManager`] has been informed of the disconnection (either by it @@ -547,10 +547,10 @@ pub type SimpleRefPeerManager<'a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j, 'k, 'l, 'm /// [`PeerManager`] functions related to the same connection must occur only in serial, making new /// calls only after previous ones have returned. /// -/// Rather than using a plain PeerManager, it is preferable to use either a SimpleArcPeerManager -/// a SimpleRefPeerManager, for conciseness. See their documentation for more details, but -/// essentially you should default to using a SimpleRefPeerManager, and use a -/// SimpleArcPeerManager when you require a PeerManager with a static lifetime, such as when +/// Rather than using a plain [`PeerManager`], it is preferable to use either a [`SimpleArcPeerManager`] +/// a [`SimpleRefPeerManager`], for conciseness. See their documentation for more details, but +/// essentially you should default to using a [`SimpleRefPeerManager`], and use a +/// [`SimpleArcPeerManager`] when you require a `PeerManager` with a static lifetime, such as when /// you're using lightning-net-tokio. /// /// [`read_event`]: PeerManager::read_event @@ -638,7 +638,7 @@ impl Pe /// `OnionMessageHandler`. No routing message handler is used and network graph messages are /// ignored. /// - /// ephemeral_random_data is used to derive per-connection ephemeral keys and must be + /// `ephemeral_random_data` is used to derive per-connection ephemeral keys and must be /// cryptographically secure random bytes. /// /// `current_time` is used as an always-increasing counter that survives across restarts and is @@ -670,7 +670,7 @@ impl PeerManager) -> Result, PeerHandleError> { let mut peer_encryptor = PeerChannelEncryptor::new_outbound(their_node_id.clone(), self.get_ephemeral_key()); let res = peer_encryptor.get_act_one(&self.secp_ctx).to_vec(); @@ -863,9 +864,9 @@ impl) -> Result<(), PeerHandleError> { let peer_encryptor = PeerChannelEncryptor::new_inbound(&self.node_signer); let pending_read_buffer = [0; 50].to_vec(); // Noise act one is 50 bytes @@ -1011,7 +1012,7 @@ impl TestEq for T {} -/// A Lightning message returned by [`read()`] when decoding bytes received over the wire. Each +/// A Lightning message returned by [`read`] when decoding bytes received over the wire. Each /// variant contains a message from [`msgs`] or otherwise the message type if unknown. #[allow(missing_docs)] #[derive(Debug)] diff --git a/lightning/src/routing/gossip.rs b/lightning/src/routing/gossip.rs index 3f9313c68..48fcd8157 100644 --- a/lightning/src/routing/gossip.rs +++ b/lightning/src/routing/gossip.rs @@ -234,7 +234,7 @@ impl>, U: Deref, L: Deref> P2PGossipSync, logger: L) -> Self { @@ -432,14 +432,20 @@ where U::Target: UtxoLookup, L::Target: Logger } /// Initiates a stateless sync of routing gossip information with a peer - /// using gossip_queries. The default strategy used by this implementation + /// 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 + /// 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 + /// when the final [`reply_scids_end`] message is received, though we are not /// tracking this directly. + /// + /// [`gossip_queries`]: https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#query-messages + /// [`reply_channel_range`]: msgs::ReplyChannelRange + /// [`query_channel_range`]: msgs::QueryChannelRange + /// [`query_scid`]: msgs::QueryShortChannelIds + /// [`reply_scids_end`]: msgs::ReplyShortChannelIdsEnd fn peer_connected(&self, their_node_id: &PublicKey, init_msg: &Init, _inbound: bool) -> Result<(), ()> { // We will only perform a sync with peers that support gossip_queries. if !init_msg.features.supports_gossip_queries() { -- 2.39.5