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 queue1094AI 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.
dovgopoly15014164
Rusty Russell95873524072
Sangbida Chaudhuri14731126066
Dusty Daemon771358066
ShahanaFarooqui931035063
daywalker9090580062
Níckolas Goline40540076
Lagrang376458069
Christian Decker36412072
Vincenzo Palazzo838080
Chandra Pratap56250082
ekzyis222063
Analysis record

Published AI watches

Last scanned 31 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-prioritypytest: fix flake in test_gossip_force_broadcast_channel_msgsby Rusty Russell · 21c2c0f9 · Feb 20, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell

pytest: fix flake in test_gossip_force_broadcast_channel_msgs

With the extra padding pings, we can get more!

```
# Make sure the noise is within reasonable bounds
assert tally['query_short_channel_ids'] <= 1
assert tally['query_channel_range'] <= 1
> assert tally['ping'] <= 3
E assert 4 <= 3

tests/test_gossip.py:2396: AssertionError
```

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

This commit adjusts a single test assertion in a Python test file. The test was occasionally failing because the number of network 'ping' messages observed during gossip testing could be 4 instead of the previously allowed maximum of 3. The fix simply raises the allowed threshold from 3 to 5. It does not change any production code, protocol behavior, or security logic.

Lower-prioritypytest: make test_no_delay more robust.by Rusty Russell · d0c158a6 · Feb 20, 2026 · 8 filesMessage 78 · AdequateInformational 18Details
Commit message · Rusty Russell

pytest: make test_no_delay more robust.

Unfortunately the effect of leaving Nagle enabled is subtle. Here it
is in v25.12:

Normal:
tests/test_connection.py::test_no_delay PASSED
====================================================================== 1 passed in 13.87s

Nagle enabled:
tests/test_connection.py::test_no_delay PASSED
====================================================================== 1 passed in 21.70s

So it's hard to both catch this issue and not have false positives. Improve the
test by deliberately running with Nagle enabled, so we can do a direct comparison.

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

This commit is a test-hardening change. It adds a developer-only flag that lets Core Lightning deliberately keep Nagle's algorithm enabled on TCP sockets, then uses that flag to compare slow vs. fast behavior in an existing test. The production code still disables Nagle by default, so ordinary users are not exposed to any new vulnerability. The change improves the test's ability to detect accidental regressions where Nagle might be left on.

Lower-prioritypytest: fix flake in test_important_plugin node failure.by Rusty Russell · ffb8d860 · Feb 20, 2026 · 1 fileMessage 73 · AdequateInformational 14Details
Commit message · Rusty Russell

pytest: fix flake in test_important_plugin node failure.

xpay can get upset if askrene goes away first:

lightningd-1 2026-02-18T02:47:44.908Z **BROKEN** plugin-cln-xpay: askrene-create-layer failed with {"code":-32601,"message":"Unknown command 'askrene-create-layer'"}

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 14/100

This is a one-line change to a test file that adds another expected log message to ignore during a test. The test deliberately starts a node with a missing important plugin, which causes the node to shut down abruptly. During that shutdown, the xpay plugin sometimes logs a harmless error because another plugin (askrene) has already gone away. The fix simply tells the test framework to expect that extra log line so the test does not randomly fail. It is not a security fix and does not change any production code.

Lower-prioritypytest: fix timeout flake in test_dataloss_protectionby Rusty Russell · 10eb2c2c · Feb 20, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell

pytest: fix timeout flake in test_dataloss_protection

This test restarts l2 twice. Each time, l1 is reconnecting, and backs
off. If the test is slow enough, the backoff gets extreme:

```
2026-02-19T02:13:03.7669982Z lightningd-1 2026-02-19T01:50:56.541Z DEBUG 033845802d25b4e074ccfd7cd8b339a41dc75bf9978a034800444b51d42b07799a-lightningd: peer_disconnected
2026-02-19T02:13:03.7670444Z lightningd-1 2026-02-19T01:50:56.547Z DEBUG 033845802d25b4e074ccfd7cd8b339a41dc75bf9978a034800444b51d42b07799a-connectd: Will try reconnect in 256 seconds
```

This isn't a bug! The backoff caps at 300 seconds, and only gets
reset if we remain connected for that long.

A manual reconnect here not only fixes the flake, but make the test
much faster, by not *doubling* the time for slow tests as shown on my
laptop (the final test using `taskset -c 1`):

