CommitWatch RSS
EP
← All projectsElements Project

Core Lightning

Modular C implementation of the Lightning Network protocol and node stack.

BitcoinLightning NetworkNormal
Source repository ↗
Repository coverage

1854 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

158security candidates263second-pass queue507AI analyses
147commits · 30 days
226commits · 60 days
804commits · 180 days
1850commits · 365 days
Backfill bands
Aug 5 → Feb 61049 seen37 candidatesComplete
Feb 6 → Jun 6579 seen10 candidatesComplete
Jun 6 → Jul 678 seen1 candidatesComplete
Jul 6 → Aug 5147 seen16 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

70/100 average clarity
431Strong · 80–100
1163Adequate · 60–79
231Thin · 40–59
29Opaque · 0–39
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
dovgopoly1502164
Rusty Russell95873237072
Sangbida Chaudhuri1473166066
Dusty Daemon771314066
ShahanaFarooqui931020063
daywalker9089528062
Níckolas Goline40512076
Lagrang376423069
Christian Decker3647072
Vincenzo Palazzo834080
Chandra Pratap56250082
ekzyis222063
Analysis record

Published AI watches

Last scanned 9 minutes ago

Informational 15 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

Revert "doc: require Homebrew GNU make and gpatch on macOS"

This commit is a simple documentation revert. It undoes a previous change that told macOS users to install GNU make and GNU patch from Homebrew and to put those tools first in their command path. The reverted instructions now omit gpatch a…

0cfa949fby Sangbida Chaudhuri+4−81 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 75 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

Revert "tests: drop obsolete x-prefix in compacter-slow.sh"

This commit re-adds an old-style 'x' prefix to a string comparison in a test helper script. It is a test-only change with no effect on the actual Core Lightning node software, user funds, network behavior, or security. The change simply re…

116fd7cdby Sangbida Chaudhuri+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

doc: require Homebrew GNU make and gpatch on macOS

This commit only updates macOS installation instructions in the documentation. It tells macOS users to install newer GNU versions of 'make' and 'patch' from Homebrew because Apple's built-in tools are too old for building and running sourc…

d3ff1474by Sangbida Chaudhuri+8−41 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: drop obsolete x-prefix in compacter-slow.sh

This commit is a trivial shell script cleanup. It removes an old-fashioned 'x' prefix from a string comparison in a test helper script so that a newer version of the Shellcheck linter stops warning about it. The change does not alter progr…

474c272aby Sangbida Chaudhuri+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

common: hoist amount+currency parsing into common code.

This commit moves existing code that parses payment amounts (Bitcoin millisatoshis, 'any' amount, or fiat currency amounts) from one plugin file into a shared library so it can be reused by a future feature. It is a code refactoring with n…

Refactoring of amount-parsing code into a shared helperAddition of explicit u64 overflow guards (mul_overflows_u64, add_overflows_u64) in the new common codeNo change to wire protocol or RPC interface semantics
e0f86c17by Rusty Russell+112−723 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: internal cleanups since all non-command JSON IDs are strings.

This is a routine internal cleanup commit in Core Lightning. It removes an unused helper function and simplifies how JSON-RPC request IDs are stored and formatted, since the project now always uses string IDs for non-command JSON traffic. …

No security-relevant keywords in commit title or messageNo CVE, advisory, or bug reference presentChanges are refactor/cleanup in nature
a70ae963by Rusty Russell+25−378 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

common: hoist hash_str helper into its own header.

This commit is a routine code cleanup: it moves a small string-hashing helper function into a shared header file so it can be reused without being copied and pasted. There is no change to behavior, no bug fix, and no security relevance.

581bbb1fby Rusty Russell+16−176 files
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

downgrade: we need to remove "impressions" from askrene datastore when downgrading to v26.06.

This is a database downgrade helper fix, not a live network vulnerability. Core Lightning's downgrade tool previously failed to strip out new 'channel impression' records when rolling a database back to version v26.06. The patch teaches th…

Database downgrade path could leave incompatible records in older schemaOffline tool only; no remote or on-chain triggerFix prevents potential node startup failure after version rollback
4d926285by Rusty Russell+43−111 file
No security note in commit
Open full analysis →Source commit ↗
Low 31 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

downgrade tool: fix invalid memory bug

This commit fixes a typo in a database downgrade helper tool. The bug caused the tool to pass a negative number (turned into a huge positive size) when copying data, which led to an out-of-memory (OOM) error. The fix swaps two variable nam…

