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 16 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.
266b8082 · Oct 26, 2025 · 8 filesInformational 19hsmd_wire: add HSM wire protocol support for secret type detection
Add TLV field to hsmd_init_reply_v4 to communicate the HSM secret type
(mnemonic vs legacy) from HSM to lightningd. This allows lightningd to
automatically determine whether to use BIP86 or BIP32 derivation without
needing separate address types.
This commit adds a small metadata field to the internal HSM (Hardware Security Module) initialization message so that lightningd can tell whether the wallet seed was created from a mnemonic phrase or from an older legacy secret. It is a protocol plumbing change, not a fix for a known vulnerability, and does not by itself change how secrets are generated, stored, or protected.
9977b72e · Oct 26, 2025 · 3 filesInformational 11common: add unified HSM secret handling module
This is a newer API to replace hsm_encryption.c and hsm_encryption.c, this tidies up the API to be used and also cleans things up to support our new formats. Our hsm_secret formats now include:
- Legacy 32-byte plain format
- Legacy 73-byte encrypted format
- New mnemonic format without passphrase (32 zero bytes + mnemonic)
- New mnemonic format with passphrase (32-byte hash + mnemonic)
This commit includes support to detect the format based on the file size and content structure. The hsm will store mnemonics in the hsm_secret file as:
`passphraseHash`mnemonic`
This commit adds a new internal module for handling the secret key file used by Core Lightning's hardware security module (HSM). It introduces support for reading the existing plain and encrypted formats, plus new formats based on BIP39 word lists (mnemonics) with optional passphrases. The code uses modern password hashing (Argon2) and authenticated encryption (libsodium secretstream). There is no direct evidence in the commit that this fixes a known security vulnerability; it appears to be a feature/refactoring change to support new wallet backup formats.
478a0d57 · Oct 24, 2025 · 5 filesInformational 24wallet: make sure to watch all txids in transactions table.
We watch if they are to do with a channel, or have outputs going to us, but otherwise
we didn't, so we never updated the blockheight in the db.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `listtransactions` now correctly updates `blockheight` for txs created by `sendpsbt` which have no change outputs.
This commit fixes a bookkeeping bug in Core Lightning's wallet. When a user broadcast a transaction created with `sendpsbt` that had no change output coming back to the node, the node did not track the transaction's confirmation status. As a result, `listtransactions` would never show the correct `blockheight` for that transaction. The fix makes the node explicitly watch all unconfirmed transactions in its database so their confirmation height gets updated. There is no direct security exploit here; it is a data-correctness and user-experience issue.
2591ac48 · Oct 24, 2025 · 1 fileInformational 12pytest: add test that we notice height change of sendpsbt with no change.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds a new automated test to the project's test suite. It does not change any production code, so it cannot directly fix or introduce a security vulnerability. The test checks that a wallet transaction created via sendpsbt is correctly tracked from unconfirmed to confirmed status, including after a node restart. It is currently marked as expected to fail (xfail), meaning the underlying behavior may not yet work as intended.
8f6d3d87 · Oct 24, 2025 · 5 filesModerate 68plugins: fix %*.s typo.
And add a check for new uses creeping in, since it got cut & paste
everywhere.
This means "this is a valid string, but truncate it to this many characters"
vs "%.*s" which means "only read this many characters of string":
```
['lightningd-3 2025-10-23T02:31:40.890Z **BROKEN** plugin-funder: Plugin marked as important, shutting down lightningd!']
--------------------------- Captured stderr teardown ---------------------------
#0 0x557da58ad1dc in printf_common(void*, char const*, __va_list_tag*) asan_interceptors.cpp.o
#1 0x557da5aff814 in json_out_addv /home/runner/work/lightning/lightning/ccan/ccan/json_out/json_out.c:239:11
#2 0x557da59740ce in plugin_logv /home/runner/work/lightning/lightning/plugins/libplugin.c:1777:2
#3 0x557da5969b6f in plugin_log /home/runner/work/lightning/lightning/plugins/libplugin.c:1934:2
#4 0x557da595c4f6 in datastore_del_success /home/runner/work/lightning/lightning/plugins/funder.c:161:2
#5 0x557da598b837 in handle_rpc_reply /home/runner/work/lightning/lightning/plugins/libplugin.c:1072:10
#6 0x557da598a4b0 in rpc_conn_read_response /home/runner/work/lightning/lightning/plugins/libplugin.c:1361:3
#7 0x557da5adbea5 in next_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:60:9
#8 0x557da5ae06ff in do_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:422:8
#9 0x557da5adfb58 in io_ready /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:439:10
#10 0x557da5aec2ce in io_loop /home/runner/work/lightning/lightning/ccan/ccan/io/poll.c:455:5
#11 0x557da59757ac in plugin_main /home/runner/work/lightning/lightning/plugins/libplugin.c:2409:3
#12 0x557da594fe23 in main /home/runner/work/lightning/lightning/plugins/funder.c:1723:2
#13 0x7f6572229d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#14 0x7f6572229e3f in __libc_start_main csu/../csu/libc-start.c:392:3
#15 0x557da588b584 in _start (/home/runner/work/lightning/lightning/plugins/funder+0x10d584) (BuildId: 71ba63ab577fc6fa60573d3e8555f6db7d5c584d)
0x624000009d28 is located 0 bytes to the right of 7208-byte region [0x624000008100,0x624000009d28)
allocated by thread T0 here:
#0 0x557da590e7f6 in __interceptor_realloc (/home/runner/work/lightning/lightning/plugins/funder+0x1907f6) (BuildId: 71ba63ab577fc6fa60573d3e8555f6db7d5c584d)
#1 0x557da5b2149b in tal_resize_ /home/runner/work/lightning/lightning/ccan/ccan/tal/tal.c:755:13
#2 0x557da59f2032 in membuf_tal_resize /home/runner/work/lightning/lightning/common/utils.c:203:2
#3 0x557da5b03934 in membuf_prepare_space_ /home/runner/work/lightning/lightning/ccan/ccan/membuf/membuf.c:45:12
#4 0x557da59d4289 in jsonrpc_io_read_ /home/runner/work/lightning/lightning/common/jsonrpc_io.c:127:2
#5 0x557da598a635 in rpc_conn_read_response /home/runner/work/lightning/lightning/plugins/libplugin.c:1366:9
#6 0x557da5adbea5 in next_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:60:9
#7 0x557da5ae06ff in do_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:422:8
#8 0x557da5adfb58 in io_ready /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:439:10
#9 0x557da5aec2ce in io_loop /home/runner/work/lightning/lightning/ccan/ccan/io/poll.c:455:5
#10 0x557da59757ac in plugin_main /home/runner/work/lightning/lightning/plugins/libplugin.c:2409:3
#11 0x557da594fe23 in main /home/runner/work/lightning/lightning/plugins/funder.c:1723:2
#12 0x7f6572229d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
SUMMARY: AddressSanitizer: heap-buffer-overflow asan_interceptors.cpp.o in printf_common(void*, char const*, __va_list_tag*)
Shadow bytes around the buggy address:
0x0c487fff9350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c487fff93a0: 00 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa fa
0x0c487fff93b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==26122==ABORTING
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a typo in several Core Lightning plugins where the wrong printf format string was used. The buggy '%*.s' tells the program to treat a string pointer as a width and then read an unlimited number of bytes from another pointer, which can read past the end of a buffer and crash or leak memory. The fix changes it to '%.*s', which correctly limits how many bytes are read from the string. The commit also adds a build-time check to stop the typo from being reintroduced.
d8ee3a5e · Oct 22, 2025 · 7 filesInformational 15tests/fuzz: fix include order.
Nobody ever runs `make check-includes` with fuzzing enabled.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only reorders #include lines in fuzz-test source files and adds minor indentation to two direct .c file includes. It is a coding-style/build-hygiene fix with no functional code changes and no security relevance.
e120f870 · Oct 22, 2025 · 83 filesInformational 15Makefile: create a library containing common, wire and bitcoin objects.
This means we don't have to manually choose what to link against,
which is much of the complexity of our Makefiles: the compiler will
automatically use any object files it needs to link.
We already do this for ccan as libccan.a, now we have libcommon.a.
We don't link against it for *everything*, as some tests require their own
versions.
Notes:
1. I get rid of the weird plugins/test/Makefile2 (accidental commit?)
2. Many tests change due to update-mocks.
3. In some places I added the missing dependency on the Makefile itself, though most are in the next
patch.
Before:
Total program size: 221366528
Total tests size: 364243856
After:
Total program size: 190733656
Total tests size: 337880888
Build time from make clean (RUST=0) (includes building external libs):
Before:
real 0m38.227000-44.245000(41.8222+/-1.6)s
user 3m2.105000-33.696000(23.1442+/-8.4)s
sys 0m35.054000-42.269000(39.7231+/-2)s
After:
real 0m38.944000-40.416000(40.1131+/-0.4)s
user 3m6.790000-17.159000(15.0571+/-2.8)s
sys 0m35.304000-37.336000(36.8942+/-0.57)s
Build time after touch config.vars (RUST=0):
Before:
real 0m18.928000-22.776000(21.5084+/-1.1)s
user 2m8.613000-36.567000(27.7281+/-7.7)s
sys 0m20.458000-23.436000(22.3963+/-0.77)s
After:
real 0m19.831000-21.862000(21.5528+/-0.58)s
user 2m15.361000-30.731000(28.4798+/-4.4)s
sys 0m21.056000-22.339000(22.0346+/-0.35)s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rusty@rusty-Framework:~/devel/cvs/lightni
This commit is a build-system cleanup. It creates a new static library (libcommon.a) containing common, wire, and bitcoin object files so that Makefiles no longer need to list individual object files by hand. It also removes many auto-generated mock function stubs from unit tests because those functions are now provided by the library. There is no runtime behavior change to Core Lightning itself, and no security issue is introduced or fixed.
f6a4e794 · Oct 22, 2025 · 212 filesInformational 15global: remove unnecessary includes from headers.
Each header should only include the other headers it needs to compile;
`devtools/reduce-includes.sh */*.h` does this. The C files then need
additional includes if they don't compile.
And remove the entirely useless wire/onion_wire.h, which only serves to include wire/onion_wiregen.h.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a large but purely mechanical cleanup of C header file #include directives across the Core Lightning codebase. The goal is to make each header include only what it actually needs, and to add missing includes to the .c source files that now need them. It also deletes a tiny wrapper header that did nothing but include another generated header. There is no change to program logic, data handling, or security behavior.
2adfdfd0 · Oct 22, 2025 · 15 filesInformational 15Makefile: run fuzzing corpora as normal unit tests in non-fuzzing mode.
This means we can make sure the compile and run in normal builds.
Side note: various tests call common_setup(), which means we called it
twice in unit testing mode, so we conditionalize those.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit changes the build system so that existing fuzz tests can also run as ordinary unit tests in normal (non-fuzzing) builds. It does not fix a bug, change runtime behavior of Core Lightning in production, or introduce any user-facing feature. It is purely a testing/CI infrastructure improvement.
6e5cb299 · Oct 22, 2025 · 177 filesInformational 15global: remove unnecessary includes from C files.
Basically, `devtools/reduce-includes.sh */*.c`.
Build time from make clean (RUST=0) (includes building external libs):
Before:
real 0m38.944000-40.416000(40.1131+/-0.4)s
user 3m6.790000-17.159000(15.0571+/-2.8)s
sys 0m35.304000-37.336000(36.8942+/-0.57)s
After:
real 0m37.872000-39.974000(39.5466+/-0.59)s
user 3m1.211000-14.968000(12.4556+/-3.9)s
sys 0m35.008000-36.830000(36.4143+/-0.5)s
Build time after touch config.vars (RUST=0):
Before:
real 0m19.831000-21.862000(21.5528+/-0.58)s
user 2m15.361000-30.731000(28.4798+/-4.4)s
sys 0m21.056000-22.339000(22.0346+/-0.35)s
After:
real 0m18.384000-21.307000(20.8605+/-0.92)s
user 2m5.585000-26.843000(23.6017+/-6.7)s
sys 0m19.650000-22.003000(21.4943+/-0.69)s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a routine code cleanup: it removes unused C-language #include directives from many source files and adds a few that were needed but previously inherited indirectly. The stated goal is faster build times, and the diff shows no functional code changes. There is no security-relevant behavior change.
ad0c7318 · Oct 22, 2025 · 1 fileInformational 15makefile: fix glob expansion for macOS
when bash expands bitcoin/*.h, it returns the files in lexicographically sorted order by default this is not necessarily the case for macOS so it has be explicitly sorted. I get a fairly uninformative error like this:
make: *** [check-bitcoin-makefile] Error 1
The error is now more informative and does not error on a clean branch on macOS:
BITCOIN_HEADERS missing: bitcoin/signature.h bitcoin/tx_parts.h bitcoin/tx.h bitcoin/varint.h
make: *** [check-bitcoin-makefile] Error 1
This commit fixes a build script check that was too strict on macOS. The Makefile check compares a manually maintained list of Bitcoin header files against files found on disk. On Linux, the shell lists files in sorted order, but macOS does not, causing the check to fail even when nothing is wrong. The patch makes the comparison order-independent and prints clearer error messages. It is a build tooling fix with no security relevance.
ea2f7607 · Oct 20, 2025 · 1 fileInformational 18tools: Read the correct default-key from gpgconf
Workflow error `gpg: using "4129A994AA7E9852" is thrown due to incorrect gpg parsing. Update the awk parsing logic to properly locate and extract the key fingerprint within the gpgconf --list-options output structure, ensuring automated signing uses the correct key.
Changelog-None.
This is a one-line fix in the release build script. It changes how the script tells GnuPG which key to use when signing release checksum files. Previously the key fingerprint was accidentally passed as a filename argument to gpg, which caused a harmless workflow error and could have led to the wrong key being used for signing. The fix moves the fingerprint to the proper --default-key option so signing uses the intended key.
e522aedc · Oct 20, 2025 · 1 fileModerate 53bookkeeper: only read listchannelmoves 1000 entries at a time.
If we read all of them, we might get 1.6M at once (after initial
migration). Then we submit a few hundred thousand simultaneous
requests to lightningd, and it gets upset, queueing them all on the
xpay command hook and running out of memory.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: plugins: bookkeeper first invocation after migration from prior to 25.09 with very large databases will not crash.
This update fixes a bug in the bookkeeper plugin of Core Lightning. After a large database migration, the plugin could ask for too many records at once, flood the main lightningd process with hundreds of thousands of requests, and cause it to run out of memory and crash. The fix reads records in batches of 1,000 instead of all at once.
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.
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.
89bce951 · Oct 1, 2025 · 3 filesLow 34dualopend: handle ANNOUNCEMENT_SIGNATURES from peer.
This can happen if we haven't transitioned to channeld yet, but logic is simply to hand
it to lightningd, exactly as channeld does.
```
2025-09-30T03:04:57.8951627Z lightningd-1 2025-09-30T02:59:14.150Z DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-dualopend-chan#1: peer_out WIRE_WARNING
2025-09-30T03:04:57.8952126Z lightningd-1 2025-09-30T02:59:14.150Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-dualopend-chan#1: Unexpected message WIRE_ANNOUNCEMENT_SIGNATURES
2025-09-30T03:04:57.8952521Z lightningd-1 2025-09-30T02:59:14.150Z INFO 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-dualopend-chan#1: Peer connection lost
2025-09-30T03:04:57.8953124Z lightningd-1 2025-09-30T02:59:14.150Z INFO 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Peer transient failure in DUALOPEND_AWAITING_LOCKIN: dualopend: Owning subdaemon dualopend died (62208)
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This patch fixes a bug where Core Lightning's dual-funding channel opener (dualopend) would crash with a 'BROKEN' error if a peer sent ANNOUNCEMENT_SIGNATURES messages before the channel had fully transitioned to the normal channel daemon. The fix simply forwards those messages to the main lightningd process, just as the regular channel daemon already does. Without the patch, a peer could cause transient connection failures and daemon restarts during channel setup.
13c5db51 · Sep 28, 2025 · 40 filesInformational 17Refactor Dockerfile, Add TODOs
all these changelogs only apply to the Docker image.
Changelog-Added: added verification of GPG keys for the bitcoin and litecoin tarballs.
Changelog-Fixed: fixed compilation on all target architectures; each had their own bugs (poetry, missing packages...).
Changelog-Fixed: fixed cargo cross compilation. it was mistakenly using QEMU before.
Changelog-Fixed: fixed CPU compatibility bug described in issue 8456
Changelog-Changed: improve build time by 8.8x
Changelog-Changed: improve image size by 2.07x
more detailed changelog can be found on the PR: https://github.com/ElementsProject/lightning/pull/8429
This commit is a large refactor of the Docker build files for Core Lightning. It mainly improves how Docker images are built, adds verification of downloaded Bitcoin and Litecoin binaries using GPG signatures, fixes cross-compilation issues, and updates build documentation. There is no obvious security vulnerability introduced by the changes; in fact, adding GPG verification is a security improvement. However, the commit removes the use of `tini` as the container init process and switches the entrypoint directly to a shell script, which is a minor operational change. The commit does not appear to fix or introduce a serious security bug in the Core Lightning software itself.
20e252b5 · Sep 15, 2025 · 1 fileInformational 18fuzz-tests: fix overflow of u32 in `fuzz-close-tx`
Changelog-None: The value WALLY_SATOSHI_PER_BTC * WALLY_BTC_MAX
is equal to 2.1e15, which is much higher than the maximum capacity
of a u32, which is 4.29e9.
Hence, use a u64 to store this value instead.
This commit fixes a variable type bug in a fuzz test, not in the main Core Lightning software. A fuzz test is an automated testing tool that feeds random data to a program to find crashes. The bug was that a calculation used a 32-bit integer (u32) to hold a value far larger than it can represent, causing an overflow. The fix changes the variable type to a 64-bit integer (u64). Because this is only in a test file, it does not directly affect real Lightning nodes or user funds.
f920c1e7 · Sep 10, 2025 · 1 fileInformational 15doc: rc1 build-release instructions.
Signing `--without-zip` will not work. You will end up with a empty SHA256SUMS file.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a one-line documentation fix in the release checklist. It removes the `--without-zip` flag from an example command because using that flag would produce an empty SHA256SUMS file. There is no code change and no security vulnerability.
bc753a2f · Sep 2, 2025 · 1 fileInformational 15contrib: add Madeline's signing key.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit simply adds a new PGP public key file for a person named Madeline to the project's contributor key directory. It is a routine administrative change with no code modifications and no direct security impact.
397fdd9e · Aug 19, 2025 · 1 fileInformational 15pytest: test coinmoves in the case of unexpected fulfill.
This happens if l1 doesn't get a signature, so it doesn't consider
the fulfill complete, but l2 does (and thus credits l1).
This is a trivial test, but will matter should we later correctly
account for channelmoves when onchain: in that case it will actually
hard to tell, in general, what HTLC(s) were fulfilled.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds a new test case to the project's test suite. It simulates a scenario where one side of a Lightning payment channel believes an HTLC was fulfilled while the other side does not, then verifies that the internal accounting records (called 'coinmoves') are produced correctly. There is no change to production code, no fix, and no vulnerability being patched.
ea2feccb · Aug 15, 2025 · 3 filesLow 35common: set errno=0 before calling strto{l,ul,ull}
The strto{l,ul,ull} functions do not set errno upon a successful return, so a
successful return from a maximally valued input could be misinterpreted as an
overflow error if errno happened already to be set to ERANGE before the call.
To guard against this edge case, always set errno to zero before calling these
functions if checking errno afterward.
Changelog-None
This commit fixes a subtle programming bug in how Core Lightning converts text strings to numbers. Functions like strtoull only set an error flag (errno) when a value is too large, but they leave it unchanged on success. If some earlier code had already set that flag to 'overflow,' a later successful conversion of the largest possible number could be wrongly rejected as an overflow. The patch clears the error flag before each conversion so the check afterward is reliable. The practical security impact is limited because the bug only triggers when a prior operation happens to leave that specific error flag set, and the affected conversions are mostly for amounts, route hints, and JSON parsing rather than cryptographic checks.
5f544038 · Aug 14, 2025 · 8 filesLow 37lightningd: fix race with crossover pings.
We cannot use subd_req() here: replies will come out of order, and the
we should not simply assign the reponses in FIFO order.
Changelog-Fixed: lightningd: don't get confused with parallel ping commands.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a bug in Core Lightning's handling of multiple ping commands sent at the same time. Previously, if two ping commands were issued in parallel, the replies could arrive out of order and be matched to the wrong command, potentially causing incorrect responses or confusion in the node. The fix adds a unique request ID to each ping so replies can be correctly paired with their original commands.
e755be0c · Aug 14, 2025 · 4 filesLow 31splice: Remove `batch_size` from `commitment_signed`
The new spec sends `batch_size` in `start_batch` and removes it from `commitment_signed` so we need to stop processing it in `commitment_signed`.
Since the tlv is now reduced to one element and that automagically turns it into a direct use TLV so we have to update the code everywhere it is referenced.
This commit updates Core Lightning's implementation of the Lightning Network splicing protocol to match a newer version of the specification. It removes a 'batch_size' field from the 'commitment_signed' message and moves that information to a different message ('start_batch'). The code changes are mostly mechanical: updating data structures, removing checks that used batch_size, and adjusting how messages are parsed and compared. There is no direct evidence in the commit or supplied references that this fixes a security vulnerability; it appears to be a protocol compatibility/spec-compliance update.
07f4bc39 · Aug 14, 2025 · 11 filesInformational 23splice: Add `start_batch` and an internal wire type
We add `start_batch` to match t-bast’s splicing spec and we add a new internal wire type `WIRE_PROTOCOL_BATCH_ELEMENT` using the type number 0
Changelog-Added: support for `start_batch`
This commit adds support for two new Lightning protocol messages used in splicing: `start_batch` and an internal-only `protocol_batch_element`. The code mostly ignores or routes these messages; it does not appear to fix a security bug. The change is a feature addition matching a draft specification, with no clear security relevance in the diff itself.