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

1855 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 queue1555AI analyses
144commits · 30 days
227commits · 60 days
805commits · 180 days
1851commits · 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
1164Adequate · 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.
dovgopoly15015164
Rusty Russell95873770072
Sangbida Chaudhuri14731141066
Dusty Daemon771366066
ShahanaFarooqui931078063
daywalker9090587062
Níckolas Goline40540076
Lagrang376465069
Christian Decker36429072
Vincenzo Palazzo838080
Chandra Pratap56250082
ekzyis222063
Analysis record

Published AI watches

Last scanned 24 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.

AI review queuedpytest: test for crash when enableoffer called on a used single-use offer.by Rusty Russell · e2d17cea · Feb 2, 2026 · 1 fileMessage 83 · StrongLow 42Details
Commit message · Rusty Russell

pytest: test for crash when enableoffer called on a used single-use offer.

Assertion happens here:

newstatus = offer_status_in_db(s | OFFER_STATUS_ACTIVE_F);

Since OFFER_STATUS_SINGLE_F|OFFER_STATUS_USED_F|OFFER_STATUS_ACTIVE_F
is not a valid combination:

```
lightningd-3 2026-01-28T04:45:21.184Z **BROKEN** lightningd: offer_status_in_db: 7 is invalid
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: FATAL SIGNAL 6 (version v25.12-92-g7fff32d-modded)
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: common/daemon.c:83 (crashdump) 0x5a883759dbb7
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x79a2b0c4532f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:44 (__pthread_kill_implementation) 0x79a2b0c9eb2c
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:78 (__pthread_kill_internal) 0x79a2b0c9eb2c
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:89 (__GI___pthread_kill) 0x79a2b0c9eb2c
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ../sysdeps/posix/raise.c:26 (__GI_raise) 0x79a2b0c4527d
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./stdlib/abort.c:79 (__GI_abort) 0x79a2b0c288fe
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/log.c:1054 (fatal_vfmt) 0x5a8837509557
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/log.c:1064 (fatal) 0x5a88375095fe
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ./wallet/wallet.h:1451 (offer_status_in_db) 0x5a88375491dc
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: wallet/wallet.c:6160 (offer_status_in_db) 0x5a8837555388
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: wallet/wallet.c:6162 (wallet_offer_enable) 0x5a8837555388
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/offer.c:288 (json_enableoffer) 0x5a8837540939
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:769 (command_exec) 0x5a8837503198
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:910 (rpc_command_hook_final) 0x5a8837503198
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:884 (rpc_command_hook_final) 0x5a8837503198
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:243 (hook_done) 0x5a8837535383
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/plugin_hook.c:343 (plugin_hook_call_next) 0x5a8837535383
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:998 (plugin_hook_call_rpc_command) 0x5a8837503c4f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:1123 (parse_request) 0x5a8837503c4f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/jsonrpc.c:1217 (read_json) 0x5a8837503c4f
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:60 (next_plan) 0x5a88375eca38
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:422 (do_plan) 0x5a88375eca38
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:439 (io_ready) 0x5a88375eca38
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:470 (io_loop) 0x5a88375eead5
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x5a8837501f8e
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: lightningd/lightningd.c:1492 (main) 0x5a88374d3c27
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x79a2b0c2a1c9
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: ../csu/libc-start.c:360 (__libc_start_main_impl) 0x79a2b0c2a28a
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0x5a88374d5aa4
lightningd-3 2026-01-28T04:45:21.260Z **BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff
```

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

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Low 42/100

This commit adds a test that exposes a bug in Core Lightning: if you try to re-enable a single-use offer that has already been used, the daemon hits an internal assertion and crashes. The test is marked as expected-to-fail for now, meaning the actual crash is not fixed by this commit—it only documents the failure. A user with RPC access could trigger a denial-of-service by calling enableoffer on a used single-use offer.

AI review queuedlightningd: don't allow enableoffer on single-use offer.by 21M4TW · d76e4e71 · Feb 2, 2026 · 3 filesMessage 65 · AdequateLow 44Details
Commit message · 21M4TW