Integer underflow / negative-to-size_t wrap leading to excessive allocationOut-of-memory crash in maintenance toolMemory corruption potential if allocation somehow succeeded
42995326by Lagrang3+8−81 file
No security note in commit
Open full analysis →Source commit ↗
Informational 24 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

xpay: actually tell askrene when a payment succeeded.

This commit fixes a bookkeeping bug in Core Lightning's xpay plugin. Previously, when a payment succeeded, xpay did not tell the askrene routing-helper that the route worked. As a result, askrene kept stale or overly pessimistic ideas abou…

Missing success feedback to routing layer can degrade payment reliabilityStale negative impressions may bias future path selection toward worse or failing routesNo direct funds-loss primitive is introduced or fixed
a66fabd4by Rusty Russell+40−02 files
No security note in commit
Open full analysis →Source commit ↗
Low 49 AI analysisMessage 58 · Thin
EP Elements ProjectCore Lightning BitcoinLightning Network

askrene: correctly order constraints.

This commit fixes a bug in Core Lightning's routing helper (askrene) where two kinds of channel information—hard limits called 'constraints' and usage estimates called 'impressions'—were being applied in the wrong order. Because impression…

Routing decision bug caused by incorrect ordering of time-relative channel statePotential payment failure or acceptance of an over-capacity routeRegression test added demonstrating incorrect route acceptance before fix
4b6fe4a1by Rusty Russell+211−1182 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

askrene: don't leak channel intel entries

