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 20 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.
b7c2629d · Oct 20, 2025 · 1 fileLow 25libplugin: remove redundant destructor which causes exponential slowdown on large numbers of requests.
Note that we create a destructor on the command to reset request->cmd
pointer if the cmd is freed (so we know not to call the callback).
But attaching hundreds of thousands of them is slow: it's a
single-linked list, which is iterated in several places.
But that's redundant: the request is now allocated off the cmd, so freeing the command
will free the request anyway.
Hacking in something to print progress to a file, here's the number of
requests processed every 10 seconds before and after:
Before:
$ while sleep 10; do wc -l /tmp/bkpr-progress; done
181529 /tmp/bkpr-progress
195994 /tmp/bkpr-progress
207083 /tmp/bkpr-progress
226336 /tmp/bkpr-progress
234319 /tmp/bkpr-progress
241514 /tmp/bkpr-progress
247421 /tmp/bkpr-progress
255292 /tmp/bkpr-progress
261367 /tmp/bkpr-progress
269085 /tmp/bkpr-progress
276953 /tmp/bkpr-progress
282233 /tmp/bkpr-progress
286193 /tmp/bkpr-progress
290930 /tmp/bkpr-progress
295276 /tmp/bkpr-progress
301086 /tmp/bkpr-progress
After:
169505 /tmp/bkpr-progress
196010 /tmp/bkpr-progress
219370 /tmp/bkpr-progress
235671 /tmp/bkpr-progress
244242 /tmp/bkpr-progress
255362 /tmp/bkpr-progress
265636 /tmp/bkpr-progress
276966 /tmp/bkpr-progress
284451 /tmp/bkpr-progress
288836 /tmp/bkpr-progress
296578 /tmp/bkpr-progress
304571 /tmp/bkpr-progress
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a performance bug, not a security vulnerability. It removes an unnecessary cleanup step that was attached to every outgoing plugin request. On large numbers of requests, that extra step created a very long internal list and slowed everything down dramatically. The fix simply relies on normal memory cleanup instead.
0c9a35e2 · Oct 20, 2025 · 2 filesInformational 15plugins/sql: add payment_hash index to channelmoves table.
This significantly speeds up the query which bookkeeper often does:
"SELECT created_index"
" FROM channelmoves"
" WHERE payment_hash = X'%s'"
" AND credit_msat = %"PRIu64
" AND created_index <= %"PRIu64,
On large databases this scan is expensive, and a payment_hash index
cuts it down a great deal. It does take longer to load the channelmoves
in the first place though (about 3x).
Before:
$ while sleep 10; do wc -l /tmp/bkpr-progress; done
169505 /tmp/bkpr-progress
196010 /tmp/bkpr-progress
219370 /tmp/bkpr-progress
235671 /tmp/bkpr-progress
244242 /tmp/bkpr-progress
255362 /tmp/bkpr-progress
265636 /tmp/bkpr-progress
276966 /tmp/bkpr-progress
284451 /tmp/bkpr-progress
288836 /tmp/bkpr-progress
296578 /tmp/bkpr-progress
304571 /tmp/bkpr-progress
After:
$ while sleep 10; do wc -l /tmp/bkpr-progress; done
161421 /tmp/bkpr-progress
238273 /tmp/bkpr-progress
281185 /tmp/bkpr-progress
305787 /tmp/bkpr-progress
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: plugins: the sql plugin now keeps an index on `channelmoves` by `payment_hash`.
This commit is a routine performance improvement for the Core Lightning SQL plugin. It adds a database index on the payment_hash column of the channelmoves table so that bookkeeping queries run faster on large databases. There is no security fix or vulnerability here.
23784a4e · Oct 17, 2025 · 1 fileInformational 20configure: set SED to gsed (MacOS et al) or sed (GNU).
We use some GNU sed features and it's easier to require gsed than fix
them all (and keep noticing when they break). MacOS comes with gsed
already!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit changes the project's build configuration script so it picks the correct version of the 'sed' text-editing tool. On macOS it will prefer 'gsed' (the GNU version), and on Linux it will use the standard 'sed'. This is a build-system portability fix, not a security patch. It does not fix a vulnerability or change any runtime code that handles money, network messages, or cryptography.
7b1c4874 · Oct 17, 2025 · 7 filesInformational 15makefile: use SED from configure in most places.
Some simple cases are left alone, but anything called from make uses $SED.
This commit is a build-system portability fix. It replaces hardcoded uses of the `sed` command with a configurable `SED` variable (usually set by the configure script). This helps the project build correctly on systems like macOS where the standard `sed` behaves differently and a GNU-compatible `gsed` is needed. There is no security-relevant change here.
992771bb · Oct 13, 2025 · 1 fileInformational 13pytest: fix flakes in feerates.
Sometimes we get a shorter signature than expected, and we're supposed
to disable the feerate tests in that case. But we didn't catch all the
cases where we make signatures.
```
2025-10-13T02:36:24.1901527Z ____________________________ test_peer_anchor_push _____________________________
2025-10-13T02:36:24.1902251Z [gw5] linux -- Python 3.10.18 /home/runner/work/lightning/lightning/.venv/bin/python
2025-10-13T02:36:24.1902731Z
2025-10-13T02:36:24.1903045Z node_factory = <pyln.testing.utils.NodeFactory object at 0x7f17fdffd6f0>
2025-10-13T02:36:24.1903740Z bitcoind = <pyln.testing.utils.BitcoinD object at 0x7f17fdffe830>
2025-10-13T02:36:24.1904495Z executor = <concurrent.futures.thread.ThreadPoolExecutor object at 0x7f17fdffcbb0>
2025-10-13T02:36:24.1906158Z chainparams = {'bip173_prefix': 'bcrt', 'chain_hash': '06226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f', 'elements': False, 'example_addr': 'bcrt1qeyyk6sl5pr49ycpqyckvmttus5ttj25pd0zpvg', ...}
2025-10-13T02:36:24.1907285Z
2025-10-13T02:36:24.1907600Z @unittest.skipIf(TEST_NETWORK != 'regtest', 'elementsd anchors not supportd')
2025-10-13T02:36:24.1908344Z def test_peer_anchor_push(node_factory, bitcoind, executor, chainparams):
2025-10-13T02:36:24.1909033Z """Test that we use anchor on peer's commit to CPFP tx"""
2025-10-13T02:36:24.1909853Z l1, l2, l3 = node_factory.line_graph(3, opts=[{},
2025-10-13T02:36:24.1910334Z {'min-emergency-msat': 546000,
2025-10-13T02:36:24.1910825Z 'dev-warn-on-overgrind': None,
2025-10-13T02:36:24.1911313Z 'broken_log': 'overgrind: short signature length'},
2025-10-13T02:36:24.1911662Z {'disconnect': ['-WIRE_UPDATE_FULFILL_HTLC'],
2025-10-13T02:36:24.1911976Z 'dev-warn-on-overgrind': None,
2025-10-13T02:36:24.1912304Z 'broken_log': 'overgrind: short signature length'}],
2025-10-13T02:36:24.1912790Z wait_for_announce=True)
2025-10-13T02:36:24.1913041Z
2025-10-13T02:36:24.1913305Z # We splinter l2's funds so it's forced to use more than one UTXO to push.
2025-10-13T02:36:24.1914043Z fundsats = int(Millisatoshi(only_one(l2.rpc.listfunds()['outputs'])['amount_msat']).to_satoshi())
2025-10-13T02:36:24.1914443Z OUTPUT_SAT = 10000
2025-10-13T02:36:24.1914647Z NUM_OUTPUTS = 10
2025-10-13T02:36:24.1914903Z psbt = l2.rpc.fundpsbt("all", "1000perkw", 1000)['psbt']
2025-10-13T02:36:24.1915520Z # Pay 5k sats in fees.
2025-10-13T02:36:24.1916329Z psbt = l2.rpc.addpsbtoutput(fundsats - OUTPUT_SAT * NUM_OUTPUTS - 5000, psbt, destination=l3.rpc.newaddr()['bech32'])['psbt']
2025-10-13T02:36:24.1917156Z for _ in range(NUM_OUTPUTS):
2025-10-13T02:36:24.1917638Z psbt = l2.rpc.addpsbtoutput(OUTPUT_SAT, psbt)['psbt']
2025-10-13T02:36:24.1918194Z l2.rpc.sendpsbt(l2.rpc.signpsbt(psbt)['signed_psbt'])
2025-10-13T02:36:24.1918731Z bitcoind.generate_block(1, wait_for_mempool=1)
2025-10-13T02:36:24.1919232Z sync_blockheight(bitcoind, [l1, l2])
2025-10-13T02:36:24.1919634Z
2025-10-13T02:36:24.1919847Z # Make sure all amounts are below OUTPUT_SAT sats!
2025-10-13T02:36:24.1920318Z assert [x for x in l2.rpc.listfunds()['outputs'] if x['amount_msat'] > Millisatoshi(str(OUTPUT_SAT) + "sat")] == []
2025-10-13T02:36:24.1920735Z
2025-10-13T02:36:24.1920957Z # Get HTLC stuck, so l2 has reason to push commitment tx.
2025-10-13T02:36:24.1921244Z amt = 100_000_000
2025-10-13T02:36:24.1921517Z sticky_inv = l3.rpc.invoice(amt, 'sticky', 'sticky')
2025-10-13T02:36:24.1921842Z route = l1.rpc.getroute(l3.info['id'], amt, 1)['route']
2025-10-13T02:36:24.1922277Z l1.rpc.sendpay(route, sticky_inv['payment_hash'], payment_secret=sticky_inv['payment_secret'])
2025-10-13T02:36:24.1922751Z l3.daemon.wait_for_log('dev_disconnect: -WIRE_UPDATE_FULFILL_HTLC')
2025-10-13T02:36:24.1923060Z
2025-10-13T02:36:24.1923241Z # Make sure HTLC expiry is what we expect!
2025-10-13T02:36:24.1923637Z l2.daemon.wait_for_log('Adding HTLC 0 amount=100000000msat cltv=119 gave CHANNEL_ERR_ADD_OK')
2025-10-13T02:36:24.1923998Z
2025-10-13T02:36:24.1924229Z # l3 drops to chain, but make sure it doesn't CPFP its own anchor.
2025-10-13T02:36:24.1924685Z wait_for(lambda: only_one(l3.rpc.listpeerchannels(l2.info['id'])['channels'])['htlcs'] != [])
2025-10-13T02:36:24.1925688Z closetx = l3.rpc.dev_sign_last_tx(l2.info['id'])['tx']
2025-10-13T02:36:24.1926132Z l3.stop()
2025-10-13T02:36:24.1926337Z # We don't care about l1 any more, either
2025-10-13T02:36:24.1926579Z l1.stop()
2025-10-13T02:36:24.1926739Z
2025-10-13T02:36:24.1926941Z # We put l3's tx in the mempool, but won't mine it.
2025-10-13T02:36:24.1927316Z bitcoind.rpc.sendrawtransaction(closetx)
2025-10-13T02:36:24.1927754Z
2025-10-13T02:36:24.1928139Z # We aim for feerate ~3750, so this won't mine l3's unilateral close.
2025-10-13T02:36:24.1928991Z # HTLC's going to time out at block 120 (we give one block grace)
2025-10-13T02:36:24.1929527Z for block in range(110, 120):
2025-10-13T02:36:24.1929989Z bitcoind.generate_block(1, needfeerate=5000)
2025-10-13T02:36:24.1930510Z assert bitcoind.rpc.getblockcount() == block
2025-10-13T02:36:24.1931014Z sync_blockheight(bitcoind, [l2])
2025-10-13T02:36:24.1931715Z assert only_one(l2.rpc.listpeerchannels(l3.info['id'])['channels'])['state'] == 'CHANNELD_NORMAL'
2025-10-13T02:36:24.1932368Z
2025-10-13T02:36:24.1932642Z # Drops to chain
2025-10-13T02:36:24.1933030Z bitcoind.generate_block(1, needfeerate=5000)
2025-10-13T02:36:24.1933824Z wait_for(lambda: only_one(l2.rpc.listpeerchannels(l3.info['id'])['channels'])['state'] == 'AWAITING_UNILATERAL')
2025-10-13T02:36:24.1934522Z
2025-10-13T02:36:24.1935254Z # But, l3's tx already there, and identical feerate will not RBF.
2025-10-13T02:36:24.1935839Z l2.daemon.wait_for_log("rejecting replacement")
2025-10-13T02:36:24.1936357Z wait_for(lambda: len(bitcoind.rpc.getrawmempool()) == 2)
2025-10-13T02:36:24.1936801Z
2025-10-13T02:36:24.1937127Z # As blocks pass, we will use anchor to boost l3's tx.
2025-10-13T02:36:24.1937666Z for block, feerate in zip(range(120, 124), (12000, 13000, 14000, 15000)):
2025-10-13T02:36:24.1938560Z l2.daemon.wait_for_log(fr"Worth fee [0-9]*sat for remote commit tx to get 100000000msat at block 125 \(\+{125 - block}\) at feerate {feerate}perkw")
2025-10-13T02:36:24.1939369Z l2.daemon.wait_for_log("sendrawtx exit 0")
2025-10-13T02:36:24.1939902Z # Check feerate for entire package (commitment tx + anchor) is ~ correct
2025-10-13T02:36:24.1940473Z details = bitcoind.rpc.getrawmempool(True).values()
2025-10-13T02:36:24.1940920Z print(f"mempool = {details}")
2025-10-13T02:36:24.1941347Z total_weight = sum([d['weight'] for d in details])
2025-10-13T02:36:24.1941903Z total_fees = sum([float(d['fees']['base']) * 100_000_000 for d in details])
2025-10-13T02:36:24.1942467Z total_feerate_perkw = total_fees / total_weight * 1000
2025-10-13T02:36:24.1942972Z > check_feerate([l3, l2], total_feerate_perkw, feerate)
2025-10-13T02:36:24.1943279Z
2025-10-13T02:36:24.1943411Z tests/test_closing.py:4064:
2025-10-13T02:36:24.1943813Z _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
2025-10-13T02:36:24.1944170Z
2025-10-13T02:36:24.1944685Z nodes = [<fixtures.LightningNode object at 0x7f17fdf684f0>, <fixtures.LightningNode object at 0x7f17fdf6af50>]
2025-10-13T02:36:24.1945708Z actual_feerate = 13005.66942869603, expected_feerate = 13000
2025-10-13T02:36:24.1946091Z
2025-10-13T02:36:24.1946247Z def check_feerate(nodes, actual_feerate, expected_feerate):
2025-10-13T02:36:24.1946558Z # Feerate can't be lower.
2025-10-13T02:36:24.1946870Z assert actual_feerate > expected_feerate - 2
2025-10-13T02:36:24.1947365Z if actual_feerate >= expected_feerate + 2:
2025-10-13T02:36:24.1947830Z if any([did_short_sig(n) for n in nodes]):
2025-10-13T02:36:24.1948239Z return
2025-10-13T02:36:24.1948589Z # Use assert as it shows the actual values on failure
2025-10-13T02:36:24.1949043Z > assert actual_feerate < expected_feerate + 2
2025-10-13T02:36:24.1949489Z E AssertionError
2025-10-13T02:36:24.1949704Z
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change only adds extra test-only logging to catch abnormally short cryptographic signatures during automated testing. It does not alter how signatures are created, verified, or used in real transactions, so it is not a security fix and does not affect normal users.
fc6bee89 · Oct 13, 2025 · 1 fileLow 35connectd: close connection properly after dev-disconnect `+`.
We need to drain subds too, otherwise if timing is correct we never close.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This patch fixes a bug in Core Lightning's connection handling where a developer testing feature (dev-disconnect '+') could leave a peer connection stuck open instead of closing it cleanly. The fix ensures all sub-connections are drained and freed before shutting down the peer connection. It is a hardening fix for a development/testing path, not a clear remote exploit on its own.
af340a68 · Oct 13, 2025 · 24 filesLow 27ccan: update to latest.
We fix the configure test which was bogus, and breaks on 32-bit gcc with optimization:
```
checking for unaligned access to int... ccan/tools/configurator/configurator: Test for HAVE_UNALIGNED_ACCESS did not compile:
configuratortest.c: In function 'main':
configuratortest.c:8:22: error: array subscript 'int[0]' is partly outside array bounds of 'char[4]' [-Werror=array-bounds]
8 | return *x == *y;
| ^~
configuratortest.c:5:11: note: at offset 1 into object 'pad' of size 4
5 | char pad[sizeof(int *) * 1];
| ^~~
cc1: all warnings being treated as errors
```
And also removes sprintf() calls, which apparently MacOS no longer likes:
Environment: Sequoia 15.6.1 (24G90)
SDK Version: MacOSX15.sdk
```
ccan/ccan/closefrom/closefrom.c:83:2: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
83 | sprintf(dnam, "/proc/%ld/fd", (long) getpid());
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:278:1: note: 'sprintf' has been explicitly marked deprecated here
278 | deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:218:48: note: expanded from macro 'deprecated_msg'
218 | #define deprecated_msg(_msg) attribute((deprecated(_msg)))
| ^
ccan/ccan/closefrom/closefrom.c:162:2: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
162 | sprintf(dnam, "/proc/%ld/fd", (long) getpid());
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:278:1: note: 'sprintf' has been explicitly marked deprecated here
278 | deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:218:48: note: expanded from macro 'deprecated_msg'
218 | #define deprecated_msg(_msg) attribute((deprecated(_msg)))
| ^
2 errors generated.
make: *** [ccan-closefrom.o] Error 1
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Reported-by: Sangbida
Fixes: https://github.com/ElementsProject/lightning/issues/8581
Reported-by: https://github.com/Raimo33
Fixes: https://github.com/ElementsProject/lightning/issues/8501
Changelog-Fixed: build: we now build on MacOS without errors on the latest Command Line Tools (macOS 15 SDK).
Changelog-Fixes: build: fix build with -O2 on 32 bit arm (armhf)
This is a routine update to an internal code library (CCAN) used by Core Lightning. The main user-visible effect is fixing build failures on newer macOS and on 32-bit ARM when compiling with optimizations. It also replaces several old-style sprintf() calls with safer snprintf() versions. The sprintf() cases shown are generally low risk because the inputs are controlled (process IDs, small integers, fixed format strings), but switching to snprintf() is a defensive hardening improvement. There is no indication this fixes an active, exploitable vulnerability in running software.
9f2e6de6 · Oct 13, 2025 · 1 fileInformational 20wallet: fix migration speed for postgres.
Testing a large db shows Postgres slowing down exponentially as
it inserts the channel_events. Rather than updating the index in the
db every time, do it at the end, for spectacular speedup:
```
lightningd-1 2025-10-08T05:39:44.333Z INFO lightningd: Creating database
lightningd-1 2025-10-08T05:39:47.581Z DEBUG lightningd: Transferring 6166 chain_events
lightningd-1 2025-10-08T05:39:48.455Z DEBUG lightningd: Transferring 1660043 channel_events
lightningd-1 2025-10-08T05:39:54.390Z INFO lightningd: Inserted 103100/1660043 channel_events
lightningd-1 2025-10-08T05:40:04.390Z INFO lightningd: Inserted 283280/1660043 channel_events
lightningd-1 2025-10-08T05:40:14.390Z INFO lightningd: Inserted 464065/1660043 channel_events
lightningd-1 2025-10-08T05:40:24.390Z INFO lightningd: Inserted 629559/1660043 channel_events
lightningd-1 2025-10-08T05:40:34.390Z INFO lightningd: Inserted 800659/1660043 channel_events
lightningd-1 2025-10-08T05:40:44.390Z INFO lightningd: Inserted 975433/1660043 channel_events
lightningd-1 2025-10-08T05:40:54.390Z INFO lightningd: Inserted 1134719/1660043 channel_events
lightningd-1 2025-10-08T05:41:04.390Z INFO lightningd: Inserted 1290549/1660043 channel_events
lightningd-1 2025-10-08T05:41:14.390Z INFO lightningd: Inserted 1443304/1660043 channel_events
lightningd-1 2025-10-08T05:41:24.390Z INFO lightningd: Inserted 1590013/1660043 channel_events
lightningd-1 2025-10-08T05:41:29.148Z INFO lightningd: bookkeeper migration complete: migrated 6166 chainmoves, 1660043 channelmoves, 132481 descriptions
```
Now we complete the entire migration in 1 minute 45 seconds.
Thanks to @michael1101 for reporting this.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: db: migration from v25.09 on a reasonable size account database could take almost infinite time.
This commit fixes a database migration performance bug in Core Lightning. When users upgraded from version 25.09, migrating large account databases to Postgres could take an extremely long time because an index was being updated after every single inserted record. The fix batches the index update until the end of the migration, reducing the time from potentially hours to under two minutes. It is a performance and reliability fix, not a security vulnerability.
b260ec2f · Oct 13, 2025 · 1 fileInformational 15wallet: print progress reports for large account migration.
Show the work we're doing (at debug level) and every 10 seconds print
progress (at INFO level):x
```
lightningd-1 2025-10-08T05:13:07.973Z INFO lightningd: Creating database
lightningd-1 2025-10-08T05:13:10.987Z DEBUG lightningd: Transferring 6166 chain_events
lightningd-1 2025-10-08T05:13:11.780Z DEBUG lightningd: Transferring 1660043 channel_events
```
It's the inserting channel_events which takes a long time, slowing
down exponentially:
```
lightningd-1 2025-10-08T05:13:18.034Z INFO lightningd: Inserted 26690/1660043 channel_events
lightningd-1 2025-10-08T05:13:28.034Z INFO lightningd: Inserted 47086/1660043 channel_events
lightningd-1 2025-10-08T05:13:38.035Z INFO lightningd: Inserted 61699/1660043 channel_events
lightningd-1 2025-10-08T05:13:48.035Z INFO lightningd: Inserted 73743/1660043 channel_events
lightningd-1 2025-10-08T05:13:58.035Z INFO lightningd: Inserted 83244/1660043 channel_events
...
lightningd-1 2025-10-08T05:35:18.286Z INFO lightningd: Inserted 466720/1660043 channel_events
lightningd-1 2025-10-08T05:35:29.074Z INFO lightningd: Inserted 468437/1660043 channel_events
lightningd-1 2025-10-08T05:35:39.079Z INFO lightningd: Inserted 470130/1660043 channel_events
lightningd-1 2025-10-08T05:35:49.081Z INFO lightningd: Inserted 471871/1660043 channel_events
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds progress messages (logging) during a database migration. It does not change how data is moved or stored, and it does not fix or introduce any security issue. It is purely a user-experience improvement so operators can see that a long upgrade is still running.
2f80305b · Oct 13, 2025 · 3 filesInformational 12lightningd: explicit db arg to wait_index_increase so we can use it in migrations.
Before db is complete, ld->wallet->db is NULL.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a small internal code cleanup change. It changes a helper function so callers can pass in a database connection directly, rather than always using the one inside the main lightningd object. The commit message says this is needed because during database migrations the main wallet database pointer is not yet set. There is no indication this fixes a security bug or is itself a vulnerability.
5c71ba22 · Oct 13, 2025 · 1 fileLow 28pytest: test for malformed reply from first hop when using injectpaymentonion.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a new test case to Core Lightning's test suite. It checks how the software handles a malformed (corrupted) payment onion message when the first hop is the node that created the payment, using a developer-only RPC command called injectpaymentonion. The test is currently marked as expected to fail (xfail), meaning the behavior it checks is not yet working correctly. The commit itself does not fix any code; it only adds a test that documents a bug or missing behavior.
01e83b76 · Oct 13, 2025 · 2 filesModerate 64lightningd: handle unparsable onion from first hop when using injectonionmessage.
In this case we have a failmsg, so we should use that. Otherwise we can have
both failmsg and failonion NULL in the call to injectonion_fail, which is not
valid.
```
DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Removing out HTLC 1 state RCVD_REMOVE_ACK_REVOCATION WIRE_INVALID_ONION_HMAC
**BROKEN** lightningd: FATAL SIGNAL 11 (version v25.09-135-g19a3bbc-modded)
**BROKEN** lightningd: backtrace: common/daemon.c:41 (send_backtrace) 0x6220e8fe0080
**BROKEN** lightningd: backtrace: common/daemon.c:78 (crashdump) 0x6220e8fe00cf
**BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x73614bc4532f
**BROKEN** lightningd: backtrace: lightningd/pay.c:1701 (injectonion_fail) 0x6220e8f951c0
**BROKEN** lightningd: backtrace: lightningd/pay.c:330 (tell_waiters_failed) 0x6220e8f943be
**BROKEN** lightningd: backtrace: lightningd/pay.c:656 (payment_failed) 0x6220e8f98db1
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:313 (fail_out_htlc) 0x6220e8fa1d04
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:1988 (remove_htlc_out) 0x6220e8fa271b
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2086 (update_out_htlc) 0x6220e8fa2904
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2095 (changed_htlc) 0x6220e8fa2c24
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2608 (peer_got_revoke) 0x6220e8fa6e5a
**BROKEN** lightningd: backtrace: lightningd/channel_control.c:1555 (channel_msg) 0x6220e8f62725
**BROKEN** lightningd: backtrace: lightningd/subd.c:560 (sd_msg_read) 0x6220e8fb2eed
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:60 (next_plan) 0x6220e90a3335
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:422 (do_plan) 0x6220e90a3806
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:439 (io_ready) 0x6220e90a38c3
**BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:455 (io_loop) 0x6220e90a524f
**BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x6220e8f7d1c7
**BROKEN** lightningd: backtrace: lightningd/lightningd.c:1496 (main) 0x6220e8f82db2
**BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x73614bc2a1c9
**BROKEN** lightningd: backtrace: ../csu/libc-start.c:360 (__libc_start_main_impl) 0x73614bc2a28a
**BROKEN** lightningd: backtrace: (null):0 ((null)) 0x6220e8f53b64
**BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff
```
Reported-by: @michael1011
Changelog-Fixed: lightningd: potential crash when we receive a malformed onion complain from our first peer when using sendonion / injectpaymentonion.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This fix stops Core Lightning from crashing with a fatal signal 11 (segfault) when a payment sent via the low-level `sendonion`/`injectpaymentonion` path fails because the very first peer reports a malformed onion. Before the fix, the code could call an internal failure-handling routine with both the failure message and the failure onion set to NULL, which is not allowed and caused the daemon to crash. The patch reorders the logic so the malformed-onion message is used when available, and adds a safety assertion that the onion is present in the remaining case.
8a0e473e · Oct 10, 2025 · 3 filesInformational 19bump minimum python to 3.9.2 and downgrade coincurve
This allows compatibility with python 3.14.0 which coincurve 21.0.0 did
not support. The next coincurve release should restore compatibility.
Fixes: #8591
Changelog-changed: pyln-testing requires python>=3.9.2
This commit adjusts Python package versions so the project's testing tools install correctly on the newly released Python 3.14. It lowers the required 'coincurve' library from version 21.0.0 to 20.0.0 and raises the minimum Python version from 3.9 to 3.9.2. The change is framed by the developer as a compatibility fix, not a security fix. There is no direct evidence in the commit that it repairs a vulnerability.
d05a8ee7 · Oct 10, 2025 · 12 filesInformational 15chore: remove __init__.py for package extension
for python 3.3+ we don’t need an __init__.py at namespace package to
allow extensions instead we can just get rid of them
This commit removes empty Python package marker files called __init__.py from several related Python library packages. It is a routine modernization to use Python 3.3+'s built-in namespace package support instead of the older pkgutil workaround. There is no security-relevant change here.
ad040d0d · Oct 10, 2025 · 1 fileInformational 15docs: add frozen for uv sync
prevent updates to lock file which might leave working directory dirty
resulting in a modded cln version build
This commit only updates documentation. It adds the '--frozen' flag to 'uv sync' commands in the installation guide so that the build tool does not update the dependency lock file automatically. This prevents the working directory from becoming 'dirty' during a build, which could otherwise cause the compiled Core Lightning version string to incorrectly show as modified. There is no code change and no security vulnerability is introduced or fixed.
2879ef12 · Oct 10, 2025 · 6 filesInformational 15chore: remove uv sources defined at workspace level
duplicate definition isn’t required as we already defined them at
workspace level sources
This commit is a routine cleanup of Python project configuration files. It removes duplicate workspace dependency definitions that were already set at the workspace level. There is no security relevance: no code behavior changes, no bug fixes, and no vulnerability patches.
c7531b0f · Oct 7, 2025 · 2 filesModerate 51plugin: remove features when plugin is disabled
We need to remove the feature bits set via a plugins get_manifest
response when the init response disables the plugin.
Changelog-Fixed Remove feature bits set by a plugin when the plugin
disables itself during init.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit fixes a bug in Core Lightning where a plugin could advertise certain protocol features when it first starts up, then later disable itself during initialization, but leave those feature bits still advertised by the node. The fix stores the feature bits a plugin claims and removes them if the plugin later disables itself. A leftover feature bit could mislead other nodes about what this node supports, potentially causing connection or protocol issues, though it is not a direct theft-of-funds bug.
8895ca29 · Oct 2, 2025 · 1 fileInformational 11Revert "update makefile to remove hsm_encryption"
This reverts commit 084b03375cac181c7ddeba7204a11e2877645003.
This commit is a simple build-system revert that puts one file (common/hsm_encryption.o) back into the fuzzing test Makefile. It undoes a prior change that had removed that file from the fuzzer's build list. There is no direct code change shown, and nothing in the commit message or diff indicates a security vulnerability or fix. It is most likely a routine build correction.
f7db1440 · Oct 2, 2025 · 1 fileInformational 15pyln-testing: pass timeout to BitcoinProxy
The bitcoin.rpc.DEFAULT_HTTP_TIMEOUT of 30 seconds may not be enough
time to generate a block when the test machine is under load. Pass
pyln.testing.utils.TIMEOUT to bitcoin.rpc.RawProxy to allow extra time:
currently 60 seconds by default or 180 seconds if SLOW_MACHINE is set.
Changelog-None
This commit changes a testing helper so that calls to Bitcoin Core during automated tests wait longer before giving up. It is purely a test-infrastructure reliability tweak and does not affect production code, user funds, or network security.
7631ce63 · Oct 2, 2025 · 2 filesInformational 12wallet: unit test for duplicate detection in wallet_save_chain_mvt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds a new automated test file. It checks that a wallet function called wallet_save_chain_mvt correctly ignores exact duplicate records while still storing records that differ in transaction ID, output point, or movement type. There is no change to production code, no bug fix, and no security patch.
bd1ba164 · Oct 2, 2025 · 2 filesLow 28wallet: don't insert duplicate chain_moves entries after accounts.db migration.
When we migrate from accounts.db, we use the `account_nonchannel_id`
field. But we can replay the block chain and the channel involved is
still open, we will use the `account_channel_id` field, and our duplicate
detection fails.
As a result, we can end up with duplicate entries in the database, which
make accounting incorrect.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `listchainmoves` could contain bogus duplicate entries after 25.09 bookkeeper migration.
This commit fixes a bug in Core Lightning's accounting/bookkeeping system where the same on-chain money movement could be recorded twice in the database after a migration. The bug happens because the code looked for duplicates using one account identifier, but after a migration or replay it could store the same event under a different identifier. The fix makes duplicate detection check both possible identifiers. It is a data-integrity bug, not a security vulnerability that an attacker can exploit.
fb973fea · Oct 2, 2025 · 3 filesLow 27wallet: find and remove any duplicates from the bug we just fixed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a database cleanup routine that removes accidentally duplicated accounting records created by a previous bug. It is a data-integrity fix, not a security patch that stops an active attack. The underlying bug allowed the same on-chain money movement to be recorded twice—once under a live channel reference and once under a non-channel account reference—so users' coin-movement reports could be wrong until the duplicates are removed.
5b06e653 · Oct 2, 2025 · 2 filesInformational 12wallet: unit test the migration dedup code.
This is based on a real database, which values changed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a new automated test for a database cleanup routine called migrate_remove_chain_moves_duplicates. The test builds a small in-memory database, inserts many example records (some deliberately duplicated), runs the cleanup function, and checks that only the duplicates are removed. It does not change the actual cleanup code or any production behavior; it only adds test coverage.
cb2849d0 · Oct 2, 2025 · 5 filesInformational 21wallet: don't delete old htlcs when we forget a channel, do it on startup.
For old channels, this can take a while, and it stops everything. But
we are only doing this to save space; it's not a *functional* necessity.
A quick and dirty test with 50,000 htlcs shows the htlc deletion took
450msec. I tried adding an index, and changing it to set hstate to
HTLC_STATE_INVALID instead of deleting entries, but it still took about 350ms.
Whereas the "COUNT(*)" only took 1.7msec, so it's worth keeping.
Reported-by: @michael1011
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: lightningd: we defer deletion of old htlcs on channel close, to avoid pausing for a long time (we clean them on startup)
Fixes: https://github.com/ElementsProject/lightning/issues/7962
This change moves a database cleanup job from the moment a channel closes to the next time the node starts up. Previously, deleting tens of thousands of old payment records when a channel closed could freeze the node for hundreds of milliseconds. Now the records are counted and reported immediately, but actually deleted later during startup. It is a performance and availability improvement, not a security fix.
bee54f0e · Oct 2, 2025 · 1 fileInformational 18wallet: don't show htlcs from closed channels in listhtlcs.
This doesn't happen yet, since we delete all HTLCs when we close a channel. But we're
about to change that, so update the wallet_htlcs_first() code to avoid them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a small, forward-looking cleanup change in Core Lightning's wallet code. It adjusts a database query so that the `listhtlcs` command will not return HTLCs (payment forwarding contracts) belonging to channels that have already been closed. The commit explicitly says this situation cannot happen yet because HTLCs are currently deleted when a channel closes, but the code is being prepared for an upcoming change where closed-channel HTLCs may be kept around.