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

schemas: make required fields match the code

EPddbd2963 View source ↗
Public commit record

What the developer wrote

Authored by daywalker90

78/100 · Adequate
schemas: make required fields match the code

Fields added to `required` (source where unconditionally added):
- askrene-create-layer/layers[]. & askrene-listlayers/layers[]:
`biases`, `node_biases` - plugins/askrene/layer.c:1512,1519
- bkpr-channelsapy/channels[]: `fees_in_msat` - plugins/bkpr/channelsapy.c:292
- bkpr-report: `format` (request) - plugins/bkpr/bookkeeper.c:520;
`format-hint` - plugins/bkpr/report.c:499
- datastore & deldatastore: `generation`, `hex` - lightningd/datastore.c:19,20
- decode/offer_recurrence[]: `compulsory_field` - plugins/offers.c:880
- delpay/payments[]: `groupid` - lightningd/pay.c:144
- feerates/onchain_fee_estimates: `unilateral_close_nonanchor_satoshis`
- lightningd/chaintopology.c:788
- fundchannel_start: `channel_type` - lightningd/opening_control.c:321
- help: `format-hint` - lightningd/jsonrpc.c:496
- hook/onion_message_recv & _secret: `unknown_fields`,
`reply_blindedpath.{first_path_key,hops}` - lightningd/onion_message.c:30,31,66
- listchannels/channels[]: `htlc_maximum_msat` - plugins/topology.c:263
- listclosedchannels/closedchannels[]: `channel_type`
- lightningd/closed_channel.c:43
- listconfigs: `configs` - lightningd/configs.c:275
- listpays/pays[]: `amount_sent_msat` - plugins/xpay/listpays.c:183
- listpeerchannels/channels[]: `channel_type` - lightningd/peer_control.c:959,
lightningd/dual_open_control.c:128, lightningd/opening_control.c:48
- listpeers/peers[]: `features` - lightningd/peer_control.c:2619
- multifundchannel: `failed` - plugins/spender/multifundchannel.c:501
- notification/coin_movement: `extra_tags` - lightningd/coin_mvts.c:169
- offer: `force_paths` - lightningd/offer.c:24
- openchannel_init & openchannel_bump: `requires_confirmed_inputs`
- lightningd/dual_open_control.c:3478
- parsefeerate: `perkw` - lightningd/chaintopology.c:823
- pay: `destination` - plugins/xpay/xpay.c:473, plugins/libplugin-pay.c:2144
- reckless (request): `target/subcommand` - plugins/recklessrpc.c:280
- renepay & renepaystatus/paystatus[]: `groupid`, `destination`
- plugins/renepay/json.c:269,278,279
- sendonion: `groupid` - lightningd/pay.c:144; pending branch `message` - :299
- sendpay & waitsendpay: `groupid` - lightningd/pay.c:144
- splice_signed: `outnum` - lightningd/channel_control.c:548
- splicein & spliceout: `psbt`, `txid` - plugins/spender/splice.c:1763,1764

Fields removed from `required` (conditional in code):
- bkpr-editdescriptionbypaymentid/items[]: `description`
- plugins/bkpr/chain_event.c:33-34, plugins/bkpr/channel_event.c:53-54
- createinvoice & sendinvoice: `description` - lightningd/invoice.c:64-65
- hook/invoice_payment: `result` - lightningd/invoice.c:237 (optional);
`failure_message` only used when `result` is absent, now required there
via if/then/else
- invoicerequest (request): `description` - plugins/offers_offer.c:693 (p_opt)
- splice_signed (request): `channel_id` - lightningd/channel_control.c:2511
(p_opt)

Note: bkpr-editdescriptionbyoutpoint keeps `description` required: the
SQL refetch filters credit_msat > 0 (recorder.c:376-382) and the desc was
just stored keyed by outpoint (bookkeeper.c:853).

Adjust plugins and tests to the now-required fields:
- lsps-plugin: peer.features is non-optional (listpeers)
- wss-proxy-plugin: listconfigs' configs object is non-optional
- cln-rpc/src/test.rs

Changelog-None
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In practice it mostly removes 'optional' markers from fields that were already unconditionally emitted, and makes a few truly conditional fields optional. It also changes one plugin hook response schema so that a plugin can reject a payment by returning only a custom failure_message, without a result field. The changes are broad but are described by the project as a schema consistency fix, not a security fix. There is no direct evidence in the commit of an exploitable vulnerability.

Recommended action

Treat this as a routine API/schema consistency update. Reviewers should verify that each newly-required field is indeed unconditionally present in the referenced C source, and that clients using the gRPC/JSON-RPC bindings can handle the new required fields. Pay particular attention to the invoice_payment hook schema change to ensure the new conditional logic (result absent => failure_message required) is handled correctly by both Core Lightning and plugin implementations. No emergency action is indicated by the commit itself.

Security signals we found

01

Large schema-only change with no accompanying security advisory or CVE

02

One semantic change to plugin hook response: invoice_payment hook can now reject with only failure_message and no result

03

Many fields change from optional to required in public RPC/protobuf interfaces

04

A few fields change from required to optional where code makes them conditional

05

No changes to cryptographic operations, authentication, authorization, or network parsing visible in the diff

Risk score

Why this scored 37/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 5/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.

More from Core Lightning

Related watches

Informational 21 AI analysisMessage 85 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

docs: document missing and fix erroneous JSON-RPC error codes

This commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…

Documentation-only change with no executable code modificationsCorrects RPC schema error-code metadata to match actual handler behaviorNo change to input parsing, authorization, cryptography, or network behavior
d1b6963bby daywalker90+204−1224 files
No security note in commit
Open full analysis →Source commit ↗
Low 46 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

channeld: initialize tx_sigs_allowed on startup

This commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …

use of uninitialized variableundefined behavior (invalid bool load)network-triggered code path
c09c4520by Erick Cestari+1−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 100 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

ci: fix the coverage nightly's profile handling

This commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…

5685c9a3by cdecker+12−211 file
No security note in commit
Open full analysis →Source commit ↗