This commit fixes a memory leak in the askrene plugin of Core Lightning. When individual channel intelligence entries were deleted, the code removed the entry from its array but forgot to free two internal pointers (impression and constrai…

Memory leak in plugin data structure cleanupMissing deallocation of nested pointers before array removalFix located in routing/intelligence plugin (askrene)
8891f414by Lagrang3+5−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 70 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

xpay: tests should expect the new error messages

This commit only updates test files so that automated checks expect slightly different error wording from the xpay payment command. It does not change any production code, so it cannot introduce a security vulnerability or fix one on its o…

0b67601fby Lagrang3+24−32 files
No security note in commit
Open full analysis →Source commit ↗
Low 43 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

offers: limit invoices to 10 minutes for recurring offers in other currencies.

This change tightens the lifetime of recurring invoices priced in foreign currencies (like USD) to 10 minutes by default, and refreshes them with current exchange rates when they expire. Previously, such invoices could remain valid for the…

Fixes stale exchange-rate exposure for currency-denominated recurring invoicesAdds configurable expiry cap for recurring currency invoicesDistinguishes user-cancellation (0s expiry) from natural expiry to avoid misleading errors
446312cfby Rusty Russell+134−148 files
No security note in commit
Open full analysis →Source commit ↗
Low 45 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

offers: limit expiry to offer limit, or 10 minutes with currency conversion.

This commit tightens the expiration time on invoices created from BOLT12 offers. Previously, all such invoices defaulted to a 2-hour payment window. Now, if the offer has an absolute expiry, the invoice expires when the offer expires; and …

BOLT12 invoice expiry now bounded by offer absolute expiryCurrency-converted invoices use short expiry to limit exchange-rate exposureNew regression test added for expiry behavior
a6cf4915by Rusty Russell+55−22 files
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

fetchinvoice: don't bother with checking recurrence timing.

This commit removes local timing checks in Core Lightning's fetchinvoice plugin for recurring payments. Instead of the plugin refusing too-early or too-late invoice requests, it now lets the remote node decide and report back. The change i…

Removal of local input-validation checks for recurring invoice requestsReliance on remote-party enforcement for recurrence period limits and pay windowsTest expectations changed from local rejection to remote failure messages
3e49d908by Rusty Russell+2−682 files
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

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

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 wa…

Removal of local payment-state validation for recurring invoice requestsParameter rename from recurrence_label to label in internal RPC callsTest expectations changed from local 'previous invoice has not been paid' errors to remote failure messages
4348d8acby Rusty Russell+5−1224 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

fetchinvoice: handle weird labels in recurrence_label parameter.

This commit fixes how the fetchinvoice plugin handles user-supplied labels that contain special characters such as backslashes, quotes, tabs, and newlines. Previously these labels were passed as raw strings, which could cause JSON encoding…

JSON injection / improper escaping of user-controlled input passed between RPC componentsPotential mismatch between label parsing and label serialization leading to functional failures or unexpected behaviorFix is narrowly scoped to a single plugin and parameter
d7f87f2dby Rusty Russell+37−102 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 70 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

Add unit tests for str_to_u64

This commit only adds a new automated test file that checks how a helper function (str_to_u64) converts text strings to unsigned 64-bit integers. It does not change any production code, so it cannot by itself introduce a security vulnerabi…

dddb455dby Lagrang3+203−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

pytest: add tests for what we want askrene to do.

This commit only adds a new pytest test file. It does not change any production code. The test describes desired future behavior for the askrene routing module's error messages when a payment source or destination lacks enough channel capa…

518620aeby Rusty Russell+67−01 file
No security note in commit
Open full analysis →Source commit ↗
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Lower-priorityxpay: keep track of ongoing payments, to implement attempt_ongoing()by Rusty Russell · 560b0165 · May 11, 2026 · 2 filesMessage 73 · AdequateTriage 0Details
Commit message · Rusty Russell

xpay: keep track of ongoing payments, to implement attempt_ongoing()

This will help when we implement listpays (next) to be xpay-aware.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityplugins: move listpays from pay plugin to xpay plugin.by Rusty Russell · ed42adc9 · May 11, 2026 · 6 filesMessage 73 · AdequateTriage 0Details
Commit message · Rusty Russell

plugins: move listpays from pay plugin to xpay plugin.

This will make life easier when we remove the pay plugin, but also fixes
an issue where `listpays` can indicate ongoing payments are failed,
even though xpay is still working on it.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityrenepay: deprecate.by Rusty Russell · 6eb7dc04 · May 11, 2026 · 6 filesMessage 51 · ThinTriage 0Details
Commit message · Rusty Russell

renepay: deprecate.

I think Eduardo and I stole all the best bits to make xpay and askrene.

I simply enabled deprecations on all the renepay tests.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

51/100 · ThinMessage clarity
✓ Subject identifies a change✓ Provides detailed explanatory context✓ Mentions testing or verification! Too few words to establish purpose
AI review queuedpay: deprecate pay and paystatus.by Rusty Russell · eebc6eea · May 11, 2026 · 20 filesMessage 78 · AdequateInformational 20Details
Commit message · Rusty Russell

pay: deprecate pay and paystatus.

Use xpay and listpays.

Some tests which are pay/paystatus specific simply enabled deprecations.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Deprecated: JSON-RPC: `pay` and `paystatus`: use `xpay`, `listpays` (or `xpay`'s notifications for details of attempts). `pay` will be replaced by `xpay` in v27.03.

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
parser or protocol pathsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Informational 20/100

This commit is a routine API deprecation notice. It marks the old 'pay' and 'paystatus' JSON-RPC commands as deprecated and tells users to switch to the newer 'xpay' and 'listpays' commands. The commands still work if a node operator explicitly allows deprecated APIs. There is no security bug being fixed here.

Lower-priorityupdate-mocks: make handling of mocks in nested files deterministic.by Rusty Russell · 86f45951 · May 11, 2026 · 2 filesMessage 88 · StrongTriage 0Details
Commit message · Rusty Russell

update-mocks: make handling of mocks in nested files deterministic.

update-mocks searches for prototypes, looking first in the local
directory, then in */*.h, and takes the first. In the case of
plugins/bkpr/test/run-currencyrate_str.c referring to
jsonrpc_request_start_, this means it could get either the one in
libplugin (correct) or the one in lightningd (wrong!), depending on
directory order randomness.

Hack it a bit harder, to look one up from the local dir before */*.h.
This is redundant in most cases, but not for three-deep-nested dirs
like this.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
AI review queuedcommon: implement tal_arr_append and tal_arr_appendn, and use them.by Rusty Russell · 427ee36d · May 11, 2026 · 12 filesMessage 73 · AdequateInformational 19Details
Commit message · Rusty Russell

common: implement tal_arr_append and tal_arr_appendn, and use them.

These are useful for the common pattern of "append these bytes to this tal array".

As a bonus, we do memcheck() on all these callers, for extra checking
under valgrind.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 19/100

This commit is a routine code cleanup: it introduces two helper functions, tal_arr_append and tal_arr_appendn, to replace repeated open-coded patterns of resizing a memory array and copying data into it. The change touches many files but does not fix any reported security bug. It adds extra memory-checking under Valgrind and a new unit test. There is no indication this patch is a security fix or that it addresses a known vulnerability.

Lower-priorityaskrene: make failure messages clearer:by Rusty Russell · 3e4af7de · May 11, 2026 · 3 filesMessage 68 · AdequateTriage 0Details
Commit message · Rusty Russell

askrene: make failure messages clearer:

If all channels are disabled, say so clearly. Also reword: it's not
the source or destination which have disabled the channels. While
we're here, remove the double space, lest people think I'm Satoshi.

Before:
Failed after 1 attempts.
Unexpected error (invalid_onion_payload) from final node: disabling 103x1x0/1 for this payment.
Then routing failed: We could not find a usable set of paths. The source has disabled 1 of 1 channels, leaving capacity only 0msat of 1000000000msat.

After:
Failed after 1 attempts.
Unexpected error (invalid_onion_payload) from final node: disabling 103x1x0/1 for this payment.
Then routing failed: We could not find a usable set of paths. All 1 channels to the source are disabled.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityxpay: add extra_tlvs support (unused for now).by Rusty Russell · 09ff5ed6 · May 11, 2026 · 1 fileMessage 60 · AdequateTriage 0Details
Commit message · Rusty Russell

xpay: add extra_tlvs support (unused for now).

This adds them to the final onion (but it's always NULL for now).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Lower-priorityinjectpaymentonion: add explicit `destination` option.by Rusty Russell · eb4655ca · May 11, 2026 · 9 filesMessage 73 · AdequateTriage 0Details
Commit message · Rusty Russell

injectpaymentonion: add explicit `destination` option.

This allows us to correctly annotate the destination in listsendpays
even if invstring isn't set (xkeysend).

Changelog-Added: JSON-RPC: `injectpaymentonion` parameter `destination`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityxpay: ensure unique_id is always valid.by Rusty Russell · 7c89e23c · May 11, 2026 · 2 filesMessage 80 · StrongTriage 0Details
Commit message · Rusty Russell

xpay: ensure unique_id is always valid.

In implementing shadow, I added a call to payment_log in xpay_core,
which caused a valgrind error because we set unique_id later. This
was a premature optimization, so we didn't assign unique_id for
payments which didn't even start, but it's a footgun, and there are
other (less common) calls to payment_log too early which make the same
mistake.

Simplify: unique_id is assigned at creation.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Lower-prioritygetroutes: return more detailed fields in routes[].by Rusty Russell · 6206d02d · May 11, 2026 · 9 filesMessage 73 · AdequateTriage 0Details
Commit message · Rusty Russell

getroutes: return more detailed fields in routes[].

This reflects a long-standing complaint from @lagrang3 when the API
was first implemented, and I should have listened. In particular, the
impedance mismatch with the sendpay API is annoying.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `getroutes` `route` explicit fields `node_id_in`, `node_id_out`, `amount_in_msat`, `amount_out_msat`, `cltv_in`, `cltv_out`.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityxpay: add xkeysend support.by Rusty Russell · 78721c7f · May 11, 2026 · 5 filesMessage 58 · ThinTriage 0Details
Commit message · Rusty Russell

xpay: add xkeysend support.

This uses askrene, so it benefits from previous payment experience.

Changelog-Added: JSON-RPC: `xkeysend` command for keysend with modern routing support.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Lower-prioritypytest: use xpay, not pay in misc tests.by Rusty Russell · 7f6a3339 · May 11, 2026 · 17 filesMessage 78 · AdequateTriage 0Details
Commit message · Rusty Russell

pytest: use xpay, not pay in misc tests.

This usually means changing the error strings, where we test them, and
avoiding `paystatus`.

Other changes:
1. Completely get rid of `test_custom_notification_topics`: xpay tests do this
already.
2. Add xpay wrapper to pyln-client so we can mix named and unnamed args.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Lower-prioritybolt12: import draft payer proof spec.by Rusty Russell · adc42215 · May 11, 2026 · 3 filesMessage 60 · AdequateTriage 0Details
Commit message · Rusty Russell

bolt12: import draft payer proof spec.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Lower-prioritydevtools/bolt12-cli: add missing offer_metadata field.by Rusty Russell · 48c6697d · May 11, 2026 · 1 fileMessage 65 · AdequateTriage 0Details
Commit message · Rusty Russell

devtools/bolt12-cli: add missing offer_metadata field.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Lower-prioritycommon: fix over-allocation in merkle tree creation.by Rusty Russell · 05a26932 · May 11, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · Rusty Russell

common: fix over-allocation in merkle tree creation.

If we have 5 fields, ilog64(5) is 3, and (1 << 3) is 8. Adding one
made it 16.

In fact, since ilog64(4) is also 3, we should *subtract one*, but
this handles 0 more neatly (ilog64(0) is defined to return 0, as
a special case).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Security candidatecommon: expose is_signature_field as is_tlv_signature_field.by Rusty Russell · bc2411b5 · May 11, 2026 · 2 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

common: expose is_signature_field as is_tlv_signature_field.

Proof code needs this.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit simply renames an internal helper function and makes it publicly available in a header file so other parts of the codebase can use it. There is no bug fix, behavior change, or security-sensitive logic alteration. It is a routine code-organization change.

Lower-prioritycommon: routines to create and validate payer proofs.by Rusty Russell · 325b52d2 · May 11, 2026 · 6 filesMessage 73 · AdequateLow 28Details
Commit message · Rusty Russell

common: routines to create and validate payer proofs.

Claude helped debug, using the LDK implementation at first, then
modified heavily.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
defensive validation
AI analysis · Low 28/100

This commit adds new code for creating and checking 'payer proofs' in Core Lightning, a feature used with BOLT 12 invoices. A payer proof lets someone who paid an invoice selectively reveal parts of it while keeping other parts hidden. The change is a new feature implementation, not a fix for a known bug or vulnerability. There is no evidence in the commit message or diff that this is a security patch or that it addresses any disclosed issue.

Lower-prioritycommon: add bolt12 payer proof support (bolt12-cli)by Vincenzo Palazzo · 94bebdef · May 11, 2026 · 1 fileMessage 50 · ThinTriage 0Details
Commit message · Vincenzo Palazzo

common: add bolt12 payer proof support (bolt12-cli)

[Adapted for my decode routines --RR]

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Lower-prioritybolt12: generate payer_proof JSON test vectors.by Rusty Russell · 22b0a1c9 · May 11, 2026 · 3 filesMessage 78 · AdequateInformational 13Details
Commit message · Rusty Russell

bolt12: generate payer_proof JSON test vectors.

Create canonical JSON test vectors, using SUPERVERBOSE. We remove the
ones from bolt12_merkle.c.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidence
AI analysis · Informational 13/100

This commit is a test-infrastructure change for Core Lightning's BOLT 12 payer proof implementation. It removes debug logging from the production merkle code and adds a new test program that prints canonical JSON test vectors. There is no change to security-sensitive runtime behavior, no bug fix, and no disclosed vulnerability.

AI review queuedoffers: add createproof API.by Rusty Russell · 9dda3eec · May 11, 2026 · 13 filesMessage 58 · ThinInformational 22Details
Commit message · Rusty Russell

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>

58/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context
Why it was queued
parser or protocol pathsecond-pass: security-sensitive path
AI analysis · Informational 22/100

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.

AI review queuedcommon/bolt12: use a const char * for fail reason.by Rusty Russell · 1189175c · May 11, 2026 · 28 filesMessage 65 · AdequateInformational 22Details
Commit message · Rusty Russell

common/bolt12: use a const char * for fail reason.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
parser or protocol pathsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Informational 22/100

This commit is a code-quality refactor across many files. It changes the 'failure reason' string returned by BOLT11/BOLT12 decoding functions from a mutable 'char *' to a read-only 'const char *'. It also exposes a previously internal helper function and adds memory ownership fixes so callers don't accidentally use freed error strings. There is no direct evidence in the commit message or diff that this fixes an active security vulnerability, but it removes a class of potential memory-management mistakes and makes the API safer for future callers.

AI review queueddecode: fix decode on recurring offers.by Rusty Russell · c23ee375 · May 11, 2026 · 6 filesMessage 78 · AdequateInformational 23Details
Commit message · Rusty Russell

decode: fix decode on recurring offers.

We no longer have offer_recurrence, we have
offer_recurrence_compulsory and offer_recurrence_optional. Decode was
changed in v25.12, but we never properly tested it (recurrence is
experimental, after all).

I opted for simplicity over truth here, and simply modified decode to
match the schema, but add a "compulsory" flag.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
parser or protocol pathsecond-pass: security-sensitive path
AI analysis · Informational 23/100

This commit fixes a bug in Core Lightning's `decode` command for recurring payment offers. A previous code change split one offer field into two variants (compulsory and optional), but the `decode` output was not updated to match the new schema. The fix makes `decode` report a single `offer_recurrence` block with a new boolean flag indicating whether recurrence is compulsory. It is a correctness/API bug, not a direct funds-loss vulnerability, because it affects an experimental feature and would mainly cause decoding errors or misleading output rather than unauthorized payments.

Lower-prioritycommon: generalize BOLT12 merkle generation.by Rusty Russell · 5c851ab9 · May 11, 2026 · 2 filesMessage 60 · AdequateTriage 0Details
Commit message · Rusty Russell

common: generalize BOLT12 merkle generation.

Allow a callback to tell us the hash of unknown branches.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Lower-prioritycommon: add test for partial merkle tree support.by Rusty Russell · 64f13406 · May 11, 2026 · 2 filesMessage 70 · AdequateTriage 0Details
Commit message · Rusty Russell

common: add test for partial merkle tree support.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification