BOLT12 LSPS2 Support via persisted BOLT12 state by TheBlueMatt · Pull Request #964 · lightningdevkit/ldk-node

TheBlueMatt · 2026-07-03T17:52:10Z

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

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>

ldk-reviews-bot · 2026-07-03T17:52:13Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tnull · 2026-07-22T08:37:37Z

Superseded by #999.

TheBlueMatt · 2026-07-03T17:52:10Z

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

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>

ldk-reviews-bot · 2026-07-03T17:52:13Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tnull · 2026-07-22T08:37:37Z

Superseded by #999.

TheBlueMatt · 2026-07-03T17:52:10Z

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

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>

ldk-reviews-bot · 2026-07-03T17:52:13Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tnull · 2026-07-22T08:37:37Z

Superseded by #999.

TheBlueMatt · 2026-07-03T17:52:10Z

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

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>

ldk-reviews-bot · 2026-07-03T17:52:13Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tnull · 2026-07-22T08:37:37Z

Superseded by #999.

TheBlueMatt · 2026-07-03T17:52:10Z

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

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>

ldk-reviews-bot · 2026-07-03T17:52:13Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tnull · 2026-07-22T08:37:37Z

Superseded by #999.

TheBlueMatt · 2026-07-03T17:52:10Z

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

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>

ldk-reviews-bot · 2026-07-03T17:52:13Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tnull · 2026-07-22T08:37:37Z

Superseded by #999.

TheBlueMatt · 2026-07-03T17:52:10Z

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

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>

ldk-reviews-bot · 2026-07-03T17:52:13Z

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

tnull · 2026-07-22T08:37:37Z

Superseded by #999.

Matt Coralloand others added 3 commits July 3, 2026 14:21

DROPME: Bump Rust Lightning to unmerged LSPS2 APIs
76f59ae
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>

TheBlueMatt force-pushed the 2026-07-lsps2-bolt12-stateful-global branch from 441801d to 5f79078Compare July 3, 2026 17:52

tnull mentioned this pull request Jul 16, 2026
Support BOLT12 LSPS2 JIT-channel receives #990
Closed