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

lightningd: don't do previous invoice checking in createinvoicerequest.

Public commit record

What the developer wrote

Authored by Rusty Russell

73/100 · Adequate
lightningd: don't do previous invoice checking in createinvoicerequest.

This is an undocumented interface, so we can just change it.

Rename "recurrence_label" to the more general "label", now we don't
require it to find previous payments.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit removes a local sanity check in Core Lightning's experimental 'createinvoicerequest' command. Previously, when creating a recurring invoice request, the code looked up past payments by label to verify the previous recurrence was paid and to copy timing data. Now it skips that lookup and lets the remote node decide. The change also renames the 'recurrence_label' parameter to the simpler 'label'. It is described by the author as a cleanup of an undocumented interface, not as a security fix.

Recommended action

Treat as a behavior change rather than a vulnerability. Review whether removing local basetime/copy and prior-payment validation could allow clients to create malformed or premature recurring invoice requests, and confirm the remote node now enforces equivalent checks. If the interface is still experimental, consider documenting the new 'label' parameter and expected remote-side errors.

Security signals we found

01

Removal of local payment-state validation for recurring invoice requests

02

Parameter rename from recurrence_label to label in internal RPC calls

03

Test expectations changed from local 'previous invoice has not been paid' errors to remote failure messages

04

Undocumented interface changed without deprecation or migration note

05

No explicit security framing by commit author

Risk score

Why this scored 32/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/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.