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 4 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.
5cdb7bde · Mar 22, 2026 · 1 fileInformational 24chaintopology: don't use txfilter, rely on wallet_extract_owned_outputs.
txfilter.c keeps a hash with interface:
* INSERT: txfilter_add_scriptpubkey &txfilter_add_derkey
* SEARCH: txfilter_match & txfilter_scriptpubkey_matches. It simply returns true/false.
wallet.c keeps an our_addresses hash:
* INSERT: on-demand when asked based on max keyidx (plus gap)
* SEARCH: wallet_can_spend (and thus its caller wallet_extract_owned_outputs).
Here are the places which populate the txfilter:
lightningd/channel.c:
- When we generate our own address final address
=> this is already covered when we call wallet_get_newindex() to get the final_key_idx
lightningd/lightningd.c:
- init_txfilter initializes all the prior addresses
=> wallet_can_spend populates this on first call.
wallet/reservation.c:
- finish_psbt and json_addpsbtoutput for change output
=> this is already covered when get call wallet_get_newindex() in the same funciton.
wallet/wallet.c:
- got_utxo for unconfirmed outputs
=> This is called when we have already determined we can spend the output (wallet_extract_owned_outputs), or on the fixup migration where the addresses are populated from a keyindex we've already created.
wallet/walletrpc.c:
- newaddr_inner
=> Already covered by wallet_get_newindex()
The result: we can just rely on the wallet to find our addresses, and
we don't need the txfilter at all. Just make chaintopology ask the
wallet directly.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit removes an old shortcut (a Bloom-like 'txfilter') that Core Lightning used to guess whether a new Bitcoin block contained transactions relevant to the wallet. Instead, it now asks the wallet directly to identify which transaction outputs belong to the node. The change is a code simplification and likely a defensive fix: the old filter could in theory miss transactions or produce false positives, while the wallet lookup is authoritative. There is no direct evidence in the commit that this was exploited or that it caused a concrete loss of funds, but it touches the code that decides whether the node notices its own on-chain payments.
46984883 · Mar 20, 2026 · 6 filesLow 42splice: Fix weight calculations & use opening feerate
Here we update `psbt_input_get_weight` to allow the caller to specify what kind of input size estimation they would like. Before it was just “zero witness bytes” which we now move to the default behavior and add an assumption option for P2WSH -> 2of2 multisig which is what we typically see in splicing.
At the same time we move channeld over to using the opening feerate estimation instead of the less useful “max feerate.” We make splice script use this same feerate.
After auditing the feerates for these two places against each other and the actually created transaction, we implement some fixes making them all match.
While we’re here, we add relevant debug log messages.
This commit fixes how Core Lightning estimates the size (and therefore the required mining fee) of Bitcoin transactions used in channel splicing. Before, the code underestimated input weights for common 2-of-2 multisig splicing inputs and used a less useful 'maximum feerate' as a safety cap. The patch adds better size-estimation options, switches the safety cap to the 'opening feerate,' and aligns the math between the different components that negotiate a splice. The main risk is that incorrect fee math could cause a splice transaction to be rejected by the network (too low fee) or to overpay/underpay, potentially disrupting channel operations or funds movement.
404bb5a0 · Mar 20, 2026 · 1 fileInformational 20gossip: Don’t reset channel on stale annoncement
Splicing can create stale announcements where the original funding output gets spent creating spruious “channel_announcement: no unspent txout” warnings.
This happens particuarlly often with agressive splice tests in CI, so we downgrade this from a warning to a log message.
This change fixes a minor operational bug in Core Lightning's gossip handling. Previously, when a stale channel announcement arrived after a channel was spliced (a process that spends the original funding output), the software treated it as a warning and reset the peer connection. The patch downgrades this to a simple log/trace message and ignores the stale announcement, which matches the Lightning specification. This is a stability improvement, not a security vulnerability fix.
05736f96 · Mar 19, 2026 · 2 filesLow 28lightningd: unreserve UTXOs from withheld funding PSBT when dropping channel
When a channel using a withheld funding PSBT is dropped, we need to
unreserve the UTXOs from the PSBT. Otherwise those funds will remain
blocked until the reservation expires, delaying their availability for
other transactions.
Changelog-Fixed: lightningd: unreserve UTXOs from withheld funding PSBT
on channel close.
This fix ensures that when a user opens a 'zero-confirmation' channel whose funding transaction is deliberately withheld and then the channel is closed/aborted, any bitcoin inputs that had been set aside (reserved) for that funding transaction are released back to the wallet promptly. Before this fix, those coins could stay locked up until an automatic timeout expired, making them unavailable for other payments or channel opens.
60cd23e3 · Mar 17, 2026 · 7 filesLow 28reestablish: Send announcement sigs when asked
A new TLV in `channel_reestablish` lets our peer request announcement signatures. This updates CLN to (re)send them when requested.
As per splice spec PR https://github.com/lightning/bolts/pull/1160/changes#diff-ed04ca2c673fd6aabde69389511fa9ee60cb44d6b2ef6c88b549ffaa753d6afeR3303-R3308
Changelog-None
This commit changes how Core Lightning handles reconnection with another Lightning node. It adds a way for the peer to ask for 'announcement signatures' again after reconnecting, and makes the node resend them when asked. This is part of a protocol update for splicing. It is not a traditional security fix; it is a protocol compliance/robustness change that could help prevent channel announcement issues after reconnections or splices.
53a5512c · Feb 27, 2026 · 2 filesInformational 15schemas: fix ping requirements documentation
Changelog-None
This commit only changes two lines of documentation text in JSON schema files. It corrects the description of the 'ping' command to say it works with any currently connected peer, not just peers with an open payment channel. There is no code change and no security impact.
d39ba340 · Feb 24, 2026 · 1 fileInformational 15CI: make downgrade and slow integration tests depend on check-compiled-source step.
As pointed out by Alex Myers: we don't want to waste time running the
complex steps if the generated files are not up-to-date.
But we still run the faster "integration" tests (not valgrind or
sanitizer ones), since they often reveal early failures.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit changes the GitHub Actions CI workflow so that three slower, more complex test jobs now wait for a 'check-compiled-source' step instead of the plain 'compile' step. It is purely a build-pipeline efficiency tweak to avoid wasting time on long tests when generated source files are stale. There is no change to application code, no security fix, and no vulnerability.
77251ec1 · Feb 24, 2026 · 1 fileInformational 15CI: use nproc + 1 for pytest parallelism..
More future proof, better for self-hosted runners.
Example run times before:
4s CI completion
2m 36s Check we can downgrade the node (compile-gcc, sqlite3, liquid-regtest)
2m 52s Check we can downgrade the node (compile-gcc, postgres, regtest)
3m 20s Check we can downgrade the node (compile-gcc, sqlite3, regtest, 1)
3m 20s Check we can downgrade the node (compile-gcc, sqlite3, regtest, 1)
8m 1s Run fuzz regression tests
11m 46s Run unit tests (compile-clang-sanitizers, 0)
12m 59s Compile CLN compile-gcc
13m 42s Compile CLN compile-clang
14m 10s Compile CLN compile-gcc-O3
14m 15s Compile CLN compile-clang-sanitizers
15m 23s Pre-build checks
19m 37s Test CLN dual-fund
26m 49s Run unit tests (compile-gcc, 1)
43m 19s Valgrind Test CLN Valgrind (06/10)
43m 21s Valgrind Test CLN Valgrind (08/10)
43m 40s Valgrind Test CLN Valgrind (05/10)
43m 59s Valgrind Test CLN Valgrind (03/10)
44m 4s Valgrind Test CLN Valgrind (07/10)
47m 28s Valgrind Test CLN Valgrind (09/10)
47m 37s Valgrind Test CLN Valgrind (02/10)
47m 45s Valgrind Test CLN Valgrind (01/10)
52m 51s Valgrind Test CLN Valgrind (04/10)
54m 6s Valgrind Test CLN Valgrind (10/10)
1h 14m 13s Sanitizers Test CLN (ASan/UBSan (03/12), 3, --test-group=3 --test-group-count=12)
1h 14m 6s Sanitizers Test CLN (ASan/UBSan (06/12), 6, --test-group=6 --test-group-count=12)
1h 15m 23s Sanitizers Test CLN (ASan/UBSan (01/12), 1, --test-group=1 --test-group-count=12)
1h 20m 30s Sanitizers Test CLN (ASan/UBSan (08/12), 8, --test-group=8 --test-group-count=12)
1h 22m 35s Sanitizers Test CLN (ASan/UBSan (12/12), 12, --test-group=12 --test-group-count=12)
1h 23m 49s Sanitizers Test CLN (ASan/UBSan (04/12), 4, --test-group=4 --test-group-count=12)
1h 26m 11s Sanitizers Test CLN (ASan/UBSan (07/12), 7, --test-group=7 --test-group-count=12)
1h 28m 44s Sanitizers Test CLN (ASan/UBSan (05/12), 5, --test-group=5 --test-group-count=12)
1h 29m 1s Sanitizers Test CLN (ASan/UBSan (02/12), 2, --test-group=2 --test-group-count=12)
1h 29m 4s Sanitizers Test CLN (ASan/UBSan (11/12), 11, --test-group=11 --test-group-count=12)
1h 31m 36s Sanitizers Test CLN (ASan/UBSan (09/12), 9, --test-group=9 --test-group-count=12)
1h 38m 54s Sanitizers Test CLN (ASan/UBSan (10/12), 10, --test-group=10 --test-group-count=12)
1h 39m 22s Test CLN liquid
1h 52m 23s Test minimum supported BTC v25.0 with clang
1h 52m 28s Test CLN gcc
1h 53m 57s Test CLN splicing
1h 57m 25s Test CLN postgres
1h 59m 25s Test CLN clang
2d 17h 56m 16s TOTAL
Example runtimes afterwards:
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only changes how many parallel test jobs run in the project's automated continuous integration (CI) system. It replaces hard-coded numbers like 4 or 2 with a dynamic value based on the number of available CPU cores. There is no change to the Core Lightning node software itself, its network behavior, wallet handling, or any user-facing feature. It is purely an infrastructure speed-up.
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.
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.
d4c62f8c · Feb 16, 2026 · 2 filesInformational 18tools: delete gossip_store of needed for downgrade even if db hasn't changed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a small bug-fix in a downgrade helper tool. Previously, the tool only deleted an incompatible gossip data file when the database actually needed changes. Now it deletes that file even if the database is already compatible, preventing a scenario where downgrading leaves behind a gossip file that the older version cannot read. It is a correctness fix, not an exploitable security vulnerability.
1ad8ca96 · Feb 16, 2026 · 7 filesInformational 18gossmap: add callback for gossipd to see dying messages.
gossmap doesn't care, so gossipd currently has to iterate through the
store to find them at startup. Create a callback for gossipd to use
instead.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a new internal callback mechanism so the gossipd component can be notified when the network graph sees a 'dying channel' message. It is a code cleanup/refactoring change: previously gossipd had to scan the entire gossip store at startup to find these messages, now it can receive them through a callback. There is no indication this fixes a security bug or introduces a vulnerability.
fe5c3c95 · Jan 26, 2026 · 1 fileInformational 15wallet: conduct unit tests with both bip86 and bip32.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only changes test code. It makes the wallet unit tests run twice: once using the older BIP32 key derivation setup and once using the newer BIP86 setup. No production code is modified, so it cannot directly affect real users or introduce a runtime security flaw.
1279a589 · Jan 26, 2026 · 10 filesInformational 15pytest: changed old_hsmsecret to default to false.
This changes various tests in minor ways:
1. The "l2" secret key in tests/plugins/channeld_fakenet.c is updated.
2. The decompressed gossip data node id needs changing.
3. The coinmoves order changes in bookkeeper for anchors.
4. Various harcoded gossip constants change.
5. Some hardcoded makesecret results change.
6. zeroconf tests which hardcoded node ids change.
7. Arbitrary rune strings change.
8. A log message which uses node ids changes.
This commit only updates test files and test helpers to match a new default wallet-seed format. It does not change production code, does not fix a vulnerability, and has no direct security impact on running Core Lightning nodes.
c7973b8a · Jan 26, 2026 · 1 fileInformational 15pytest: make sure to use old_hsmsecret on downgrade tests.
We only support downgrade if you upgraded, so your hsm_secret will be old.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change only updates a test file so that downgrade tests create nodes using an older-format secret key file. It does not change any production code, network protocol, or wallet behavior, and there is no security issue in the commit itself.
ee0175b8 · Jan 20, 2026 · 7 filesInformational 18Makefile: update next and prev versions now we've released.
This means:
1. downgrade changes (we no longer fail due to node biases).
2. various deprecations no longer are
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a routine post-release maintenance commit for Core Lightning. It updates version numbers in the build files and test infrastructure after a new release, adjusts downgrade tests to reflect that downgrading past the new release no longer fails on a recently-added database feature, and removes some temporary test workarounds for APIs that are no longer considered deprecated. There is no direct security fix here; it is housekeeping that keeps the CI and downgrade tooling aligned with the current release cycle.
5fdc56c5 · Jan 14, 2026 · 3 filesLow 28wallet/hsmd: fix signmessagewithkey for BIP86 wallets
The signmessagewithkey RPC was failing for BIP86 (mnemonic-based)
wallets because:
1. The wallet RPC was iterating through BIP32-derived addresses only,
so it couldn't find BIP86-derived addresses.
2. The HSM's handle_bip137_sign_message always used bitcoin_key()
(BIP32 derivation) regardless of wallet type.
This commit fixes a bug where the `signmessagewithkey` RPC command did not work for newer BIP86-style wallets. Previously, the wallet RPC only searched through older BIP32-derived addresses, and the HSM signing code always used BIP32 key derivation. The fix makes both the wallet lookup and the HSM signing aware of BIP86 derivation, so users can sign messages with keys from BIP86 wallets. This is a functionality bug, not a clear security vulnerability, but it could have caused user confusion or application failures.
fa96b601 · Jan 14, 2026 · 1 fileInformational 23lightningd: use bip86 derivation for anchor spend change outputs
Why it was queuedThis small change updates how Core Lightning creates the 'change' output when spending an anchor output in a Lightning channel. It now uses a newer, Taproot-specific key derivation method (BIP86) when available, instead of the older BIP32 method. The change itself is a correctness/hardening improvement for Taproot key handling, not a fix for an active exploit or a clearly disclosed vulnerability.
9b85ce7b · Jan 14, 2026 · 1 fileModerate 62hsmd: fix derivation for non-taproot addresses in modern mnemonic (25.12+) nodes.
This is a fix from https://github.com/rauaap who correctly diagnosed the problem:
```
Error broadcasting transaction: error code: -26\nerror message\nmempool-script-verify-flag-failed (Script failed an OP_EQUALVERIFY operation), input 0 of ...
```
The decision to use the changed derivation for all addresses, not just
taproot, came up during review. Unfortunately, the signing code
(here) was not changed to match the address generation code (in the
wallet).
Reported-by: https://github.com/postanissue
Fixes: https://github.com/ElementsProject/lightning/issues/8804
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: lightningd: we now correctly sign for non-taproot addresses given by nodes created by v25.12 or newer.
This commit fixes a bug where Core Lightning nodes created with a modern mnemonic (version 25.12 or newer) could not correctly sign transactions that spend from non-Taproot on-chain addresses. The address generation code was updated to use a new key derivation method for all address types, but the signing code still only used that method for Taproot addresses. As a result, the private key used to sign did not match the public key in the address, causing transaction broadcast failures with an OP_EQUALVERIFY script error. The fix makes the signing code use the new derivation for all address types when the node uses the modern mnemonic format.
0269d0c0 · Jan 14, 2026 · 1 fileLow 34jsonrpc: fix recover command for BIP86 wallets
The recover command checks if a node has already issued bitcoin
addresses before allowing recovery. This check only looked at
bip32_max_index, but with BIP86 wallets, newaddr() increments
bip86_max_index instead.
Also, the recover test asserted on hex but now it's asserting on codex32 instead. We should probably go in and fix the end point. @rustyrussell what do you think?
This commit fixes the 'recover' command in Core Lightning so it correctly detects whether a wallet has already generated Bitcoin addresses. Previously, the check only looked at one counter used by older wallets, but a newer type of wallet (BIP86) uses a separate counter. As a result, a BIP86 wallet that had already issued addresses could wrongly be allowed to run recovery, which could overwrite or confuse wallet state. The fix adds the missing check.
bf43fbb7 · Jan 14, 2026 · 1 fileModerate 54lightningd: Fix penalty tx output derivation for BIP86 wallets
When using the new BIP39 mnemonic HSM secret format, the wallet uses
BIP86 derivation for taproot addresses. However, onchaind_tx_unsigned() was always using bip32_pubkey() to derive the final key for penalty transaction outputs.
This fix corrects how Core Lightning derives wallet addresses used in penalty transactions when a newer BIP39-style secret is in use. Previously, the code always used the older BIP32 derivation even when the wallet was configured for BIP86 (taproot) addresses. That mismatch could cause penalty transaction outputs to be sent to addresses the wallet does not recognize or cannot spend, potentially making recovered funds inaccessible after a channel breach.
4b1f2a07 · Jan 14, 2026 · 1 fileLow 42lightningd: use BIP86 derivation for P2TR in HTLC rebroadcast change outputs
Why it was queuedThis change fixes how Core Lightning derives the public key used for 'change' outputs when rebroadcasting on-chain HTLC (Hashed Time-Locked Contract) transactions that pay to a Taproot (P2TR) address. Previously, the code always used the older BIP32 derivation even when the wallet was configured for the newer BIP86 Taproot-specific derivation. Using the wrong derivation path could produce a change output that the wallet does not recognize or cannot spend later, potentially locking up funds. The patch checks whether BIP86 is available and uses it for P2TR change outputs, falling back to BIP32 otherwise.
c10c54ff · Jan 14, 2026 · 2 filesInformational 15pytest: don't record IO when we kill nodes
```
ERROR tests/test_connection.py::test_channel_persistence - json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
Similarly:
```
ERROR tests/test_opening.py::test_sendpsbt_crash - json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This change only adjusts two test cases so they no longer save plugin input/output logs before deliberately crashing a test node. It fixes flaky test failures where reading a partially-written JSON file produced a decode error. It does not change any production code or affect real users.
21d4f684 · Jan 8, 2026 · 1 fileInformational 19hsmd: check *all* anchor inputs for short sigs.
Anchors will have one input from the commitment tx, and at least on
more (in this case, 3 more); we were only checking the first one for
short signatures.
```
total_feerate_perkw = total_fees / total_weight * 1000
> check_feerate([l3, l2], total_feerate_perkw, feerate)
tests/test_closing.py:4064:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
nodes = [<fixtures.LightningNode object at 0x7f3e9a2c74f0>, <fixtures.LightningNode object at 0x7f3e991d5f30>]
actual_feerate = 14006.105538595726, expected_feerate = 14000
def check_feerate(nodes, actual_feerate, expected_feerate):
# Feerate can't be lower.
assert actual_feerate > expected_feerate - 2
if actual_feerate >= expected_feerate + 2:
if any([did_short_sig(n) for n in nodes]):
return
# Use assert as it shows the actual values on failure
> assert actual_feerate < expected_feerate + 2
E AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit fixes a test-only diagnostic check in Core Lightning's hardware signing daemon (HSM). The code warns developers if a Bitcoin signature is unusually short (a sign of 'overgrinding' during signature creation), but it only checked the first input of an anchor-spending transaction. Anchor transactions can have multiple inputs, so the check missed short signatures on the other inputs. This is a testing/quality fix, not a vulnerability that attackers can exploit.
fd21b329 · Jan 8, 2026 · 1 fileInformational 15pytest: fix test_bitcoin_backend_gianttx flake.
signpsbt could be the one which takes a long time, so allow any
psbt event.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a one-line change to a test file. It widens the expected log message pattern in a flaky test so that either 'fundpsbt' or 'signpsbt' slow operations are accepted, rather than only 'fundpsbt'. It does not change production code, user behavior, or security boundaries.