Normal Valgrind Valgrind, 1 CPU
Before: 22sec 124sec 230sec
After: 18sec 102sec 191sec

These are from a single run: it could be much more in the worst case.

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

This commit fixes a flaky automated test, not a security bug. The test was sometimes timing out because one node kept waiting longer and longer to reconnect after the other node restarted. The fix manually triggers a reconnect so the test completes faster and more reliably. There is no change to production code or user-facing behavior.

Lower-prioritypytest: fix flakes in test_onchain_reestablish_reply and test_reestablish_closed_channelsby Rusty Russell · 000462c2 · Feb 20, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell

pytest: fix flakes in test_onchain_reestablish_reply and test_reestablish_closed_channels

We can have:
1. A slow test, so we're near the 60 second tolerance for bitcoind failures.
2. On shutdown, we fail and we hit the limit.

```
lightningd-2 2026-02-18T02:21:19.642Z **BROKEN** plugin-bcli: bitcoin-cli -regtest -datadir=/tmp/ltests-f3nd9ykw/test_reestablish_closed_channels_1/lightning-2/ -rpcclienttimeout=60 -rpcport=57403 -rpcuser=... -stdinrpcpass -stdin getblockhash 104 exited 1 (after 58 other errors) 'error: JSON value of type null is not of expected type number
lightningd-2 2026-02-18T02:21:19.642Z **BROKEN** plugin-bcli: '; we have been retrying command for --bitcoin-retry-timeout=60 seconds; bitcoind setup or our --bitcoin-* configs broken?
lightningd-2 2026-02-18T02:21:19.642Z INFO plugin-bcli: Killing plugin: exited during normal operation
lightningd-2 2026-02-18T02:21:19.642Z **BROKEN** lightningd: The Bitcoin backend died.
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: FATAL SIGNAL 6 (version 7f635ff-modded)
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: /home/runner/work/lightning/lightning/common/daemon.c:46 (send_backtrace) 0x562ab3ef1307
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: /home/runner/work/lightning/lightning/common/daemon.c:83 (crashdump) 0x562ab3ef2758
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x7fd7e584532f
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:44 (__pthread_kill_implementation) 0x7fd7e589eb2c
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:78 (__pthread_kill_internal) 0x7fd7e589eb2c
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: ./nptl/pthread_kill.c:89 (__GI___pthread_kill) 0x7fd7e589eb2c
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: ../sysdeps/posix/raise.c:26 (__GI_raise) 0x7fd7e584527d
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: ./stdlib/abort.c:79 (__GI_abort) 0x7fd7e58288fe
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: /home/runner/work/lightning/lightning/lightningd/log.c:1128 (fatal_vfmt) 0x562ab3bc7675
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: /home/runner/work/lightning/lightning/lightningd/log.c:1138 (fatal) 0x562ab3bc77db
lightningd-2 2026-02-18T02:21:19.865Z **BROKEN** lightningd: backtrace: /home/runner/work/lightning/lightning/lightningd/bitcoind.c:27 (bitcoin_destructor) 0x562ab3a4ae63
lightningd-2 2026-02-18T02:21:19.866Z **BROKEN** lightningd: backtrace: /home/runner/work/lightning/lightning/ccan/ccan/tal/tal.c:246 (notify) 0x562ab40d5d52
lightningd-2 2026-02-18T02:21:19.866Z **BROKEN** lightningd: backtrace: /home/runner/work/lightning/lightning/ccan/ccan/tal/tal.c:437 (del_tree) 0x562ab40d6d5a
lightningd-2 2026-02-18T02:21:19.866Z **BROKEN** lightningd: backtrace: /home/runner/work/lightning/lightning/ccan/ccan/tal/tal.c:532 (tal_free) 0x562ab40d66f0
lightningd-2 2026-02-18T02:21:19.866Z **BROKEN** lightningd: backtrace: /home/runner/work/lightning/lightning/lightningd/plugin.c:469 (plugin_kill) 0x562ab3cd9112
```

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

This change only adjusts two automated test cases to prevent them from randomly failing in the project's own test suite. It does not change the actual Core Lightning software that users run, and it does not fix or introduce any security issue in production code.

Lower-priorityaskrene: make minflow() static, and remove unused linear_flow_cost.by Rusty Russell · e397b122 · Feb 19, 2026 · 2 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

