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 51 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.
ab9fd89a · Aug 4, 2026 · 1 fileInformational 11xpay: trim constraints: small optimization
Use a single realloc to remove old entries.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit is a small internal code cleanup in Core Lightning's payment routing plugin. It replaces a loop that removes old routing hints one-by-one with a single bulk removal. There is no indication this fixes a security bug or changes externally visible behavior.
b0a7a6a9 · Aug 4, 2026 · 8 filesInformational 19askrene: give clearer error codes.
Add PAY_INSUFFICIENT_FUNDS and PAY_ROUTE_NOT_FOUND, and give nice
detailed errors for those.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: JSON-RPC: `getroutes` can now return PAY_INSUFFICIENT_FUNDS (215) and PAY_DESTINATION_INSUFFICIENT_CAPACITY (220) error codes.
This commit improves the error messages returned by Core Lightning's routing plugin (askrene) when a payment cannot be routed. It adds two new, more specific error codes: one for 'not enough local funds' and one for 'destination cannot receive this amount.' There is no indication this fixes an active security vulnerability; it is a user-experience and diagnostics improvement.
0f144dc7 · Aug 4, 2026 · 1 fileInformational 15xpay: fakenet test: skip temporarily
channeld_fakenet sudbdaemon purposedly crafted for this test needs
updating to account for funds moving after every success payment.
I've tried to fix that but in doing so I also triggered an xpay bug not
related to this PR. Therefore, for the moment we skip this test.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit simply skips a single automated test in the project's test suite. It does not change any production code, network protocol handling, or wallet logic. The commit message explains the test is being disabled temporarily because a fake-network helper used only for testing needs updating, and the author encountered an unrelated bug while trying to fix it. There is no security-relevant change here.
dd652105 · Aug 4, 2026 · 1 fileLow 38libplugin: json_id: guard against weird prefixes
Following the recent enforcement of ids being printable strings
we put guards on "method" and "prefix" as well.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit tightens a safety check in Core Lightning's plugin library. When a plugin sends a JSON-RPC request, it builds an internal ID from a method name and a prefix. The code already replaced the method name with a safe placeholder if it contained unusual characters that would need escaping. Now it does the same for the prefix. If either field had weird characters, the generated ID could be escaped differently than expected, and the plugin might fail to match the reply to the right outgoing request. The patch is a small, defensive hardening change.
529ae2b7 · Aug 4, 2026 · 3 filesLow 34common: implement str_to_u64, make json_to_u64 use it.
The prior implementation could read past the end of the buffer (we actually
pad our JSON so this isn't harmful, but still). Fix up json_to_s64 and
json_to_double too, but since they're not used as often, just copy the
string there.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This commit fixes a bug in how Core Lightning parsed unsigned 64-bit integers from JSON. The old code used a standard C library function (strtoull) that could read beyond the intended token boundary. The commit author notes this is not currently harmful because JSON buffers are padded, but it is still a defensive fix. The commit also applies similar safer handling to signed 64-bit and double parsing.
395f99d7 · Aug 4, 2026 · 8 filesLow 27libplugins: JSON ids are always strings.
We used to handle it being a literal, but this was removed in
73fc9b0c2a162c98703baf618abf944c791bb879 (v25.05) so we don't need to handle that at all.
Not using the raw JSON means we handle weird methodnames by replacement: otherwise we would
not match the responses. Only an issue for commando, where the command would time out
rather than report "Unknown method".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit cleans up how Core Lightning plugins handle JSON-RPC request IDs. Previously, IDs could be passed around as raw JSON fragments (with quotes included), which caused mismatches when method names contained unusual characters. The fix forces IDs to be plain strings everywhere. The main user-visible effect mentioned by the author is that commando (a remote-command plugin) would previously time out instead of returning 'Unknown method' for certain weird method names. There is no direct evidence in the commit of a security vulnerability such as injection or remote code execution.
95769649 · Aug 4, 2026 · 18 filesInformational 17askrene: add APIs for "impressions" which are *relative* constraints.
Normal constraints are clamps on min/max caused by failed payments:
min for the channels that succeeded, max for the channel which failed.
Impressions are the results of successful payments, which alter both
min and max (negatively in the forward direction, positively in the
reverse).
impression: n
1. An effect, feeling, or image retained as a consequence of experience.
2. A vague notion, remembrance, or belief.
3. A mark produced on a surface by pressure.
Unlike constraints, this is the result of our own effect on the network: they're related
but different enough to get their own API and terminology.
The name conveys both we made an impression on the channel, and that
the results are a bit vague (due to other changes since then, which we
won't know about).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `askrene` layers now contain "impressions" representing the effects of successful payments we made through channels.
This commit adds a new 'impressions' feature to the askrene routing plugin in Core Lightning. It is a normal feature addition that lets the node remember how much capacity was used by successful payments, separate from existing 'constraints' that track failed payments. There is no indication this fixes a security bug or introduces a vulnerability.
e0f86c17 · Aug 4, 2026 · 3 filesInformational 18common: hoist amount+currency parsing into common code.
Currently used for offers, we will use it for repeatpay too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit moves existing code that parses payment amounts (Bitcoin millisatoshis, 'any' amount, or fiat currency amounts) from one plugin file into a shared library so it can be reused by a future feature. It is a code refactoring with no obvious security bug introduced or fixed. The parsing logic is essentially unchanged, just relocated and slightly tightened.
a70ae963 · Aug 4, 2026 · 8 filesInformational 17lightningd: internal cleanups since all non-command JSON IDs are strings.
In particular, "struct jsonrpc_request"'s id is always a string.
cmd->id isn't, though.
We can also remove the now-unused json_get_id.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a routine internal cleanup commit in Core Lightning. It removes an unused helper function and simplifies how JSON-RPC request IDs are stored and formatted, since the project now always uses string IDs for non-command JSON traffic. The changes are refactor-style and do not appear to fix a security bug.
4d926285 · Aug 4, 2026 · 1 fileInformational 23downgrade: we need to remove "impressions" from askrene datastore when downgrading to v26.06.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a database downgrade helper fix, not a live network vulnerability. Core Lightning's downgrade tool previously failed to strip out new 'channel impression' records when rolling a database back to version v26.06. The patch teaches the tool to remove those records during downgrade. If left unfixed, a downgrade could leave newer data in an older database format, which might cause errors or prevent the node from starting after rollback. There is no attacker-controlled path in normal operation.
42995326 · Aug 4, 2026 · 1 fileLow 31downgrade tool: fix invalid memory bug
Fix a typo in the downgrade tool that produced an OOM error.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a typo in a database downgrade helper tool. The bug caused the tool to pass a negative number (turned into a huge positive size) when copying data, which led to an out-of-memory (OOM) error. The fix swaps two variable names so the tool copies the already-processed chunk of data instead of the remaining chunk. It is a reliability bug in an offline maintenance tool, not a network-exploitable vulnerability.
0b67601f · Aug 4, 2026 · 2 filesInformational 15xpay: tests should expect the new error messages
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit only updates test files so that automated checks expect slightly different error wording from the xpay payment command. It does not change any production code, so it cannot introduce a security vulnerability or fix one on its own.
76396dd4 · Aug 4, 2026 · 1 fileInformational 17askrene: explain failure: add known enabled case
Consider the case in which payment fails due to not enough "known enabled"
liquidity. Notice that we cover the "known" and "enabled" cases already.
But:
known_enabled <= enabled
and
known_enabled <= known
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit improves an internal diagnostic message inside Core Lightning's payment routing plugin (askrene). It adds a new explanation category called 'known_usable' so that when a payment fails, the software can more precisely report that the failure was due to insufficient usable liquidity that is both known to the node and currently enabled. There is no indication this fixes a security vulnerability; it is a correctness/usability improvement to failure reporting.
3700f4b8 · Aug 4, 2026 · 2 filesInformational 15common: add helper to remove a range of elements
from a tal array.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit adds a new internal helper function for removing a contiguous block of items from a memory array. It is a straightforward utility addition with no bug fix, no change to existing behavior, and no security relevance visible in the commit itself.
2a3feb7e · Aug 4, 2026 · 1 fileLow 32askrene: safer iterating over changing htable
on trim_constraints:
to be sure we don't miss elements we add to the hash table after the
loop and not during iteration.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This change fixes a subtle bug in Core Lightning's askrene plugin where adding items back into a hash table while looping through it could cause some items to be skipped. The fix collects items that need to be re-added and inserts them only after the loop finishes. The main risk is that the old code could leave stale routing constraints in place, potentially affecting payment routing decisions rather than directly stealing funds.
e13df371 · Aug 4, 2026 · 2 filesLow 42multiwithdraw: use unique ids on requests.
Shades of `efacada7ddf` which did the same thing in multifundchannel:
(ab)used the id, which being a string, gave and id of 34 (").
Also clean up the leftover assert in multifundchannel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This patch fixes a bug in the multiwithdraw plugin where it reused the JSON-RPC command ID as its own internal request identifier. Because command IDs can be arbitrary strings (for example, a double-quote character becomes the number 34), using them directly as numeric IDs could cause collisions or confusion when tracking multiple in-flight withdrawal requests. The fix introduces a private global counter so each multiwithdraw request gets a unique numeric ID, matching an earlier fix made to the multifundchannel plugin. The patch also removes a leftover debug assertion in multifundchannel.
52fd6ae4 · Aug 4, 2026 · 1 fileInformational 15askrene: test explain: fix flake
Fix test_explain_source_dest_failure by increasing the amounts by a
factor of ten, which reduces the relative significance of on-chain fees
on the commitment transaction.
This used to fail on liquid-regtest due to insufficient liquidity on
l2->l4 to prevent channel starvation.
At line
```
l1.rpc.xpay(l4.rpc.invoice('30000sat', 'test_explain_simple_failures2', 'test_explain_simple_failures2')['bolt11'])
```
we would get
```
lightningd-2 2026-07-06T11:29:09.973Z DEBUG 02287bfac8b99b35477ebe9334eede1e32b189e24644eb701c079614712331cec0-channeld-chan#3: Adding HTLC would leave us only 19454000msat: we need 25281sat for another HTLC if fees increase from 7500perkw to 13906perkw
lightningd-2 2026-07-06T11:29:09.973Z DEBUG 02287bfac8b99b35477ebe9334eede1e32b189e24644eb701c079614712331cec0-channeld-chan#3: Adding HTLC 0 amount=30000000msat cltv=130 gave CHANNEL_ERR_CHANNEL_CAPACITY_EXCEEDED
```
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit only changes a test file. It makes the test channels and payment amounts ten times larger so that small on-chain fee variations no longer cause the test to fail on liquid-regtest. There is no change to production code, no user-facing behavior change, and no security fix.
81425f17 · Aug 4, 2026 · 3 filesModerate 60lightningd: don't crash when truncating large log messages
It's not okay to call free() on the pointer to a truncated log message
that was allocated by tal_fmt() in cap_header(). Let's call tal_free()
instead, and rather than calling vasprintf() to malloc the log message in
the first place, let's call tal_vfmt().
Also, since we're now always using a tallocated string for the log message,
let's have cap_header() take ownership of it and either free it if it
truncated the message (and is returning a different pointer to the truncated
message) or else return the taken original pointer without freeing it.
Also, log_io()'s str and data parameters are marked TAKES, but the function
was not actually taking them, so fix that up too.
Also, don't call strlen() on a string returned by tal_fmt(). The returned
pointer is guaranteed to have tal_count() == strlen() + 1, so there's no
sense in scanning through the string to find its length.
Suggested-by: Lagrang3 <lagrang3@protonmail.com>
See: https://github.com/ElementsProject/lightning/pull/9331#discussion_r3628600315
Changelog-Fixed: log: don't crash when truncating large log messages
This commit fixes a crash bug in Core Lightning's logging code. When a log message was very long and got truncated, the program accidentally used the standard free() on memory that had been allocated by the project's own tal allocation system, causing a crash. The patch switches everything to use tal consistently, marks some function parameters as 'taken' so ownership is clear, and removes a failing-test marker because the bug is now fixed.
a9b43851 · Aug 4, 2026 · 1 fileModerate 62lightningd: test for very long log entries
We were using vasprintf to generate the log line and then using free to
deallocate the string. However, in the case of a very long log line
a new pointer was created with tal_fmt and then tried to use free on it.
This was introduced in commit: 4d8f923a9a1468b8987dbb48e8fc988747f8c62f
```
free(): invalid pointer
lightningd: FATAL SIGNAL 6 (version v26.06-21-gebc5dc2)
0x563dab20be43 send_backtrace
common/daemon.c:38
0x563dab20becd crashdump
common/daemon.c:83
0x7f0cf0c96def ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f0cf0ceb95c __pthread_kill_implementation
./nptl/pthread_kill.c:44
0x7f0cf0c96cc1 __GI_raise
../sysdeps/posix/raise.c:26
0x7f0cf0c7f4ab __GI_abort
./stdlib/abort.c:77
0x7f0cf0c80290 __libc_message_impl
../sysdeps/posix/libc_fatal.c:134
0x7f0cf0cf5464 malloc_printerr
./malloc/malloc.c:5832
0x7f0cf0cfa41b _int_free_check
./malloc/malloc.c:4560
0x7f0cf0cfa41b _int_free
./malloc/malloc.c:4692
0x7f0cf0cfa41b __GI___libc_free
./malloc/malloc.c:3476
0x563dab19be60 logv
lightningd/log.c:688
0x563dab19c0bc log_
lightningd/log.c:728
0x563dab1c1047 plugin_log_handle
lightningd/plugin.c:530
0x563dab1c5801 plugin_notification_handle
lightningd/plugin.c:609
0x563dab1c5a9a plugin_read_json
lightningd/plugin.c:753
0x563dab2388a5 next_plan
ccan/ccan/io/io.c:60
0x563dab238c83 do_plan
ccan/ccan/io/io.c:422
0x563dab238d3c io_ready
ccan/ccan/io/io.c:439
0x563dab239e5b io_loop
ccan/ccan/io/poll.c:470
0x563dab194399 io_loop_with_timers
lightningd/io_loop_with_timers.c:22
0x563dab199c29 main
lightningd/lightningd.c:1480
0x7f0cf0c80ca7 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f0cf0c80d64 __libc_start_main_impl
../csu/libc-start.c:360
0x563dab169020 ???
_start+0x20:0
0xffffffffffffffff ???
???:0
```
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit adds a test that reveals Core Lightning can crash when a plugin produces an extremely long log message. The crash happens because the logging code sometimes allocates memory using one method but tries to free it with another, leading to an invalid-pointer error and an abort. The commit only adds the failing test; it does not include the actual fix, so the vulnerability remains unpatched in this commit.
31d08fb5 · Aug 3, 2026 · 1 fileTriage 0pytest: deterministic test for lockin of a non-latest mined RBF inflight
test_rbf_non_last_mined occasionally fails in CI when the peer
reconnects while the node is still catching up on blocks (#9373).
Reproduce that window deterministically: stall the fetch of the
block after the funding block via the bitcoind proxy, so the node
has seen the funding confirm but cannot finish catching up, then
reconnect. Without the previous commit, this locks in the
never-mined latest inflight on every run.
90b58e81 · Aug 3, 2026 · 1 fileTriage 0lightningd: lock in the mined RBF inflight, not the latest one
When a block containing a non-tip inflight's funding tx was
processed, dual_funding_found set the channel's scid right away, but
the channel's funding fields were only updated to the mined inflight
once block catch-up completed (opening_depth_cb, via the blockdepth
watches). A peer reconnecting inside that window reestablished
against channel_current_inflight() -- the latest inflight -- with the
scid already set, so dualopend sent channel_ready and the channel
locked in a funding tx that was never mined: its last_tx spends a
nonexistent outpoint, and the two peers disagree about the channel's
funding.
Record the mined inflight on the channel as soon as its block is
seen, and make peer_restart_dualopend reestablish with the inflight
matching the recorded funding when the scid is already set.
Fixes: #9373
Changelog-Fixed: Protocol: dual-funding: reconnecting during block catch-up could lock in a channel with the latest RBF candidate rather than the one that was actually mined.
8c42be35 · Aug 3, 2026 · 1 fileInformational 12tests: add regression test for hsmtool commands with passphrase
Why it was queuedThis commit only adds and updates a regression test in the project's test suite. It checks that the hsmtool utility correctly handles both empty and non-empty passphrases when working with BIP39 mnemonic-based wallet secrets. There is no change to the actual hsmtool or wallet code, so it does not introduce or fix a live security vulnerability on its own.
8480f6c2 · Aug 3, 2026 · 1 fileLow 25lightning-hsmtool: Fix getsecret does not show mnemonic after typing passphrase
Changelog-Fixed: `lightning-hsmtool`: `getsecret` does not show mnemonic after typing passphrase
This is a bug fix in a command-line helper tool used by Core Lightning node operators. The `getsecret` command was accidentally refusing to show the wallet recovery words (mnemonic) when the wallet was protected by a passphrase. After the fix, users who correctly type their passphrase can see their mnemonic again. There is no attacker-controlled path; it is a usability/availability issue for legitimate owners, not a security vulnerability that lets someone steal funds.
2e5bc4fc · Aug 3, 2026 · 2 filesInformational 17lightningd: update graceful notifications when HTLC states change
The graceful command notifies watchers about the closest-expiry HTLC,
including its state, whenever that message changes. But nothing
re-evaluated the message when an HTLC changed state: only HTLC
removal, peer disconnect and another graceful invocation re-ran the
check. If graceful was invoked while a commitment dance was in
flight, the initial notification named a transient state (e.g.
RCVD_ADD_REVOCATION) and no follow-up ever announced the settled
state.
test_graceful_htlc waits for exactly that follow-up (since 6994681ae
"flake: Fix test_graceful_htlc to be flexible for notifs"), so it
times out whenever graceful catches the dance mid-flight, which
valgrind CI runs make likely. In one CI failure graceful caught the
outgoing HTLC in RCVD_ADD_REVOCATION, the dance completed 600ms
later, and no notification followed for the remaining 180 seconds.
Re-check graceful progress in the handlers that advance HTLC states
(peer_sending_commitsig, peer_got_commitsig, peer_got_revoke). The
check is a no-op unless a graceful command is outstanding, and
identical messages are already deduplicated.
The dance now generates transient-state notifications, so rewrite the
test to match expected notifications as an ordered subsequence
instead of by exact index. That also removes two accidents the old
indexing depended on: the RCVD_ADD_REVOCATION special case (the
settled state now always notifies), and the wait for a notification
after l1's disconnect, which was really satisfied by the graceful(1)
call's own initial notification arriving on the shared rpc socket --
the disconnect itself never notifies, since the message text
describes the still-connected peer l3 and does not change.
Fixes: https://github.com/ElementsProject/lightning/issues/9219
Changelog-Fixed: JSON-RPC: `graceful` notifications now update when a pending HTLC changes state.
This commit fixes a notification bug in Core Lightning's `graceful` JSON-RPC command. The `graceful` command tells users about the next pending payment (HTLC) that is closest to expiring, including its current state. Previously, if a user ran `graceful` while a channel update was in progress, the notification could show a temporary state (like RCVD_ADD_REVOCATION) and never update again when the HTLC reached its final settled state. The fix re-checks and sends updated notifications whenever HTLC states advance during the normal commitment dance. There is no security vulnerability here; it is a correctness and test-flakiness fix for user-facing status notifications.
1e871ffd · Aug 3, 2026 · 1 fileInformational 15xpay: add traces for payments
Produce traces (see common/trace.h) for every payment in order to gather
statistics about the duration of a full payment execution.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit adds diagnostic tracing to the xpay plugin so developers can measure how long payments take. It does not change payment behavior, network handling, or access controls. There is no security issue visible in the change.