AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 35 Bitcoin

lsp_plugin: add lsps-jitchannel handler

Public commit record

What the developer wrote

Authored by Peter Neuroth

76/100 · Adequate
lsp_plugin: add lsps-jitchannel handler

Adds the full roundtrip to request a jit channel from the LSP. It
approves the jit scid returned by the LSP and returns the invoice with
the corresponding route-hint.

Changelog-Added Experimental support for LSPS2 no-MPP,
Lsps-trusts-client mode. See
https://github.com/lightning/blips/blob/master/blip-0052.md for further
details.

Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds experimental support for a new Lightning protocol feature called LSPS2 'just-in-time' (JIT) channels. It lets a user request a payment invoice that, when paid, causes a Lightning Service Provider (LSP) to open a new channel on the fly and forward the payment. The code is marked experimental and contains several TODO/FIXME comments noting that important safety checks are not yet implemented, such as verifying the payment is not a forwarded payment, preventing double payment for the same channel, and checking that the LSP is trusted before accepting a zero-confirmation channel.

Recommended action

Treat this as experimental/incomplete code that should not be enabled in production. Before release, implement the documented FIXME/TODO items: enforce a trusted-LSP allowlist in on_openchannel, verify the HTLC is for a local invoice (not a forward) before rewriting the onion, add replay/double-payment protection for jit channel invoices, replace the hardcoded cltv with a real value, and add tests for malicious/untrusted LSP scenarios. Reviewers should audit the TLV parsing and payment_secret mutation logic carefully.

Security signals we found

01

openchannel hook returns mindepth=0 and reserve=0msat for any peer without verifying the peer is a trusted LSP or that a jit channel was expected

02

htlc_accepted hook rewrites onion payment_secret and forward_amt based on extra_tlv 65537 without verifying the HTLC is a local invoice payment rather than a forwarded payment

03

Datastore approval record is keyed only by jit_channel_scid with no replay/double-spend check noted in code

04

Invoice cltv hardcoded to 6+2 with a TODO to fetch real value

05

Multiple explicit TODO/FIXME comments indicating incomplete safety checks

06

New experimental RPC surface added (lsps-jitchannel, lsps-lsps2-approve) and hooks registered

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 6/15
Affected reach 5/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.