mirrors/rust-lightning
1
0
Fork 0
mirror of https://github.com/lightningdevkit/rust-lightning.git synced 2025-02-23 14:50:45 +01:00
Code Issues Projects Releases Packages Wiki Activity
rust-lightning/lightning-liquidity
History
Elias Rohrer e05b76af7b
liquidity: Allow setting process_events callback in c_bindings 
To trigger message processing, we previously had the user set a callback
to `PeerManager::process_events` via an `Fn()` callback. This is however
not supported by `c_bindings`.

Here, we therefore introduce as `ProcessMesssagesCallback` trait that
can be used via `LiquidityManager::set_process_msgs_callback_fn`, which
is exposed in `c_bindings`.
2025-01-15 09:58:43 +01:00
..
src liquidity: Allow setting process_events callback in c_bindings 2025-01-15 09:58:43 +01:00
tests Add lightning-liquidity crate to the workspace 2024-12-11 17:01:03 +01:00
Cargo.toml Use lightning::sync via symlink in lightning-liquidity 2024-12-11 17:01:04 +01:00
README.md Add notes to docs/README to indicate beta status of service-side 2024-12-19 17:12:09 +01:00

README.md

lightning-liquidity

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

LiquidityManager uses an eventing system to notify the user about important updates to the protocol flow. To this end, you will need to handle events emitted via one of the event handling methods provided by LiquidityManager, e.g., LiquidityManager::next_event.