From 4cb4d66e1b5f2323da43718eebc78e295090cf8e Mon Sep 17 00:00:00 2001 From: Elias Rohrer Date: Tue, 17 Dec 2024 11:06:15 +0100 Subject: [PATCH 1/4] Address doc nits We address some minor mistakes that made it into the docs before. --- lightning-liquidity/README.md | 8 +++++--- lightning-liquidity/src/lib.rs | 7 ++++--- lightning-liquidity/src/lsps0/client.rs | 2 +- lightning-liquidity/src/lsps0/msgs.rs | 2 +- lightning-liquidity/src/manager.rs | 9 +++++++-- 5 files changed, 18 insertions(+), 10 deletions(-) diff --git a/lightning-liquidity/README.md b/lightning-liquidity/README.md index ace18ca0a13..b3b8f602243 100644 --- a/lightning-liquidity/README.md +++ b/lightning-liquidity/README.md @@ -6,9 +6,11 @@ Currently the following specifications are supported: - [LSPS0] defines the transport protocol with the LSP over which the other protocols communicate. - [LSPS1] allows to order Lightning channels from an LSP. This is useful when the client needs inbound Lightning liquidity for which they are willing and able to pay in bitcoin. -- [LSPS2] allows to generate a special invoice for which, when paid, an LSP will open a "just-in-time". -This is useful for the initial on-boarding of clients as the channel opening fees are deducted -from the incoming payment, i.e., no funds are required client-side to initiate this flow. +- [LSPS2] allows to generate a special invoice for which, when paid, an LSP + will open a "just-in-time" channel. This is useful for the initial + on-boarding of clients as the channel opening fees are deducted from the + incoming payment, i.e., no funds are required client-side to initiate this + flow. To get started, you'll want to setup a `LiquidityManager` and configure it to be the `CustomMessageHandler` of your LDK node. You can then call `LiquidityManager::lsps1_client_handler` / `LiquidityManager::lsps2_client_handler`, or `LiquidityManager::lsps2_service_handler`, to access the respective client-side or service-side handlers. diff --git a/lightning-liquidity/src/lib.rs b/lightning-liquidity/src/lib.rs index 369972a1339..23472a467e6 100644 --- a/lightning-liquidity/src/lib.rs +++ b/lightning-liquidity/src/lib.rs @@ -14,9 +14,10 @@ //! - [LSPS0] defines the transport protocol with the LSP over which the other protocols communicate. //! - [LSPS1] allows to order Lightning channels from an LSP. This is useful when the client needs //! inbound Lightning liquidity for which they are willing and able to pay in bitcoin. -//! - [LSPS2] allows to generate a special invoice for which, when paid, an LSP will open a "just-in-time". -//! This is useful for the initial on-boarding of clients as the channel opening fees are deducted -//! from the incoming payment, i.e., no funds are required client-side to initiate this flow. +//! - [LSPS2] allows to generate a special invoice for which, when paid, an LSP will open a +//! "just-in-time" channel. This is useful for the initial on-boarding of clients as the channel +//! opening fees are deducted from the incoming payment, i.e., no funds are required client-side to +//! initiate this flow. //! //! To get started, you'll want to setup a [`LiquidityManager`] and configure it to be the //! [`CustomMessageHandler`] of your LDK node. You can then for example call diff --git a/lightning-liquidity/src/lsps0/client.rs b/lightning-liquidity/src/lsps0/client.rs index a04cf86289b..ab169bd7efb 100644 --- a/lightning-liquidity/src/lsps0/client.rs +++ b/lightning-liquidity/src/lsps0/client.rs @@ -1,4 +1,4 @@ -//! Contains the main LSPS2 client-side object, [`LSPS0ClientHandler`]. +//! Contains the main LSPS0 client-side object, [`LSPS0ClientHandler`]. //! //! Please refer to the [LSPS0 //! specifcation](https://github.com/BitcoinAndLightningLayerSpecs/lsp/tree/main/LSPS0) for more diff --git a/lightning-liquidity/src/lsps0/msgs.rs b/lightning-liquidity/src/lsps0/msgs.rs index 79fd46ea676..631cc9206c5 100644 --- a/lightning-liquidity/src/lsps0/msgs.rs +++ b/lightning-liquidity/src/lsps0/msgs.rs @@ -1,4 +1,4 @@ -//! Message, request, and other primitive types used to implement LSPS1. +//! Message, request, and other primitive types used to implement LSPS0. use crate::lsps0::ser::{LSPSMessage, RequestId, ResponseError}; use crate::prelude::Vec; diff --git a/lightning-liquidity/src/manager.rs b/lightning-liquidity/src/manager.rs index 0c03e5128f8..aa2b8b7f5b8 100644 --- a/lightning-liquidity/src/manager.rs +++ b/lightning-liquidity/src/manager.rs @@ -75,13 +75,18 @@ pub struct LiquidityClientConfig { /// Users need to continually poll [`LiquidityManager::get_and_clear_pending_events`] in order to surface /// [`Event`]'s that likely need to be handled. /// -/// If configured, users must forward the [`Event::HTLCIntercepted`] event parameters to [`LSPS2ServiceHandler::htlc_intercepted`] -/// and the [`Event::ChannelReady`] event parameters to [`LSPS2ServiceHandler::channel_ready`]. +/// If the LSPS2 service is configured, users must forward the following parameters from LDK events: +/// - [`Event::HTLCIntercepted`] to [`LSPS2ServiceHandler::htlc_intercepted`] +/// - [`Event::ChannelReady`] to [`LSPS2ServiceHandler::channel_ready`] +/// - [`Event::HTLCHandlingFailed`] to [`LSPS2ServiceHandler::htlc_handling_failed`] +/// - [`Event::PaymentForwarded`] to [`LSPS2ServiceHandler::payment_forwarded`] /// /// [`PeerManager`]: lightning::ln::peer_handler::PeerManager /// [`MessageHandler`]: lightning::ln::peer_handler::MessageHandler /// [`Event::HTLCIntercepted`]: lightning::events::Event::HTLCIntercepted /// [`Event::ChannelReady`]: lightning::events::Event::ChannelReady +/// [`Event::HTLCHandlingFailed`]: lightning::events::Event::HTLCHandlingFailed +/// [`Event::PaymentForwarded`]: lightning::events::Event::PaymentForwarded pub struct LiquidityManager where ES::Target: EntropySource, From 8825fc387bc6c7deeee3898cce5be9cb2ccec2a6 Mon Sep 17 00:00:00 2001 From: Elias Rohrer Date: Wed, 18 Dec 2024 09:54:05 +0100 Subject: [PATCH 2/4] Drop disconnecting peers from the list of ignored peers When a peer misbehaves/sends bogus data we reply with an error message and insert it to the ignored list. Here, we avoid having this list grow unboundedly over time by removing peers again once they disconnect, allowing them a second chance upon reconnection. --- lightning-liquidity/src/manager.rs | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lightning-liquidity/src/manager.rs b/lightning-liquidity/src/manager.rs index aa2b8b7f5b8..06587ba632c 100644 --- a/lightning-liquidity/src/manager.rs +++ b/lightning-liquidity/src/manager.rs @@ -618,6 +618,9 @@ where } fn peer_disconnected(&self, counterparty_node_id: bitcoin::secp256k1::PublicKey) { + // If the peer was misbehaving, drop it from the ignored list to cleanup the kept state. + self.ignored_peers.write().unwrap().remove(&counterparty_node_id); + if let Some(lsps2_service_handler) = self.lsps2_service_handler.as_ref() { lsps2_service_handler.peer_disconnected(counterparty_node_id); } From 6e062629359a5de37e29a25c05c40f4d7b365ef6 Mon Sep 17 00:00:00 2001 From: Elias Rohrer Date: Wed, 18 Dec 2024 10:12:53 +0100 Subject: [PATCH 3/4] Update `best_block` field in `Confirm::best_block_updated` Previously, we wouldn't set the field as we aren't yet making use of it. Here, we start setting the field. To this end, we make `best_block` an `RwLock>` rather than `Option>`. --- lightning-liquidity/src/manager.rs | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/lightning-liquidity/src/manager.rs b/lightning-liquidity/src/manager.rs index 06587ba632c..1e467c302de 100644 --- a/lightning-liquidity/src/manager.rs +++ b/lightning-liquidity/src/manager.rs @@ -107,7 +107,7 @@ where lsps2_client_handler: Option>, service_config: Option, _client_config: Option, - best_block: Option>, + best_block: RwLock>, _chain_source: Option, } @@ -215,7 +215,7 @@ where { lsps2_service_handler, service_config, _client_config: client_config, - best_block: chain_params.map(|chain_params| RwLock::new(chain_params.best_block)), + best_block: RwLock::new(chain_params.map(|chain_params| chain_params.best_block)), _chain_source: chain_source, } } @@ -642,8 +642,7 @@ where &self, header: &bitcoin::block::Header, txdata: &chain::transaction::TransactionData, height: u32, ) { - if let Some(best_block) = &self.best_block { - let best_block = best_block.read().unwrap(); + if let Some(best_block) = self.best_block.read().unwrap().as_ref() { assert_eq!(best_block.block_hash, header.prev_blockhash, "Blocks must be connected in chain-order - the connected header must build on the last connected header"); assert_eq!(best_block.height, height - 1, @@ -656,8 +655,7 @@ where fn block_disconnected(&self, header: &bitcoin::block::Header, height: u32) { let new_height = height - 1; - if let Some(best_block) = &self.best_block { - let mut best_block = best_block.write().unwrap(); + if let Some(best_block) = self.best_block.write().unwrap().as_mut() { assert_eq!(best_block.block_hash, header.block_hash(), "Blocks must be disconnected in chain-order - the disconnected header must be the last connected header"); assert_eq!(best_block.height, height, @@ -690,7 +688,10 @@ where // confirmed at a height <= the one we now unconfirmed. } - fn best_block_updated(&self, _header: &bitcoin::block::Header, _height: u32) { + fn best_block_updated(&self, header: &bitcoin::block::Header, height: u32) { + let new_best_block = BestBlock::new(header.block_hash(), height); + *self.best_block.write().unwrap() = Some(new_best_block); + // TODO: Call best_block_updated on all sub-modules that require it, e.g., LSPS1MessageHandler. if let Some(lsps2_service_handler) = self.lsps2_service_handler.as_ref() { lsps2_service_handler.prune_peer_state(); From dd91418463639ee603493a575d0bb35ddd94f238 Mon Sep 17 00:00:00 2001 From: Elias Rohrer Date: Wed, 18 Dec 2024 10:20:59 +0100 Subject: [PATCH 4/4] Add notes to docs/README to indicate beta status of service-side As a few things are missing (most importantly persistence), we add notes that the service-side integration is currently considered 'beta'. --- lightning-liquidity/README.md | 3 +++ lightning-liquidity/src/lib.rs | 3 +++ 2 files changed, 6 insertions(+) diff --git a/lightning-liquidity/README.md b/lightning-liquidity/README.md index b3b8f602243..dd74ba830c2 100644 --- a/lightning-liquidity/README.md +++ b/lightning-liquidity/README.md @@ -2,6 +2,9 @@ The goal of this crate is to provide types and primitives to integrate a spec-compliant LSP with an LDK-based node. To this end, this crate provides client-side as well as service-side logic to implement the [LSP specifications]. +**Note**: Service-side support is currently considered "beta", i.e., not fully +ready for production use. + Currently the following specifications are supported: - [LSPS0] defines the transport protocol with the LSP over which the other protocols communicate. - [LSPS1] allows to order Lightning channels from an LSP. This is useful when the client needs diff --git a/lightning-liquidity/src/lib.rs b/lightning-liquidity/src/lib.rs index 23472a467e6..520c2009811 100644 --- a/lightning-liquidity/src/lib.rs +++ b/lightning-liquidity/src/lib.rs @@ -10,6 +10,9 @@ //! The goal of this crate is to provide types and primitives to integrate a spec-compliant LSP with an LDK-based node. To this end, this crate provides client-side as well as service-side logic to implement the [LSP specifications]. //! +//! **Note**: Service-side support is currently considered "beta", i.e., not fully ready for +//! production use. +//! //! Currently the following specifications are supported: //! - [LSPS0] defines the transport protocol with the LSP over which the other protocols communicate. //! - [LSPS1] allows to order Lightning channels from an LSP. This is useful when the client needs