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

Commit to client's node id in bLIP-52/LSPS2 promise

Public commit record

What the developer wrote

Authored by Elias Rohrer

73/100 · Adequate
Commit to client's node id in bLIP-52/LSPS2 promise

Previously, the promise HMAC would only commit to the promise secret and
the `OpeningFeeParams` fields, leaving room for other clients to reuse
the same `OpeningFeeParams` in `BuyRequests` if they'd acquire it
somehow out-of-bounds.

While this flexibility also has some benefits, we here have the service
commit to the client's node id, making sure only the original client
can redeem a specific `OpeningFeeParams`.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change fixes a security issue in the LSPS2 (Lightning Service Provider Specification 2) implementation used by Lightning Dev Kit. Previously, a service's fee-quote 'promise' could be reused by any client who obtained it, potentially letting someone else claim another client's reserved channel-opening terms. The patch now includes the client's unique node identifier in the cryptographic promise, so only the originally quoted client can redeem it.

Recommended action

Review whether any deployed services or clients rely on the old unbound promise format; if so, coordinate an upgrade because old quotes will fail validation after this change. Consider whether the protocol spec (bLIP-52/LSPS2) needs a corresponding update to mandate node-id binding, and monitor for any CVE assignment if this is treated as a security fix.

Security signals we found

01

HMAC now binds OpeningFeeParams to a specific counterparty node id

02

Prevents out-of-bounds reuse of fee quotes by other clients

03

Adds explicit regression test for client-node-id mismatch

04

Updates integration test to validate with correct client_node_id

Risk score

Why this scored 60/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 10/15
Confidence 8/10
Evidence quality 4/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.