Drop `chain_source` from `LSPS1ServiceHandler`
What the developer wrote
Authored by Elias Rohrer
Drop `chain_source` from `LSPS1ServiceHandler`
We previously considered tracking payment confirmations as part of the
handler. However, we can considerably simplify our logic if we stick
with the current approach of having the LSPs track the payment status
and update us when prompted through events.
What changed, and why it matters
This commit removes an unused `chain_source` field from a Lightning service handler. It is a straightforward internal cleanup that simplifies the code by no longer passing around a blockchain data source that was not actually being used. There is no indication this fixes or introduces a security issue.
No security action required. Treat as normal refactoring/cleanup.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch drops the chain_source: Option<C> generic parameter and field from LSPS1ServiceHandler, where C: Filter was imported from lightning::chain::Filter. The commit message explains this was an unused dependency from an earlier design idea to track payment confirmations inside the handler; the project instead keeps the existing event-driven approach where the LSP tracks payment status and notifies the handler. All call sites in manager.rs are updated to remove the chain_source.clone() argument and adjust the generic type signatures. No functional logic changes are present.
Changed components
lightning-liquidity/src/lsps1/service.rslightning-liquidity/src/manager.rsInspect captured patch +9 / −15
diff --git a/lightning-liquidity/src/lsps1/service.rs b/lightning-liquidity/src/lsps1/service.rs
index 793e376..7d138e3 100644
--- a/lightning-liquidity/src/lsps1/service.rs
+++ b/lightning-liquidity/src/lsps1/service.rs
@@ -30,7 +30,6 @@ use crate::prelude::{new_hash_map, HashMap};
use crate::sync::{Arc, Mutex, RwLock};
use crate::utils;
-use lightning::chain::Filter;
use lightning::ln::channelmanager::AChannelManager;
use lightning::ln::msgs::{ErrorAction, LightningError};
use lightning::sign::EntropySource;
@@ -114,34 +113,30 @@ impl PeerState {
}
/// The main object allowing to send and receive bLIP-51 / LSPS1 messages.
-pub struct LSPS1ServiceHandler<ES: EntropySource, CM: Deref + Clone, C: Filter, K: KVStore + Clone>
+pub struct LSPS1ServiceHandler<ES: EntropySource, CM: Deref + Clone, K: KVStore + Clone>
where
CM::Target: AChannelManager,
{
entropy_source: ES,
_channel_manager: CM,
- _chain_source: Option<C>,
pending_messages: Arc<MessageQueue>,
pending_events: Arc<EventQueue<K>>,
per_peer_state: RwLock<HashMap<PublicKey, Mutex<PeerState>>>,
config: LSPS1ServiceConfig,
}
-impl<ES: EntropySource, CM: Deref + Clone, C: Filter, K: KVStore + Clone>
- LSPS1ServiceHandler<ES, CM, C, K>
+impl<ES: EntropySource, CM: Deref + Clone, K: KVStore + Clone> LSPS1ServiceHandler<ES, CM, K>
where
CM::Target: AChannelManager,
{
/// Constructs a `LSPS1ServiceHandler`.
pub(crate) fn new(
entropy_source: ES, pending_messages: Arc<MessageQueue>,
- pending_events: Arc<EventQueue<K>>, channel_manager: CM, chain_source: Option<C>,
- config: LSPS1ServiceConfig,
+ pending_events: Arc<EventQueue<K>>, channel_manager: CM, config: LSPS1ServiceConfig,
) -> Self {
Self {
entropy_source,
_channel_manager: channel_manager,
- _chain_source: chain_source,
pending_messages,
pending_events,
per_peer_state: RwLock::new(new_hash_map()),
@@ -397,8 +392,8 @@ where
}
}
-impl<ES: EntropySource, CM: Deref + Clone, C: Filter, K: KVStore + Clone> LSPSProtocolMessageHandler
- for LSPS1ServiceHandler<ES, CM, C, K>
+impl<ES: EntropySource, CM: Deref + Clone, K: KVStore + Clone> LSPSProtocolMessageHandler
+ for LSPS1ServiceHandler<ES, CM, K>
where
CM::Target: AChannelManager,
{
diff --git a/lightning-liquidity/src/manager.rs b/lightning-liquidity/src/manager.rs
index 1f11fc8..5336e6f 100644
--- a/lightning-liquidity/src/manager.rs
+++ b/lightning-liquidity/src/manager.rs
@@ -297,7 +297,7 @@ pub struct LiquidityManager<
lsps0_client_handler: LSPS0ClientHandler<ES, K>,
lsps0_service_handler: Option<LSPS0ServiceHandler>,
#[cfg(lsps1_service)]
- lsps1_service_handler: Option<LSPS1ServiceHandler<ES, CM, C, K>>,
+ lsps1_service_handler: Option<LSPS1ServiceHandler<ES, CM, K>>,
lsps1_client_handler: Option<LSPS1ClientHandler<ES, K>>,
lsps2_service_handler: Option<LSPS2ServiceHandler<CM, K, T>>,
lsps2_client_handler: Option<LSPS2ClientHandler<ES, K>>,
@@ -474,7 +474,7 @@ where
#[cfg(lsps1_service)]
let lsps1_service_handler = service_config.as_ref().and_then(|config| {
if let Some(number) =
- <LSPS1ServiceHandler<ES, CM, C, K> as LSPSProtocolMessageHandler>::PROTOCOL_NUMBER
+ <LSPS1ServiceHandler<ES, CM, K> as LSPSProtocolMessageHandler>::PROTOCOL_NUMBER
{
supported_protocols.push(number);
}
@@ -484,7 +484,6 @@ where
Arc::clone(&pending_messages),
Arc::clone(&pending_events),
channel_manager.clone(),
- chain_source.clone(),
config.clone(),
)
})
@@ -544,7 +543,7 @@ where
/// Returns a reference to the LSPS1 server-side handler.
#[cfg(lsps1_service)]
- pub fn lsps1_service_handler(&self) -> Option<&LSPS1ServiceHandler<ES, CM, C, K>> {
+ pub fn lsps1_service_handler(&self) -> Option<&LSPS1ServiceHandler<ES, CM, K>> {
self.lsps1_service_handler.as_ref()
}
@@ -1148,7 +1147,7 @@ where
#[cfg(lsps1_service)]
pub fn lsps1_service_handler(
&self,
- ) -> Option<&LSPS1ServiceHandler<ES, CM, C, KVStoreSyncWrapper<KS>>> {
+ ) -> Option<&LSPS1ServiceHandler<ES, CM, KVStoreSyncWrapper<KS>>> {
self.inner.lsps1_service_handler()
}
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.