lightningd: don't allow enableoffer on single-use offer.

Changelog-Fixed: enableoffer: Adding an error when trying to activate an used single use offer (don't crash!)

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
second-pass: broader security terminology
AI analysis · Low 44/100

This commit fixes a bug in Core Lightning's offer management. A 'single-use offer' is meant to be used once and then become inactive. Previously, calling the enableoffer command on an already-used single-use offer could cause the node to crash. The fix adds a clear error message instead of crashing. It also removes an 'expected failure' marker from a related test, meaning that test now passes.

Lower-priorityaskrene: remove unnecessary print in testby Lagrang3 · bb3be7e8 · Feb 1, 2026 · 1 fileMessage 70 · AdequateInformational 15Details
Commit message · Lagrang3

askrene: remove unnecessary print in test

Changelog-None

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>

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

This commit simply removes a leftover debug print statement from a test file. It has no effect on the actual Core Lightning software users run, no security implications, and does not change any behavior beyond making one test slightly less noisy in its output.

Lower-priorityaskrene: fixed a timeout corner caseby Lagrang3 · f1bf66c9 · Feb 1, 2026 · 2 filesMessage 68 · AdequateLow 32Details
Commit message · Lagrang3

askrene: fixed a timeout corner case

Changelog-Fixed: askrene: fixed a class of corner cases that cause askrene main loop to timeout instead of quickly failing, thus wasting runtime.

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 32/100

This commit fixes a bug in Core Lightning's payment routing plugin (askrene) where certain impossible or severely constrained payments would make the routing engine loop until a timeout instead of quickly giving up. The fix detects tiny or nearly-undeliverable payment paths, disables the bottleneck channel, and removes the bad path so the engine can fail fast. It is a denial-of-service/availability issue rather than theft of funds, and it only affects routing attempts that already violate constraints.

Lower-priorityaskrene: add test that triggers infinite loopby Lagrang3 · 597da1fe · Feb 1, 2026 · 1 fileMessage 70 · AdequateLow 25Details
Commit message · Lagrang3

askrene: add test that triggers infinite loop

Changelog-None

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>

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

This commit only adds a new test case for the askrene routing module. The test is marked to be skipped and demonstrates a scenario where an impossible payment could cause askrene's main loop to run forever. It does not change any production code, so it cannot by itself introduce or fix a vulnerability. It is a diagnostic test that documents a potential bug.

Lower-priorityaskrene: consider fees during *explain failure*by Lagrang3 · 41a5c68a · Feb 1, 2026 · 1 fileMessage 68 · AdequateLow 37Details
Commit message · Lagrang3

askrene: consider fees during *explain failure*

We would try to explain a failure by simply finding a path between
source and destination and then checking the constraints.
However, we did not add fees.

Changelog-None

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 37/100

This commit fixes a bug in Core Lightning's 'askrene' plugin, which is used to explain why a Lightning Network payment failed. Previously, when explaining a failure, the plugin checked whether each channel along a route could carry the payment amount, but it ignored the fees that must also be carried by earlier channels. This could cause askrene to incorrectly report that a path should have worked, or to miss the real reason a payment failed. The fix calculates the rolling amount including fees from destination back to source, and uses that larger amount when checking channel capacity and limits.

AI review queuedfuzz-tests: Add coverage increasing inputs to seed corporaby Chandra Pratap · 461ca686 · Jan 30, 2026 · 31 filesMessage 83 · StrongInformational 15Details
Commit message · Chandra Pratap

fuzz-tests: Add coverage increasing inputs to seed corpora

Improvements in the fuzz-testing scheme of
`fuzz-bolt12-offer-decode` led to the discovery of test inputs
that result in greater in code coverage.

Add these inputs to the test's seed corpus.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidenceparser or protocol pathsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only adds 31 new test input files to a fuzz-testing seed corpus for BOLT12 offer decoding. It does not change any production code, so it cannot introduce or fix a runtime security vulnerability on its own. It is a routine test-data update intended to improve code-coverage during automated fuzzing.

AI review queuedfuzz-tests: Make `fuzz-bolt12-offer-decode` roundripby Chandra Pratap · 557a744b · Jan 30, 2026 · 1 fileMessage 91 · StrongInformational 15Details
Commit message · Chandra Pratap

fuzz-tests: Make `fuzz-bolt12-offer-decode` roundrip

Changelog-None: Currently, the `BOLT #12` offer parsing test only
tests the offer decode function. Add a test for the encoding
function as well by making the test roundtrip.

91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
fuzzing or regression evidenceparser or protocol pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only changes a fuzz test file. It extends an existing test for BOLT 12 offer decoding to also check that re-encoding the decoded offer produces the same result (a roundtrip test). It does not modify any production code, so it cannot introduce a runtime security vulnerability in the Core Lightning software itself.

Lower-priorityDocs: Update mac instructions to gmakeby Dusty Daemon · 4c10cb76 · Jan 29, 2026 · 1 fileMessage 92 · StrongInformational 15Details
Commit message · Dusty Daemon

Docs: Update mac instructions to gmake

Apple bundles a rather old version of GNU Make: 3.81. Our Makefiles use the &: feature which requires version 4.3. Apparently Apple isn’t updating GNU Make anymore due to a licensing issue.

Switching the instructions over to using gmake installed from the brew package manager, which currently installs 4.4.1

Changelog-None

92/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
documentation-only discount
AI analysis · Informational 15/100

This commit only updates the macOS build instructions in the documentation. It tells users to install a newer version of GNU Make (called 'gmake') from Homebrew instead of using the old 'make' that Apple ships. There is no code change and no security issue.

Lower-prioritycommon: tighten restrictions on periods, as per latest draft.by Rusty Russell · cc227ed2 · Jan 29, 2026 · 1 fileMessage 65 · AdequateLow 40Details
Commit message · Rusty Russell

common: tighten restrictions on periods, as per latest draft.

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
AI analysis · Low 40/100

This change adds stricter validation rules when a Core Lightning node receives a BOLT12 offer that includes recurring payment terms. It now rejects offers with invalid time units, zero-length periods, zero recurrence limits, or recurrence-related fields that appear without an actual recurrence definition. This prevents the node from accepting malformed or contradictory offers that could lead to confusion, failed payments, or protocol edge-case abuse.

Lower-priorityaskrene: add auto.include_fees layerby Lagrang3 · 3822a670 · Jan 29, 2026 · 4 filesMessage 68 · AdequateInformational 21Details
Commit message · Lagrang3

askrene: add auto.include_fees layer

Changelog-Added: askrene: add a new layer auto.include_fees thhat makes fees be deducted from the payment amount making in effect the receiver pay for routing fees.

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 21/100

This commit adds a new optional routing layer called auto.include_fees to Core Lightning's askrene plugin. Normally, when sending a Lightning payment, the sender adds extra money on top of the requested amount to cover routing fees. With this new layer, the total amount sent is fixed, and the fees are subtracted from what the receiver gets instead. This is a deliberate feature change, not a bug fix, and it only affects routing calculations when a user explicitly requests the new layer. There is no direct security vulnerability in the code shown, but any mistake in fee arithmetic could in theory cause incorrect payment amounts.

Lower-priorityfix: build on Alpine Linuxby Marcel Hernandez · 3917cee8 · Jan 28, 2026 · 1 fileMessage 80 · StrongInformational 15Details
Commit message · Marcel Hernandez

fix: build on Alpine Linux

Reference: https://github.com/ElementsProject/lightning/commit/53154a40a55ab803ceef0dcc8e62f7424111714a

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
AI analysis · Informational 15/100

This is a one-line build fix for Alpine Linux. It adds a missing #include <unistd.h> header in a source file so the code compiles correctly on that platform. There is no security issue here.

Lower-priorityMakefile: improve print-binary-sizes to be more meaningful.by Rusty Russell · c8eb54be · Jan 28, 2026 · 1 fileMessage 91 · StrongInformational 15Details
Commit message · Rusty Russell

Makefile: improve print-binary-sizes to be more meaningful.

Users care about memory more than disk, and they care about programs
they run more than our test programs and tools.

Also, fix dependencies on print-binary-sizes, as spotted by
https://github.com/Lagrang3

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

91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
AI analysis · Informational 15/100

This commit changes a Makefile helper target that prints the sizes of compiled programs. It switches from reporting disk file sizes to reporting memory sizes (using the 'size' tool), includes additional binary categories, and fixes a build dependency. There is no security relevance in the change itself.

Lower-priorityBuild: add function sections.by Rusty Russell · 744432dd · Jan 28, 2026 · 1 fileMessage 70 · AdequateInformational 15Details
Commit message · Rusty Russell

Build: add function sections.

This allows further reduction in binary sizes.

Size of all user before:
text data bss dec hex filename
64277932 904968 317576 65500476 3e7753c (TOTALS)

After:
52443036 729560 271720 53444316 32f7edc (TOTALS)

Some are dramatic, such as lightning-cli not pulling in libbacktrace:

174454 2880 296 177630 2b5de cli/lightning-cli
56633 2608 232 59473 e851 cli/lightning-cli

But most things get a 25% trim:

3972339 363568 21760 4357667 427e23 lightningd/lightningd
3300337 247768 21664 3569769 367869 lightningd/lightningd

Changelog-Changed: Build: most binaries are now about 20% smaller.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit is a build-system optimization that makes the compiled program files smaller by telling the linker to discard unused code sections. It does not change any program behavior or fix any security issue.

Lower-priorityconfigure: remove gratuitous CSANFLAGS print.by Rusty Russell · bb7602cd · Jan 28, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Rusty Russell

configure: remove gratuitous CSANFLAGS print.

It's printed at the bottom, no need to print as we're determining it.

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
AI analysis · Informational 15/100

This commit simply removes a debug line that printed the value of a compiler flag variable during the build configuration step. It is a cleanup change with no security relevance.

Lower-prioritypatch configure-check-function-sections.patchby Rusty Russell · 01c1264c · Jan 28, 2026 · 1 fileMessage 45 · ThinInformational 18Details
Commit message · Rusty Russell

patch configure-check-function-sections.patch

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
AI analysis · Informational 18/100

This commit changes the build configuration script so it tests whether the compiler supports a size-optimization feature (placing each function in its own section and removing unused ones during linking). It is a build-system hardening/optimization change, not a fix for an exploitable vulnerability. There is no indication in the commit that it addresses a security issue.

Lower-prioritypytest: also make sure askrene doesn't suffer when reloading many layers on startup.by Rusty Russell · c7d313ea · Jan 27, 2026 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Rusty Russell

pytest: also make sure askrene doesn't suffer when reloading many layers on startup.

We used non-persistent layers before, but what if we save to the datastore and restore?

This takes it from 29 to 45 seconds.

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
AI analysis · Informational 15/100

This commit only changes a benchmark test file. It extends an existing performance test for the askrene feature to also measure startup time after saving and restoring many layers. There is no security-relevant change to production code, no bug fix, and no vulnerability patch.

Lower-priorityaskrene: speed up when using large number of layers.by Rusty Russell · a3946663 · Jan 27, 2026 · 5 filesMessage 73 · AdequateInformational 15Details
Commit message · Rusty Russell

askrene: speed up when using large number of layers.

Simple bench.

Before:
Creating 20,000 layers: 20 seconds
Creating 50,000 layers: 107 seconds

After:
Creating 20,000 layers: 7 seconds
Creating 50,000 layers: 15 seconds
Creating 100,000 layers: 29 seconds

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
AI analysis · Informational 15/100

This commit is a straightforward performance optimization for the askrene plugin. It replaces a slow linked-list lookup of routing 'layers' with a fast hash table, dramatically speeding up operations when many layers exist. There is no security-relevant change here.

Lower-prioritypytest: add askrene layer creation bench.by Rusty Russell · ff609833 · Jan 27, 2026 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Rusty Russell

pytest: add askrene layer creation bench.

This means it has to do a lookup and an insert.

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
AI analysis · Informational 15/100

This commit adds a new performance benchmark test to the project's test suite. It exercises a feature called 'askrene' by creating 20,000 empty layers through the normal RPC interface. There is no change to production code, no bug fix, and no security-related behavior.

Lower-prioritypytest: test upfront_shutdown_script with new-style hsm_secret too.by Sangbida Chaudhuri · 129b2077 · Jan 26, 2026 · 1 fileMessage 60 · AdequateInformational 15Details
Commit message · Sangbida Chaudhuri

pytest: test upfront_shutdown_script with new-style hsm_secret too.

60/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
AI analysis · Informational 15/100

This commit only adds a new test case to the project's test suite. It extends an existing test to also run with a newer wallet format (BIP86 mnemonic), ensuring the upfront shutdown script feature works for both old and new wallet types. There is no change to production code, no bug fix, and no security patch.

Lower-prioritypytest: parameterize test_showrunes.by Rusty Russell · b2b03e6e · Jan 26, 2026 · 1 fileMessage 50 · ThinInformational 15Details
Commit message · Rusty Russell

pytest: parameterize test_showrunes.

Another one we want to make sure stays unchanged.

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

50/100 · ThinMessage clarity
✓ Descriptive subject✓ Provides an explanatory body
AI analysis · Informational 15/100

This commit only updates a test file. It makes an existing test run twice—once with an old-style secret key and once with a new-style secret key—and checks that the expected rune values differ in each case. There is no change to production code, no bug fix, and no security patch.

Security candidatepytest: make sure to use old_hsmsecret on downgrade tests.by Rusty Russell · c7973b8a · Jan 26, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell

pytest: make sure to use old_hsmsecret on downgrade tests.

We only support downgrade if you upgraded, so your hsm_secret will be old.

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

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
update trust
AI analysis · Informational 15/100

This change only updates a test file so that downgrade tests create nodes using an older-format secret key file. It does not change any production code, network protocol, or wallet behavior, and there is no security issue in the commit itself.

Lower-prioritypytest: determine scid direction dynamicallyby Sangbida Chaudhuri · 6a9bdb80 · Jan 26, 2026 · 1 fileMessage 90 · StrongInformational 15Details
Commit message · Sangbida Chaudhuri

pytest: determine scid direction dynamically

Since we have changed our hsm_secret seed the node ids have all change hence the asseertions on the scids break. This changes it so that the direction is determined when the test executes.

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit only updates test code. It changes hard-coded channel direction numbers in pytest test expectations to be calculated at runtime based on node IDs. The reason is that a recent change to the test secret seed changed all generated node IDs, which flipped which channel direction value (0 or 1) the tests should expect. There is no change to production code, no security fix, and no vulnerability.

AI review queuedpytest: use old hsm secret whenever a canned database files is usedby Sangbida Chaudhuri · 81d1d4a3 · Jan 26, 2026 · 8 filesMessage 65 · AdequateInformational 17Details
Commit message · Sangbida Chaudhuri

pytest: use old hsm secret whenever a canned database files is used

Anything using a canned db depends on the node ids being generated from the old hsm seed.

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

This commit only changes test files. It tells the test framework to use an older, fixed HSM (wallet seed) secret whenever a test loads a pre-made ('canned') database snapshot. This ensures the test node's public identity matches the one recorded in the snapshot, so database migration and regression tests keep working after a recent change to how random seeds are generated. It is a test-suite maintenance patch, not a fix for a runtime security vulnerability.

Lower-prioritypytest: use hsmtool's getsecret instead of deprecated getcodexsecret, parameterize test_recover_command.by Rusty Russell · 12bc5b04 · Jan 26, 2026 · 2 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

pytest: use hsmtool's getsecret instead of deprecated getcodexsecret, parameterize test_recover_command.

This matters for mnemonic nodes.

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
AI analysis · Informational 15/100

This is a routine test-only change. It updates two test scripts to use a newer, non-deprecated command name ('getsecret' instead of 'getcodexsecret') in the lightning-hsmtool helper, and expands test coverage for recovery with both old-style and new-style HSM secrets. There is no change to production code, no user-facing behavior change, and no security fix.