askrene: make minflow() static, and remove unused linear_flow_cost.

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 code cleanup in Core Lightning's routing plugin. It makes two internal functions private (static) and removes one unused helper function. There is no security-relevant change: no bug is fixed, no behavior is altered, and no externally reachable interface is changed.

Lower-prioritybitcoin: hash_scid and hash_scidd public functions.by Rusty Russell · d9774e73 · Feb 19, 2026 · 11 filesMessage 73 · AdequateInformational 15Details
Commit message · Rusty Russell

bitcoin: hash_scid and hash_scidd public functions.

We reimplemented this redundantly: hash_scid was called
short_channel_id_hash, so I obviously missed it.

Rename, and implement hash_scidd helper too.

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 routine code cleanup: it renames an internal hash function and consolidates duplicate copies of the same hashing logic into one shared helper. There is no user-facing change, no bug fix, and no security-relevant behavior change.

Lower-priorityaskrene: remove non child-friendly fields from struct route_query.by Rusty Russell · 0f575ac8 · Feb 19, 2026 · 7 filesMessage 73 · AdequateInformational 11Details
Commit message · Rusty Russell

askrene: remove non child-friendly fields from struct route_query.

Notably no access to the struct command and struct plugin.

Note: we actually *do* mess with askrene->reserves, but the previous code
used cmd to get to it. Now we need to include a non-const pointer in
struct route_query.

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 11/100

This is a code cleanup change in Core Lightning's routing plugin (askrene). It removes direct access to the command and plugin objects from an internal data structure used during route calculations, passing only the specific pieces of information the child process needs instead. This is a defensive design improvement, not a fix for an active security bug.

Lower-prioritycommon: fix `bad cupdates` count in gossmap.cby Rusty Russell · a84ad108 · Feb 19, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Rusty Russell

common: fix `bad cupdates` count in gossmap.c

I noticed this in the logs:

```
lightningd-1 2026-01-28T00:27:37.504Z DEBUG gossipd: gossip_store: Read 59428/118856/0/0 cannounce/cupdate/nannounce/delete from store in 45521871 bytes, now 45521849 bytes (populated=true)
lightningd-1 2026-01-28T00:27:37.504Z DEBUG gossipd: Got 118856 bad cupdates, ignoring them (expected on mainnet)
```

That's weird, and turns out it counting good updates, not bad ones!

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 is a one-line logging fix. The code was counting successful channel updates as 'bad' channel updates in a debug log message. The fix flips the boolean so the counter increments only when an update actually fails. It does not change any network behavior, validation rules, or security logic.

Lower-prioritylibplugin: add command_finish_rawstr() for when we're simply repeating an entore response.by Rusty Russell · 9bcac634 · Feb 19, 2026 · 2 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

libplugin: add command_finish_rawstr() for when we're simply repeating an entore response.

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 commit adds a new helper function that lets plugin code send a pre-built JSON response directly, instead of building it piece by piece. It is a straightforward internal code refactor with no obvious security relevance.

Lower-prioritypytest: rework test_real_data and test_real_biases to be parallel.by Rusty Russell · ab3e7c31 · Feb 19, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Rusty Russell

pytest: rework test_real_data and test_real_biases to be parallel.

This speeds them up, and exercises the askrene parallel code.

Before: test_real_data: 348s test_real_biases: 105s

After: test_real_data: 133s test_real_biases: 106s

And this is because much of the time is spent uncompressing the gossmap
and startup.

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

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Informational 15/100

This commit only changes test code. It rewrites two slow pytest test functions to submit RPC calls in parallel using a thread executor, which makes one test run faster and exercises Core Lightning's askrene parallel-routing code path. There is no change to production code, no bug fix, and no security relevance visible in the diff or commit message.

Lower-priorityaskrene: close files in child to isolate against bugs.by Rusty Russell · d5c2c486 · Feb 19, 2026 · 1 fileMessage 73 · AdequateLow 34Details
Commit message · Rusty Russell

askrene: close files in child to isolate against bugs.

This makes sure it cannot interfere with the parent askrene's
connection to lightningd, for example.

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 · Low 34/100

This change is a hardening fix in a Core Lightning plugin called askrene. When askrene spawns a child process to do heavy route-finding work, the child previously inherited all of the parent's open file descriptors (network sockets, pipes, files). If the child had a bug, it could accidentally write to or close those inherited descriptors, disrupting the plugin's connection to the main lightningd daemon. The patch makes the child close most inherited file descriptors (keeping only standard error) so a buggy child cannot interfere with the parent's communication channels.

