Skip to content

Follow-ups to #3436#3493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
TheBlueMatt merged 4 commits into from
Dec 19, 2024
Merged

Follow-ups to #3436 #3493

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
4cb4d66
Address doc nits
tnull Dec 17, 2024
8825fc3
Drop disconnecting peers from the list of ignored peers
tnull Dec 18, 2024
6e06262
Update `best_block` field in `Confirm::best_block_updated`
tnull Dec 18, 2024
dd91418
Add notes to docs/README to indicate beta status of service-side
tnull Dec 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 8 additions & 3 deletions lightning-liquidity/README.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -2,13 +2,18 @@

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
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.

Expand Down
10 changes: 7 additions & 3 deletions lightning-liquidity/src/lib.rs
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -10,13 +10,17 @@

//! 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
//! 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
Expand Down
2 changes: 1 addition & 1 deletion lightning-liquidity/src/lsps0/client.rs
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -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
Expand Down
2 changes: 1 addition & 1 deletion lightning-liquidity/src/lsps0/msgs.rs
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -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;
Expand Down
27 changes: 18 additions & 9 deletions lightning-liquidity/src/manager.rs
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -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<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone>
where
ES::Target: EntropySource,
Expand All@@ -102,7 +107,7 @@ where
lsps2_client_handler: Option<LSPS2ClientHandler<ES>>,
service_config: Option<LiquidityServiceConfig>,
_client_config: Option<LiquidityClientConfig>,
best_block: Option<RwLock<BestBlock>>,
best_block: RwLock<Option<BestBlock>>,
_chain_source: Option<C>,
}

Expand DownExpand Up@@ -210,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,
}
}
Expand DownExpand Up@@ -613,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);
}
Expand All@@ -634,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,
Expand All@@ -648,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,
Expand DownExpand Up@@ -682,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();
Expand Down
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Follow-ups to #3436 by tnull · Pull Request #3493 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #3436#3493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

TheBlueMatt
merged 4 commits into

from

Dec 19, 2024
 Merged


Follow-ups to #3436
#3493
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


4 commits


Select commit
Hold shift + click to select a range
4cb4d66

Address doc nits


tnull Dec 17, 2024
8825fc3

Drop disconnecting peers from the list of ignored peers


tnull Dec 18, 2024
6e06262

Update `best_block` field in `Confirm::best_block_updated`


tnull Dec 18, 2024
dd91418

Add notes to docs/README to indicate beta status of service-side


tnull Dec 18, 2024

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


11 changes: 8 additions & 3 deletions
lightning-liquidity/README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2,13 +2,18 @@

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
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.

Expand Down

10 changes: 7 additions & 3 deletions
lightning-liquidity/src/lib.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,13 +10,17 @@

//! 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
//! 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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/client.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/msgs.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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;
Expand Down

27 changes: 18 additions & 9 deletions
lightning-liquidity/src/manager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -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<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone>
where
	ES::Target: EntropySource,
Expand All@@ -102,7 +107,7 @@ where
	lsps2_client_handler: Option<LSPS2ClientHandler<ES>>,
	service_config: Option<LiquidityServiceConfig>,
	_client_config: Option<LiquidityClientConfig>,
	best_block: Option<RwLock<BestBlock>>,
	best_block: RwLock<Option<BestBlock>>,
	_chain_source: Option<C>,
}

Expand DownExpand Up@@ -210,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,
 }
	}
Expand DownExpand Up@@ -613,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);
 }
Expand All@@ -634,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,
Expand All@@ -648,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,
Expand DownExpand Up@@ -682,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();
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Follow-ups to #3436 by tnull · Pull Request #3493 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #3436#3493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

TheBlueMatt
merged 4 commits into

from

Dec 19, 2024
 Merged


Follow-ups to #3436
#3493
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


4 commits


Select commit
Hold shift + click to select a range
4cb4d66

Address doc nits


tnull Dec 17, 2024
8825fc3

Drop disconnecting peers from the list of ignored peers


tnull Dec 18, 2024
6e06262

Update `best_block` field in `Confirm::best_block_updated`


tnull Dec 18, 2024
dd91418

Add notes to docs/README to indicate beta status of service-side


