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

offers: add createproof API.

Public commit record

What the developer wrote

Authored by Rusty Russell

58/100 · Thin
offers: add createproof API.

Changelog-EXPERIMENTAL: JSON-RPC: `createproof` to create a payment proof for a (successful) BOLT12 payment.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new experimental JSON-RPC command called `createproof` to Core Lightning. It lets a user generate a cryptographically signed receipt (a 'payer proof') showing they successfully paid a BOLT12 invoice or offer. The change is a feature addition, not a fix for a known vulnerability. It exposes a new RPC that signs proof data using the node's keys, so the main security consideration is making sure only authorized callers can use it and that the proof data is signed correctly. The commit itself does not claim to fix any security issue, and there is no evidence of malicious intent or a disclosed vulnerability.

Recommended action

Review the new `createproof` RPC for proper RPC authorization (runes/permissions), ensure input validation on `invstring` and `include` is robust, verify that `payersign` cannot be tricked into signing attacker-chosen merkle roots, and audit memory handling in the new plugin code. Because this is an experimental feature, consider restricting access until the BOLT12 proof specification is finalized.

Security signals we found

01

New experimental RPC added (`createproof`) that signs payment proofs with node keys via `payersign`

02

Existing internal `merkle_payer_proof` renamed and exported as `bolt12_payer_proof_merkle` so the plugin can compute the signing merkle root

03

Proof construction enforces mandatory fields (invreq_payer_id, invoice_payment_hash, invoice_features, invoice_node_id, signature) and allows caller-controlled optional `include` list

04

RPC requires a successful completed payment (`listsendpays` status=complete) and returns error 1700 if none found

05

No security relevance, vulnerability fix, or incident disclosure is stated in the commit message or diff

Risk score

Why this scored 22/100

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