Lower-priorityaskrene: make "child.c" to be the explicit child entry point.by Rusty Russell · 6903cf2e · Feb 19, 2026 · 5 filesMessage 73 · AdequateInformational 11Details
Commit message · Rusty Russell

askrene: make "child.c" to be the explicit child entry point.

The fork logic itself is pretty simple, so do that directly in
askrene.c, and then call into "run_child()" almost as soon as
we do the fork.

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 11/100

This commit is a straightforward internal code reorganization in Core Lightning's routing plugin (askrene). It moves the fork() logic from a dedicated child entry file into the main askrene.c file and renames the child entry point. There is no change to security-sensitive behavior, no bug fix, and no disclosed vulnerability.

Lower-priorityaskrene: actually run children in parallel.by Rusty Russell · fb4232df · Feb 19, 2026 · 2 filesMessage 68 · AdequateLow 27Details
Commit message · Rusty Russell

askrene: actually run children in parallel.

Changelog-Changed: Plugins: `askrene` now runs routing in parallel.

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 · Low 27/100

This commit changes the `askrene` routing plugin so that instead of waiting for each route-finding child process to finish before starting the next one, it now runs those child processes in parallel using non-blocking I/O. The change removes a synchronous "FIXME: Go async!" bottleneck and adds a new "FIXME: limit parallelism!" note. It is a performance/behavior change rather than a clear security fix, but running children in parallel can affect resource consumption, timing, and error-handling behavior.

Lower-priorityaskrene: have child make `struct route_query` internally.by Rusty Russell · 68b30b1e · Feb 19, 2026 · 3 filesMessage 65 · AdequateInformational 11Details
Commit message · Rusty Russell

askrene: have child make `struct route_query` internally.

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 11/100

This is a routine internal code cleanup in Core Lightning's routing plugin (askrene). It moves the creation of a 'route_query' data structure from the parent process into the child process, and changes the function that forks the router child to accept individual fields instead of a pre-built structure. There is no indication this fixes or introduces a security vulnerability.

Lower-priorityaskrene: move route_query definition and functions into child/.by Rusty Russell · b0028242 · Feb 19, 2026 · 10 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

askrene: move route_query definition and functions into child/.

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 commit is a straightforward code reorganization: it moves the route_query data structure and two helper functions from the main askrene.c/askrene.h files into a new child/route_query.c and child/route_query.h. The actual logic is copied verbatim, and the build system is updated to compile the new file. There is no functional change and no security relevance.

Lower-priorityaskrene: expose additional_costs htable so child can access it.by Rusty Russell · 85c9179f · Feb 19, 2026 · 3 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

askrene: expose additional_costs htable so child can access it.

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 commit is a straightforward code reorganization: it moves the definition of a hash table type called additional_cost_htable from a private source file into a new public header file so that a child process can use it. There is no change to program behavior, no bug fix, and no security-related change.

AI review queuedaskrene: move routines only accessed by the child process into child/.by Rusty Russell · 8775b628 · Feb 19, 2026 · 28 filesMessage 73 · AdequateInformational 15Details
Commit message · Rusty Russell

askrene: move routines only accessed by the child process into child/.

We want to make it clear when future generations edit the code, which
routines are called in the child (i.e. all the routing), and which in
the parent.

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
second-pass: unusually broad change
AI analysis · Informational 15/100

This commit is a pure code reorganization: it moves several routing-related source files into a new 'child/' subdirectory within the askrene plugin. There are no functional changes, no bug fixes, and no security patches visible in the diff. The code is simply relocated to make it clearer which routines run in the child process versus the parent process.

Lower-priorityaskrene: make children use child_log() instead of rq_log.by Rusty Russell · ac9aa975 · Feb 19, 2026 · 8 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

askrene: make children use child_log() instead of rq_log.

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 commit is a straightforward internal cleanup in the Core Lightning 'askrene' routing plugin. It removes a temporary 'hack' where child processes used the parent logging function, and instead makes them use their own dedicated child_log() function. There is no security-relevant change visible in the diff.

Lower-priorityaskrene: move fork() entry point into its own file.by Rusty Russell · 33e2f0a4 · Feb 19, 2026 · 5 filesMessage 73 · AdequateInformational 15Details
Commit message · Rusty Russell