tnull Dec 18, 2024

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


11 changes: 8 additions & 3 deletions
lightning-liquidity/README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2,13 +2,18 @@

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
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.

Expand Down

10 changes: 7 additions & 3 deletions
lightning-liquidity/src/lib.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,13 +10,17 @@

//! 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
//! 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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/client.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/msgs.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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;
Expand Down

27 changes: 18 additions & 9 deletions
lightning-liquidity/src/manager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -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<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone>
where
	ES::Target: EntropySource,
Expand All@@ -102,7 +107,7 @@ where
	lsps2_client_handler: Option<LSPS2ClientHandler<ES>>,
	service_config: Option<LiquidityServiceConfig>,
	_client_config: Option<LiquidityClientConfig>,
	best_block: Option<RwLock<BestBlock>>,
	best_block: RwLock<Option<BestBlock>>,
	_chain_source: Option<C>,
}

Expand DownExpand Up@@ -210,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,
 }
	}
Expand DownExpand Up@@ -613,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);
 }
Expand All@@ -634,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,
Expand All@@ -648,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,
Expand DownExpand Up@@ -682,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();
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Follow-ups to #3436 by tnull · Pull Request #3493 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #3436#3493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

TheBlueMatt
merged 4 commits into

from

Dec 19, 2024
 Merged


Follow-ups to #3436
#3493
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


4 commits


Select commit
Hold shift + click to select a range
4cb4d66

Address doc nits


tnull Dec 17, 2024
8825fc3

Drop disconnecting peers from the list of ignored peers


tnull Dec 18, 2024
6e06262

Update `best_block` field in `Confirm::best_block_updated`


tnull Dec 18, 2024
dd91418

Add notes to docs/README to indicate beta status of service-side


tnull Dec 18, 2024

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


11 changes: 8 additions & 3 deletions
lightning-liquidity/README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2,13 +2,18 @@

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
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.

Expand Down

10 changes: 7 additions & 3 deletions
lightning-liquidity/src/lib.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,13 +10,17 @@

//! 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
//! 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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/client.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/msgs.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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;
Expand Down

27 changes: 18 additions & 9 deletions
lightning-liquidity/src/manager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -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<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone>
where
	ES::Target: EntropySource,
Expand All@@ -102,7 +107,7 @@ where
	lsps2_client_handler: Option<LSPS2ClientHandler<ES>>,
	service_config: Option<LiquidityServiceConfig>,
	_client_config: Option<LiquidityClientConfig>,
	best_block: Option<RwLock<BestBlock>>,
	best_block: RwLock<Option<BestBlock>>,
	_chain_source: Option<C>,
}

Expand DownExpand Up@@ -210,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,
 }
	}
Expand DownExpand Up@@ -613,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);
 }
Expand All@@ -634,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,
Expand All@@ -648,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,
Expand DownExpand Up@@ -682,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();
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Follow-ups to #3436 by tnull · Pull Request #3493 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #3436#3493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

TheBlueMatt
merged 4 commits into

from

Dec 19, 2024
 Merged


Follow-ups to #3436
#3493
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


4 commits


Select commit
Hold shift + click to select a range
4cb4d66

Address doc nits


tnull Dec 17, 2024
8825fc3

Drop disconnecting peers from the list of ignored peers


tnull Dec 18, 2024
6e06262

Update `best_block` field in `Confirm::best_block_updated`


tnull Dec 18, 2024
dd91418

Add notes to docs/README to indicate beta status of service-side


tnull Dec 18, 2024

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


11 changes: 8 additions & 3 deletions
lightning-liquidity/README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2,13 +2,18 @@

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
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.

Expand Down

10 changes: 7 additions & 3 deletions
lightning-liquidity/src/lib.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,13 +10,17 @@

//! 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
//! 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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/client.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/msgs.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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;
Expand Down

27 changes: 18 additions & 9 deletions
lightning-liquidity/src/manager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -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<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone>
where
	ES::Target: EntropySource,
Expand All@@ -102,7 +107,7 @@ where
	lsps2_client_handler: Option<LSPS2ClientHandler<ES>>,
	service_config: Option<LiquidityServiceConfig>,
	_client_config: Option<LiquidityClientConfig>,
	best_block: Option<RwLock<BestBlock>>,
	best_block: RwLock<Option<BestBlock>>,
	_chain_source: Option<C>,
}

