Modular C implementation of the Lightning Network protocol and node stack.
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.
Aug 5 → Feb 61049 seen37 candidatesCompleteFeb 6 → Jun 6579 seen10 candidatesCompleteJun 6 → Jul 678 seen1 candidatesCompleteJul 6 → Aug 5147 seen16 candidatesCompleteMessage quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
Public Git author strings; identities are not independently verified.
Last scanned 5 minutes ago
This commit simply adds a new person's PGP public-key fingerprint to the list of trusted release signers in two documentation files. It does not change any code, fix any bug, or alter any security behavior of the software itself.
41278b4eby jaonoctus+2−02 filesThis is a tiny internal fix to make a bookkeeping migration produce stable event ordering. It changes the timestamp used when creating historical 'deposit' records during a one-time database migration, so the records sort consistently with…
498e5086by daywalker90+2−01 fileThis commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…
d1b6963bby daywalker90+204−1224 filesThis commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …
c09c4520by Erick Cestari+1−01 fileThis commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…
5685c9a3by cdecker+12−211 fileThis commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In prac…
ddbd2963by daywalker90+1786−173950 filesThis commit only updates documentation. It adds error code 313 to the documented error lists for several Core Lightning commands (fundpsbt, utxopsbt, txprepare, multiwithdraw, and upgradewallet). The error code already existed in the code …
a34b9758by Peter Neuroth+30−86 filesThis commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-sig…
8e495707by Peter Neuroth+5−21 fileThis commit updates Core Lightning's release documentation to tell users and release managers to run gpg --verify with both the signature file and the manifest file named explicitly. The old one-argument form can silently succeed even if t…
2dee8699by Peter Neuroth+9−62 filesThis commit is a routine update to the Rust dependency lock file (Cargo.lock), bumping many third-party libraries to newer patch or minor versions. The commit message gives no security reason for the update, and no verified references link…
c1551c55by daywalker90+298−2761 fileThis commit fixes a stack-overflow risk in Core Lightning's JSON parser. Before the fix, an attacker could send a valid JSON-RPC message containing thousands of nested brackets or braces. The parser's own helper functions used recursion fo…
83f92e4bby Níckolas Goline+90−22 filesThis commit only fixes typos and comment style. It changes two C-style comments from // to /* */ and corrects a grammar error in a documentation comment ('element' to 'elements'). There are no code behavior changes, no bug fixes, and no se…
273d7f02by w3lld1+3−32 filesThis change fixes a test-infrastructure bug in Core Lightning's Python testing helpers. When running tests against a PostgreSQL database, very long test names could be silently shortened by PostgreSQL, causing different test runs or nodes …
c4fe4cbaby Peter Neuroth+59−12 filesThis fix prevents Core Lightning from trying to use freshly created bitcoins (immature coinbase rewards) as emergency funds for fee-bump transactions. Such a transaction would be invalid under Bitcoin's rules and would be rejected by the n…
34883ff7by cdecker+5−12 filesThis commit fixes a bug in Core Lightning's askrene plugin that could prevent a node from restarting. When a saved routing layer contained a node bias with a description, the plugin accidentally freed the description's memory while using i…
4681177dby Vincenzo Palazzo+2−32 filesThis commit only fixes a test case so it actually exercises the intended code path. It does not change any production code, so it cannot introduce or fix a real-world security vulnerability by itself. The test change is a reproducer for a …
0f3f67a0by Vincenzo Palazzo+3−21 fileThis commit fixes a bug in Core Lightning's experimental dual-funded channel feature. When another node tried to open a channel, Core Lightning was not checking whether the proposed transaction fees were reasonable. A peer could request a …
ba08356fby cdecker+140−04 filesThis commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a…
65bdbc47by cdecker+137−02 filesThis update fixes a crash bug in Core Lightning. When the software tried to list details of a channel opening in progress, it could crash if a stored fee rate was extremely large or zero. The crash happened because the code used an interna…
d67c4936by cdecker+72−227 filesThis commit fixes a bug where Core Lightning nodes could get stuck in a crash loop. If a node had previously stored an extremely high or zero fee rate for an in-progress channel funding operation (a 'splice' or dual-funded channel RBF), a …
f057c692by cdecker+34−01 fileExpand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
cff488d4 · Feb 23, 2026 · 2 filesLow 42offers: honor `payment-fronting-nodes` when creating invoice_requests.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change fixes a configuration being ignored when creating invoice requests. Core Lightning has a 'payment-fronting-nodes' setting that tells a node to route incoming invoice requests through specific neighbor nodes for privacy. Before this patch, the setting was honored for regular offers but ignored when creating invoice requests, meaning the node could expose its real identity even when it explicitly asked to hide behind a fronting node. The patch makes invoice-request creation respect the setting and fails if no suitable fronting node can be found.
572d4db8 · Feb 23, 2026 · 7 filesInformational 15offers: encapsulate globals in plugin_get_data()
This is how modern plugins do it, and it has the benefit of not
requiring extra code for memleak tracking.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a straightforward internal code cleanup in the Core Lightning 'offers' plugin. It moves several global variables into a single per-plugin data structure and provides a helper function to access them. There is no change to user-facing behavior, no bug fix, and no security-related change described in the commit or diff.
9eee744d · Feb 23, 2026 · 5 filesLow 36lightningd: honor `payment-fronting-node` when making bolt12 offers.
We use all the fronting nodes when creating offers.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a feature gap in Core Lightning's BOLT12 offer creation. Previously, the `payment-fronting-node` setting—which lets a node hide behind one or more public 'front' nodes for privacy—was ignored when creating BOLT12 offers. The patch makes the offer plugin read the configured fronting nodes and include them all as blinded paths in generated offers, matching the behavior already intended for invoices. It is a correctness/privacy fix rather than a remote-exploitable vulnerability.
15ef2fd3 · Feb 23, 2026 · 4 filesInformational 15Build: don't use HAVE_FUNCTION_SECTIONS for update-mocks.
I ran `uv run make update-mocks` and many mocks vanished. But that
broke MacOS (and maybe other archs) which doesn't support function
sections and no longer linked.
If this proves problematic, we might end up generating mocks properly:
1. Use #include "mocks-sphinx-xor_cipher_stream_gen.c"
2. Generate those separate files as necessary.
3. Don't commit them, build them locally.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a build-system fix for a developer-only mock-generation script. It stops using a compiler feature (function sections) that is unsupported on macOS, which had caused test builds to fail after mocks were regenerated. There is no runtime security issue or user impact.
7b69f5f6 · Feb 23, 2026 · 1 fileInformational 15pytest: really fix race in test_buy_liquidity_ad_check_bookkeeping
I thought I fixed this in b15f386df66b31b55e50bb55195bbf835ad1c4c8,
but it happened again, because my fix was insufficent! "all([])" is
true, and we want to make sure the channel really has been seen.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a fix to a flaky automated test, not a security fix. The test was checking whether all channels are active before continuing, but the check accidentally returned 'true' when there were no channels at all (because 'all([])' is true in Python). The patch now explicitly waits for exactly two channels and both to be active. It does not change production code or address any vulnerability.
113d2e80 · Feb 23, 2026 · 1 fileInformational 15pytest: fix test_sendpay_grouping regex.
It doesn't match "after 10 attempts":
```
with pytest.raises(RpcError, match=r'Ran out of routes to try after [1-9]+ attempts'):
> l1.rpc.pay(inv, amount_msat='100001msat')
tests/test_pay.py:5250:
...
elif "error" in resp:
> raise RpcError(method, payload, resp['error'])
E pyln.client.lightning.RpcError: RPC call failed: method: pay, payload: {'bolt11': 'lnbcrt1p5evy5ksp5ndq75geqkggp9jvkal5e36mwpyppf0vm8ftzv7qqv9plkw2u5hkspp53rw3mkve9896muty6wzpjxc6ucau0cvekmakg6ta5h5v0ar07m6qdq8v3jhxccxqyjw5qcqp9rzjqvuytqpdyk6wqaxvl47d3vee5swuwklej79qxjqqg394r4ptqaue5qqqvuqqqqgqqqqqqqqpqqqqqzsqqc9qxpqysgq53phr29544luhuduaqjajvj8d54yep69sy6cqtesk2t3q83htsas8nhluh9jjqm4se274pzzg8ma943xe8a5sg7d286n2vttraqd7dsq8s7k84', 'amount_msat': '100001msat'}, error: {'code': 210, 'message': 'Ran out of routes to try after 10 attempts: see `paystatus`', 'attempts': [{'status': 'failed', 'failreason': 'failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)', 'partid': 0, 'amount_msat': 100001}, {'status': 'pending', 'failreason': 'No path found', 'partid': 1, 'amount_msat': 100001, 'parent_partid': 0}, {'status': 'failed', 'failreason': 'failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)', 'partid': 2, 'amount_msat': 51394, 'parent_partid': 1}, {'status': 'failed', 'failreason': 'failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)', 'partid': 4, 'amount_msat': 51394, 'parent_partid': 2}, {'status': 'failed', 'failreason': 'No path found', 'partid': 6, 'amount_msat': 51394, 'parent_partid': 4}, {'status': 'failed', 'failreason': 'No path found', 'partid': 7, 'amount_msat': 51394, 'parent_partid': 6}, {'status': 'failed', 'failreason': 'failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)', 'partid': 3, 'amount_msat': 48607, 'parent_partid': 1}, {'status': 'failed', 'failreason': 'failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)', 'partid': 5, 'amount_msat': 48607, 'parent_partid': 3}, {'status': 'failed', 'failreason': 'failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote)', 'partid': 8, 'amount_msat': 48607, 'parent_partid': 5}, {'status': 'failed', 'failreason': 'No path found', 'partid': 9, 'amount_msat': 48607, 'parent_partid': 8}]}
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a test-only regular expression so it correctly matches error messages that say 'after 10 attempts'. It is a test-suite maintenance change with no effect on the actual Core Lightning payment software or its users.
0240882d · Feb 23, 2026 · 1 fileInformational 15pytest: fix flake in test_gossip_store_compact_while_extending and test_gossmap_lost_node
node_factory.line_graph waits until all nodes have seen all channels,
not all node announcements, so we can get this:
```
> assert post_nodes == pre_nodes
...
E Full diff:
E [
E {
E + 'addresses': [],
E + 'alias': 'JUNIORYARD-b2d9563',
E + 'color': '02287b',
E + 'features': '808898880a8a59a1',
E + 'last_timestamp': 1771565748,
E 'nodeid': '02287bfac8b99b35477ebe9334eede1e32b189e24644eb701c079614712331cec0',
E },
E {
E 'addresses': [],
E 'alias': 'SILENTGOPHER-b2d9563',
E 'color': '033845',
E 'features': '808898880a8a59a1',
...
tests/test_gossip.py:1710: AssertionError
```
Since the same pattern occurs in test_gossmap_lost_node, fix that too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes two flaky automated tests in the Core Lightning project's test suite. The tests were occasionally failing because they assumed all network node announcements had been received, but the helper function they used only waited for channel announcements. The fix adds an explicit wait for node announcements before capturing the list of nodes. There is no change to production code and no security relevance.
1e608584 · Feb 23, 2026 · 1 fileInformational 15pytest: fix flake in test_reconnect_remote_sends_no_sigs
Actual order could be either way:
```
FAILED tests/test_connection.py::test_reconnect_remote_sends_no_sigs - AssertionError: assert ['peer_in', 'peer_out'] == ['peer_out', 'peer_in']
At index 0 diff: 'peer_in' != 'peer_out'
Full diff:
[
+ 'peer_in',
'peer_out',
- 'peer_in',
]
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a flaky test by sorting log messages before comparing them. The test was failing because two network messages could arrive in either order. There is no change to production code and no security issue.
f318c13b · Feb 23, 2026 · 10 filesLow 47db: add STRICT tables with migration for old databases
Enables STRICT tables in developer mode, but old databases (~2019) may
have BLOB values in TEXT columns. Migration converts BLOB faildetail
to TEXT with UTF-8 validation, NULLs invalid data.
STRICT is only applied to fresh databases; existing databases being
upgraded skip STRICT to avoid type affinity issues with legacy data.
Also adds security pragmas in developer mode: trusted_schema=OFF,
cell_size_check=ON.
Fixes #5390.
Changelog-Added: Database: STRICT tables and security pragmas in developer mode
Changelog-Fixed: Database migration for old BLOB-typed faildetail values
This commit hardens Core Lightning's SQLite database handling in developer mode by adding STRICT table enforcement and two security-related SQLite pragmas. It also adds a migration that cleans up old database entries where a text column accidentally stored binary data, converting them to text or wiping them if they aren't valid text. The changes are defensive: they reduce the chance of unexpected data types causing bugs or security issues, but they do not by themselves fix a known exploitable vulnerability.
580c2f78 · Feb 23, 2026 · 8 filesLow 47renepay: refactor and bugfixes
We remove the auxiliary RPC renesenday (only used internally) in favor
of a function that builds the onion, stores the shared secrets
needed to recover the onion reply, and calls sendonion/injectpaymentonion.
This solves a concurrency race
```
**BROKEN** plugin-cln-renepay: Unable to parse sendpay_failure
```
in which we are waiting for renesenday to return in order to record the shared
secrets but we get the a sendpay_failure notification with an onionreply
before we have secrets to decode it.
It also solves a missing JSON id seen in the logs
```
DEBUG plugin-cln-renepay: JSON reply with unknown id
```
because renesendpay was using his command variable to issue an RPC
to sendonion/injecpaymentonion and would fail or succeed the command
before those RPCs were done. This also meant that the callback
functions were silently being ignored.
Changelog-Fixed: renepay: fixes a race condition that leads to **BROKEN** plugin-cln-renepay: Unable to parse sendpay_failure
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a timing bug in Core Lightning's experimental 'renepay' payment plugin. Previously, the plugin used an internal helper command (renesendpay) to send payment routes. Because of the way commands were chained, the plugin could receive a failure notification with an encrypted onion reply before it had saved the secrets needed to decode that reply. That caused error messages and could prevent the plugin from correctly learning why a payment failed. The fix builds the onion and stores the shared secrets directly before calling sendonion/injectpaymentonion, removing the race condition.
f2fcd6b0 · Feb 23, 2026 · 1 fileInformational 17fuzz: fix uninitialized variable in fuzz-handle_onion_message
Changelog-Fixed: fuzz: fix build with newer clang.
Fixes: #8683
This commit fixes a fuzz-test build issue in Core Lightning. A fuzz test is an automated testing tool, not the live Lightning node software. The change moves a variable declaration and initializes it to NULL so newer versions of the Clang compiler no longer complain about a potentially uninitialized variable when the test's error-recovery path is taken. It does not appear to fix a vulnerability in production code.
aa3f2469 · Feb 20, 2026 · 1 fileInformational 13Add `-O2` in armv7 Docker build following bug fix
Changelog-None
This commit changes the compiler optimization level for the ARMv7 Docker build from -O1 to -O2. It removes a TODO comment that referenced a prior bug (GitHub issue #8501) which had been worked around by using lower optimization. The change itself is a build-configuration cleanup after a bug was fixed elsewhere; it does not contain any direct security flaw, but it re-enables a higher optimization level that had previously been disabled due to a bug.
823a575d · Feb 20, 2026 · 1 fileInformational 13pytest: fix flake involving partial lines.
Not sure how this happens, but it does, and may explain other races:
```
line = l1.daemon.wait_for_log(f"plugin-all_notifications.py: notification pay_failure: ")
dict_str = line.split("notification pay_failure: ", 1)[1]
> data = ast.literal_eval(dict_str)
tests/test_plugin.py:4869:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/opt/hostedtoolcache/Python/3.10.19/x64/lib/python3.10/ast.py:64: in literal_eval
node_or_string = parse(node_or_string.lstrip(" \t"), mode='eval')
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
source = "{'origin': 'pay', 'payload': {'payment_hash': 'a9caff840abedac582c3e22b46f78d205d8"
filename = '<unknown>', mode = 'eval'
def parse(source, filename='<unknown>', mode='exec', *,
type_comments=False, feature_version=None):
"""
Parse the source into an AST node.
Equivalent to compile(source, filename, mode, PyCF_ONLY_AST).
Pass type_comments=True to get back type comments where the syntax allows.
"""
flags = PyCF_ONLY_AST
if type_comments:
flags |= PyCF_TYPE_COMMENTS
if isinstance(feature_version, tuple):
major, minor = feature_version # Should be a 2-tuple.
assert major == 3
feature_version = minor
elif feature_version is None:
feature_version = -1
# Else it should be an int giving the minor version for 3.x.
> return compile(source, filename, mode, flags,
_feature_version=feature_version)
E File "<unknown>", line 1
E {'origin': 'pay', 'payload': {'payment_hash': 'a9caff840abedac582c3e22b46f78d205d8
E ^
E SyntaxError: unterminated string literal (detected at line 1)
/opt/hostedtoolcache/Python/3.10.19/x64/lib/python3.10/ast.py:50: SyntaxError
...
lightningd-1 2026-02-19T03:32:31.425Z INFO plugin-all_notifications.py: notification pay_failure: {'origin': 'pay', 'payload': {'payment_hash': 'a9caff840abedac582c3e22b46f78d205d87ff1212de05a64b12a6a53459bf29', 'bolt11': 'lnbcrt100n1p5edpz0sp5l5nj5p28kzm47d0tug2c2hz9q9gknd5sve6nwkf59fnpfvzecvcqpp54890lpq2hmdvtqkrug45daudypwc0lcjzt0qtfjtz2n22dzehu5sdq8v3jhxccxqyjw5qcqp9rzjqvuytqpdyk6wqaxvl47d3vee5swuwklej79qxjqqg394r4ptqaue5qqqvuqqqqgqqqqqqqqpqqqqqzsqqc9qxpqysgqvqzc5wd097xa6shdfkvr3yarvj36gu00ylfwdlfql9wkq3kueqgkk3pa3zdzd8a0de5vny0whzwjzrvhcuf86q6m9yakwjwjs3hzl9gpcf5lzn', 'error': {'message': 'failed: WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS (reply from remote)'}}, 'pay_failure': {'payment_hash': 'a9caff840abedac582c3e22b46f78d205d87ff1212de05a64b12a6a53459bf29', 'bolt11': 'lnbcrt100n1p5edpz0sp5l5nj5p28kzm47d0tug2c2hz9q9gknd5sve6nwkf59fnpfvzecvcqpp54890lpq2hmdvtqkrug45daudypwc0lcjzt0qtfjtz2n22dzehu5sdq8v3jhxccxqyjw5qcqp9rzjqvuytqpdyk6wqaxvl47d3vee5swuwklej79qxjqqg394r4ptqaue5qqqvuqqqqgqqqqqqqqpqqqqqzsqqc9qxpqysgqvqzc5wd097xa6shdfkvr3yarvj36gu00ylfwdlfql9wkq3kueqgkk3pa3zdzd8a0de5vny0whzwjzrvhcuf86q6m9yakwjwjs3hzl9gpcf5lzn', 'error': {'message': 'failed: WIRE_INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS (reply from remote)'}}}
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a fix for a flaky test helper, not a security issue. The change makes the test framework wait for a complete line of log output before reading it, preventing test failures caused by reading a partial line mid-write. It does not change Core Lightning's production code or affect real users' funds or node security.
21c2c0f9 · Feb 20, 2026 · 1 fileInformational 15pytest: 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>
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.
d0c158a6 · Feb 20, 2026 · 8 filesInformational 18pytest: 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>
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.
ffb8d860 · Feb 20, 2026 · 1 fileInformational 14pytest: 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>
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.
a9a72adc · Feb 20, 2026 · 3 filesInformational 15pytest: make global exclusion for "That's weird: Request X took Y msec" under valgrind.
Rather than playing whack-a-mole:
```
ERROR tests/test_misc.py::test_emergencyrecover - ValueError:
Node errors:
- lightningd-1: had BROKEN or That's weird messages
...
lightningd-1 2026-02-18T02:29:54.826Z UNUSUAL jsonrpc#76: That's weird: Request signpsbt took 7466 milliseconds
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a test-only change that stops CI test failures caused by slow valgrind runs. It does not change the actual Core Lightning node software that users run, so it has no direct security impact on real systems.
000462c2 · Feb 20, 2026 · 1 fileInformational 15pytest: 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>
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.
10eb2c2c · Feb 20, 2026 · 1 fileInformational 15pytest: 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>
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.
a84ad108 · Feb 19, 2026 · 1 fileInformational 15common: 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>
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.
3c6504a9 · Feb 19, 2026 · 3 filesLow 26askrene: 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>
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.
da2f7776 · Feb 19, 2026 · 4 filesInformational 12askrene: 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>
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.
d9774e73 · Feb 19, 2026 · 11 filesInformational 15bitcoin: 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>
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.
0ede29b8 · Feb 19, 2026 · 1 fileInformational 23askrene: 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>
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.
e397b122 · Feb 19, 2026 · 2 filesInformational 15askrene: make minflow() static, and remove unused linear_flow_cost.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.