BOLT12 LSPS2 Support via persisted BOLT12 state#964
Draft
TheBlueMatt wants to merge 3 commits into
Draft
Conversation
Point the Rust Lightning overrides at the local branch carrying the LSPS2 BOLT12 router changes and carry the temporary API updates needed to compile LDK Node. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Wrap the default router with the LSPS2-aware `LSPS2Router` and wire it to the LSPS2 client handler, so JIT-channel blinded payment paths are injected into BOLT12 invoices based on the latest invoice parameters negotiated with our configured LSPs. If liquidity sources are configured, we negotiate the parameters with the cheapest LSP once at startup. From then on they simply apply to all BOLT12 receives, i.e., any offer created via the regular receive APIs will have JIT-channel paths injected into its invoices, and we force a refresh of any static invoices stored with a static invoice server so they include the new paths, too. As the router encodes the used parameters in the paths' payment metadata, they are available again upon receipt and used to verify any skimmed channel opening fee against what was negotiated. Parameters previously negotiated with LSPs that are no longer configured are wiped early during node building, before the node could create any invoices or connect to peers. The BOLT11 JIT receive flows are refactored to share the same negotiation logic. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Exercise the BOLT12 receive flow with LSPS2 JIT channels via plain BOLT12 offers relying on the parameters negotiated at startup: the initial channel open, paying an offer after LSP restart, and wiping of stale parameters when restarting without the LSP configured. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
👋 Hi! I see this is a draft PR. |
TheBlueMatt
force-pushed
the
2026-07-lsps2-bolt12-stateful-global
branch
from
441801d to
5f79078
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an alternative to #817 which uses the persisted LSPS2 parameters from https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/4781. It moves away from having the receive methods specify LSPS parameters in favor of just always using them. This is somewhat required for BOLT 12 as we may have an offer from 6 months ago that we still want to receive payments to, but we've since swapped the LSPS parameters we use and we don't want to keep reusing an old LSP just because we configured it as the LSP once. Instead, the new
lightning-liquiditypersists the latest state for our LSPs services and, on startup, ldk-node deletes the negotiated parameters for LSPs we're no longer configured to use.This is all just claude output, I only skimmed the code to make sure its doing what I intended.