Expand DownExpand Up@@ -210,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,
 }
	}
Expand DownExpand Up@@ -613,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);
 }
Expand All@@ -634,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,
Expand All@@ -648,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,
Expand DownExpand Up@@ -682,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();
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Follow-ups to #3436 by tnull · Pull Request #3493 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #3436#3493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

TheBlueMatt
merged 4 commits into

from

Dec 19, 2024
 Merged


Follow-ups to #3436
#3493
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


4 commits


Select commit
Hold shift + click to select a range
4cb4d66

Address doc nits


tnull Dec 17, 2024
8825fc3

Drop disconnecting peers from the list of ignored peers


tnull Dec 18, 2024
6e06262

Update `best_block` field in `Confirm::best_block_updated`


tnull Dec 18, 2024
dd91418

Add notes to docs/README to indicate beta status of service-side


tnull Dec 18, 2024

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


11 changes: 8 additions & 3 deletions
lightning-liquidity/README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2,13 +2,18 @@

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
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.

Expand Down

10 changes: 7 additions & 3 deletions
lightning-liquidity/src/lib.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,13 +10,17 @@

//! 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
//! 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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/client.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/msgs.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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;
Expand Down

27 changes: 18 additions & 9 deletions
lightning-liquidity/src/manager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -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<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone>
where
	ES::Target: EntropySource,
Expand All@@ -102,7 +107,7 @@ where
	lsps2_client_handler: Option<LSPS2ClientHandler<ES>>,
	service_config: Option<LiquidityServiceConfig>,
	_client_config: Option<LiquidityClientConfig>,
	best_block: Option<RwLock<BestBlock>>,
	best_block: RwLock<Option<BestBlock>>,
	_chain_source: Option<C>,
}

Expand DownExpand Up@@ -210,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,
 }
	}
Expand DownExpand Up@@ -613,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);
 }
Expand All@@ -634,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,
Expand All@@ -648,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,
Expand DownExpand Up@@ -682,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();
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
})();
Follow-ups to #3436 by tnull · Pull Request #3493 · lightningdevkit/rust-lightning · GitHub
Skip to content
Follow-ups to #3436#3493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

TheBlueMatt
merged 4 commits into

from

Dec 19, 2024
 Merged


Follow-ups to #3436
#3493
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


4 commits


Select commit
Hold shift + click to select a range
4cb4d66

Address doc nits


tnull Dec 17, 2024
8825fc3

Drop disconnecting peers from the list of ignored peers


tnull Dec 18, 2024
6e06262

Update `best_block` field in `Confirm::best_block_updated`


tnull Dec 18, 2024
dd91418

Add notes to docs/README to indicate beta status of service-side


tnull Dec 18, 2024

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


11 changes: 8 additions & 3 deletions
lightning-liquidity/README.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -2,13 +2,18 @@

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
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.

Expand Down

10 changes: 7 additions & 3 deletions
lightning-liquidity/src/lib.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,13 +10,17 @@

//! 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
//! 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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/client.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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
Expand Down

2 changes: 1 addition & 1 deletion
lightning-liquidity/src/lsps0/msgs.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
@@ -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;
Expand Down

27 changes: 18 additions & 9 deletions
lightning-liquidity/src/manager.rs

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -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<ES: Deref + Clone, CM: Deref + Clone, C: Deref + Clone>
where
	ES::Target: EntropySource,
Expand All@@ -102,7 +107,7 @@ where
	lsps2_client_handler: Option<LSPS2ClientHandler<ES>>,
	service_config: Option<LiquidityServiceConfig>,
	_client_config: Option<LiquidityClientConfig>,
	best_block: Option<RwLock<BestBlock>>,
	best_block: RwLock<Option<BestBlock>>,
	_chain_source: Option<C>,
}

Expand DownExpand Up@@ -210,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,
 }
	}
Expand DownExpand Up@@ -613,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);
 }
Expand All@@ -634,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,
Expand All@@ -648,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,
Expand DownExpand Up@@ -682,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();
Expand Down