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

lsp_plugin: add htlc_accepted handler for no-mpp

Public commit record

What the developer wrote

Authored by Peter Neuroth

68/100 · Adequate
lsp_plugin: add htlc_accepted handler for no-mpp

Adds the service side (LSP) for a simple no-mpp trusted jit channel
opening. This is only an intermediate step, we are going to add support
for multiple htlcs.
This is experimental and can drain on-chain fees from the LSP if used in
public.

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

What changed, and why it matters

This commit adds an experimental service-side feature for Core Lightning's LSPS2 plugin that automatically opens a new Lightning channel when a payment arrives for an unknown peer. The code is marked as experimental and incomplete by its own author, with several 'Fixme' notes indicating future hardening is needed. The main operational risk is that a public LSP could have its on-chain funds drained by attackers who trigger many automatic channel opens. The commit itself does not claim to fix a security bug; it is a new feature implementation.

Recommended action

Treat this as an experimental feature that should not be enabled on production or publicly reachable LSP nodes until the noted 'Fixme' items are resolved, especially: HTLC timeout handling, configurable and validated minimum HTLC, duplicate-channel prevention, policy-driven capacity sizing, and rate limiting on channel opens. Review the test policy plugin's hard-coded capacity before any real deployment. No CVE or vendor security advisory is indicated by the commit itself.

Security signals we found

01

New automatic on-chain funding path triggered by incoming HTLCs

02

Author explicitly labels feature as experimental and dangerous if exposed publicly

03

Multiple 'Fixme' comments indicate incomplete validation and error handling

04

Hard-coded 1000 msat htlc_minimum_msat placeholder in production hook registration

05

Fixed 100000000 msat capacity returned by test policy plugin regardless of payment size

06

Busy-wait loop polls peer channels with 10s backoff; no HTLC timeout handling

07

Channel funding failure returns generic UNKNOWN_NEXT_PEER failure

08

MPP payments explicitly rejected with UNKNOWN_NEXT_PEER failure

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.