askrene: move fork() entry point into its own file.

Now there's only one file clearly shared by both parent and child.

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 code reorganization: it moves the function that creates a child process (fork_router_child) and related helper code from the main askrene.c file into a new child/entry.c file. No security-sensitive logic was changed; the same fork(), pipe, and routing behavior is preserved. The change makes the build layout cleaner by having only one file shared between the parent and child process.

Lower-priorityaskrene: move fmt_flow_full from askrene.c into flow.c.by Rusty Russell · 395261fc · Feb 19, 2026 · 2 filesMessage 65 · AdequateInformational 15Details
Commit message · Rusty Russell

askrene: move fmt_flow_full from askrene.c into flow.c.

Weird that it was in askrene.c

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 commit simply moves a helper function that formats debug logging text from one source file to another within the same plugin. There is no change to what the code does, no bug fix, and no security relevance.

Lower-priorityaskrene: limit how many children we have.by Rusty Russell · 3c6504a9 · Feb 19, 2026 · 3 filesMessage 68 · AdequateLow 26Details
Commit message · Rusty Russell

askrene: limit how many children we have.

Queue them before we query local channels, so they don't use stale
information.

Changelog-Added: Config: `askrene-max-threads` to control how many CPUs we use for routing (default 4).
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 · Low 26/100

This change adds a limit to how many routing calculations the askrene plugin can run at the same time. Previously, there was no cap, and the code even had a note saying 'FIXME: limit parallelism!' The new default is 4 concurrent routing requests, with extra requests queued and processed later. The commit also explicitly queues requests before fetching local channel information, so waiting requests don't use outdated channel data when they finally run. This is a hardening improvement rather than a fix for a known active attack.

Lower-priorityaskrene: add child_log function so child can do logging.by Rusty Russell · da2f7776 · Feb 19, 2026 · 4 filesMessage 73 · AdequateInformational 12Details
Commit message · Rusty Russell

askrene: add child_log function so child can do logging.

We just shim rq_log for now, but we'll be weaning the child process off
that soon.

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 12/100

This commit adds a new logging mechanism so that a child process inside the askrene routing plugin can send log messages back to its parent process. It is a plumbing/infrastructure change: a new pipe is created between parent and child, and log messages are serialized over it. There is no indication this fixes a security bug or introduces a vulnerability; it is normal software development.

Lower-priorityaskrene: fork before calling the route solver.by Rusty Russell · 0ede29b8 · Feb 19, 2026 · 1 fileMessage 68 · AdequateInformational 23Details
Commit message · Rusty Russell

askrene: fork before calling the route solver.

This is fairly simple. We do all the prep work, fire off the child,
and it continues all the way to producing JSON output (or an error).
The parent then forwards it.

Limitations (fixed in successive patches):

1. Child logging currently gets lost.
2. We wait for the child, so this code is not a speedup.

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 23/100

This change rewrites part of a Lightning routing plugin so that the heavy route-finding work is done in a separate child process. The parent process prepares the request, forks a child, the child runs the algorithm and writes a JSON answer (or an error string) back through a pipe, and the parent forwards that answer. The commit notes that child logging is currently lost and that the parent still waits for the child, so it is not a performance improvement yet. There is no claim that this fixes a security bug; it appears to be an architectural isolation change.

Lower-prioritypytest: add tests for bcli `getblockfrompeer` retry pathby dovgopoly · edbad6cd · Feb 18, 2026 · 1 fileMessage 83 · StrongInformational 12Details
Commit message · dovgopoly

pytest: add tests for bcli `getblockfrompeer` retry path

Add `test_bcli_concurrent` to verify bcli handles concurrent requests while the `getblockfrompeer` retry path is active, simulating a pruned node scenario where `getblock` initially fails.

Add `test_bcli_retry_timeout` to verify lightningd crashes with a clear error message when we run out of `getblock` retries.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 12/100

This commit only adds new automated tests to the Core Lightning project. It does not change any production code, so it cannot introduce a security vulnerability by itself. The tests exercise an existing retry mechanism in the bitcoin backend plugin (bcli) when a pruned Bitcoin node temporarily cannot return a block. One test documents that Core Lightning will shut down (fatal error) if the retry path runs out of time. That behavior is already present in the code; the test merely records it.