CommitWatch RSS
EP
← All projectsElements Project

Core Lightning

Modular C implementation of the Lightning Network protocol and node stack.

BitcoinLightning NetworkNormal
Source repository ↗
Repository coverage

1856 commits in the local evidence base

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.

158security candidates263second-pass queue1853AI analyses
140commits · 30 days
227commits · 60 days
803commits · 180 days
1839commits · 365 days
Backfill bands
Aug 5 → Feb 61049 seen37 candidatesComplete
Feb 6 → Jun 6579 seen10 candidatesComplete
Jun 6 → Jul 678 seen1 candidatesComplete
Jul 6 → Aug 5147 seen16 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

70/100 average clarity
432Strong · 80–100
1164Adequate · 60–79
231Thin · 40–59
29Opaque · 0–39
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
dovgopoly15015164
Rusty Russell95873958072
Sangbida Chaudhuri14731146066
Dusty Daemon771377066
ShahanaFarooqui931093063
daywalker9090589062
Níckolas Goline40540076
Lagrang376476069
Christian Decker36436072
Vincenzo Palazzo838080
Chandra Pratap56256082
ekzyis222063
Analysis record

Published AI watches

Last scanned 50 minutes ago

Informational 15 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

Revert "doc: require Homebrew GNU make and gpatch on macOS"

This commit is a simple documentation revert. It undoes a previous change that told macOS users to install GNU make and GNU patch from Homebrew and to put those tools first in their command path. The reverted instructions now omit gpatch a…

0cfa949fby Sangbida Chaudhuri+4−81 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 75 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

Revert "tests: drop obsolete x-prefix in compacter-slow.sh"

This commit re-adds an old-style 'x' prefix to a string comparison in a test helper script. It is a test-only change with no effect on the actual Core Lightning node software, user funds, network behavior, or security. The change simply re…

116fd7cdby Sangbida Chaudhuri+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

doc: require Homebrew GNU make and gpatch on macOS

This commit only updates macOS installation instructions in the documentation. It tells macOS users to install newer GNU versions of 'make' and 'patch' from Homebrew because Apple's built-in tools are too old for building and running sourc…

d3ff1474by Sangbida Chaudhuri+8−41 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: drop obsolete x-prefix in compacter-slow.sh

This commit is a trivial shell script cleanup. It removes an old-fashioned 'x' prefix from a string comparison in a test helper script so that a newer version of the Shellcheck linter stops warning about it. The change does not alter progr…

474c272aby Sangbida Chaudhuri+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

common: hoist amount+currency parsing into common code.

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 n…

Refactoring of amount-parsing code into a shared helperAddition of explicit u64 overflow guards (mul_overflows_u64, add_overflows_u64) in the new common codeNo change to wire protocol or RPC interface semantics
e0f86c17by Rusty Russell+112−723 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: internal cleanups since all non-command JSON IDs are strings.

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. …

No security-relevant keywords in commit title or messageNo CVE, advisory, or bug reference presentChanges are refactor/cleanup in nature
a70ae963by Rusty Russell+25−378 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

common: hoist hash_str helper into its own header.

This commit is a routine code cleanup: it moves a small string-hashing helper function into a shared header file so it can be reused without being copied and pasted. There is no change to behavior, no bug fix, and no security relevance.

581bbb1fby Rusty Russell+16−176 files
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

downgrade: we need to remove "impressions" from askrene datastore when downgrading to v26.06.

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 th…

Database downgrade path could leave incompatible records in older schemaOffline tool only; no remote or on-chain triggerFix prevents potential node startup failure after version rollback
4d926285by Rusty Russell+43−111 file
No security note in commit
Open full analysis →Source commit ↗
Low 31 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

downgrade tool: fix invalid memory bug

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 nam…

Integer underflow / negative-to-size_t wrap leading to excessive allocationOut-of-memory crash in maintenance toolMemory corruption potential if allocation somehow succeeded
42995326by Lagrang3+8−81 file
No security note in commit
Open full analysis →Source commit ↗
Informational 24 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

xpay: actually tell askrene when a payment succeeded.

This commit fixes a bookkeeping bug in Core Lightning's xpay plugin. Previously, when a payment succeeded, xpay did not tell the askrene routing-helper that the route worked. As a result, askrene kept stale or overly pessimistic ideas abou…

Missing success feedback to routing layer can degrade payment reliabilityStale negative impressions may bias future path selection toward worse or failing routesNo direct funds-loss primitive is introduced or fixed
a66fabd4by Rusty Russell+40−02 files
No security note in commit
Open full analysis →Source commit ↗
Low 49 AI analysisMessage 58 · Thin
EP Elements ProjectCore Lightning BitcoinLightning Network

askrene: correctly order constraints.

This commit fixes a bug in Core Lightning's routing helper (askrene) where two kinds of channel information—hard limits called 'constraints' and usage estimates called 'impressions'—were being applied in the wrong order. Because impression…

Routing decision bug caused by incorrect ordering of time-relative channel statePotential payment failure or acceptance of an over-capacity routeRegression test added demonstrating incorrect route acceptance before fix
4b6fe4a1by Rusty Russell+211−1182 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

askrene: don't leak channel intel entries

This commit fixes a memory leak in the askrene plugin of Core Lightning. When individual channel intelligence entries were deleted, the code removed the entry from its array but forgot to free two internal pointers (impression and constrai…

Memory leak in plugin data structure cleanupMissing deallocation of nested pointers before array removalFix located in routing/intelligence plugin (askrene)
8891f414by Lagrang3+5−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 70 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

xpay: tests should expect the new error messages

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 o…

0b67601fby Lagrang3+24−32 files
No security note in commit
Open full analysis →Source commit ↗
Low 43 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

offers: limit invoices to 10 minutes for recurring offers in other currencies.

This change tightens the lifetime of recurring invoices priced in foreign currencies (like USD) to 10 minutes by default, and refreshes them with current exchange rates when they expire. Previously, such invoices could remain valid for the…

Fixes stale exchange-rate exposure for currency-denominated recurring invoicesAdds configurable expiry cap for recurring currency invoicesDistinguishes user-cancellation (0s expiry) from natural expiry to avoid misleading errors
446312cfby Rusty Russell+134−148 files
No security note in commit
Open full analysis →Source commit ↗
Low 45 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

offers: limit expiry to offer limit, or 10 minutes with currency conversion.

This commit tightens the expiration time on invoices created from BOLT12 offers. Previously, all such invoices defaulted to a 2-hour payment window. Now, if the offer has an absolute expiry, the invoice expires when the offer expires; and …

BOLT12 invoice expiry now bounded by offer absolute expiryCurrency-converted invoices use short expiry to limit exchange-rate exposureNew regression test added for expiry behavior
a6cf4915by Rusty Russell+55−22 files
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

fetchinvoice: don't bother with checking recurrence timing.

This commit removes local timing checks in Core Lightning's fetchinvoice plugin for recurring payments. Instead of the plugin refusing too-early or too-late invoice requests, it now lets the remote node decide and report back. The change i…

Removal of local input-validation checks for recurring invoice requestsReliance on remote-party enforcement for recurrence period limits and pay windowsTest expectations changed from local rejection to remote failure messages
3e49d908by Rusty Russell+2−682 files
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: don't do previous invoice checking in createinvoicerequest.

This commit removes a local sanity check in Core Lightning's experimental 'createinvoicerequest' command. Previously, when creating a recurring invoice request, the code looked up past payments by label to verify the previous recurrence wa…

Removal of local payment-state validation for recurring invoice requestsParameter rename from recurrence_label to label in internal RPC callsTest expectations changed from local 'previous invoice has not been paid' errors to remote failure messages
4348d8acby Rusty Russell+5−1224 files
No security note in commit
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

fetchinvoice: handle weird labels in recurrence_label parameter.

This commit fixes how the fetchinvoice plugin handles user-supplied labels that contain special characters such as backslashes, quotes, tabs, and newlines. Previously these labels were passed as raw strings, which could cause JSON encoding…

JSON injection / improper escaping of user-controlled input passed between RPC componentsPotential mismatch between label parsing and label serialization leading to functional failures or unexpected behaviorFix is narrowly scoped to a single plugin and parameter
d7f87f2dby Rusty Russell+37−102 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 70 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

Add unit tests for str_to_u64

This commit only adds a new automated test file that checks how a helper function (str_to_u64) converts text strings to unsigned 64-bit integers. It does not change any production code, so it cannot by itself introduce a security vulnerabi…

dddb455dby Lagrang3+203−01 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 78 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

pytest: add tests for what we want askrene to do.

This commit only adds a new pytest test file. It does not change any production code. The test describes desired future behavior for the askrene routing module's error messages when a payment source or destination lacks enough channel capa…

518620aeby Rusty Russell+67−01 file
No security note in commit
Open full analysis →Source commit ↗
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Lower-prioritylightningd: optimize find_cmd.by Rusty Russell · 98bd95cb · Nov 20, 2025 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Rusty Russell

lightningd: optimize find_cmd.

We have a reasonable number of commands now, and we *already* keep a
strmap for the usage strings. So simply keep the usage and the command
in the map, and skip the array.

tests/test_coinmoves.py::test_generate_coinmoves (2,000,000, sqlite3):
Time (from start to end of l2 node): 95 seconds (was 102)
Worst latency: 4.5 seconds

tests/test_coinmoves.py::test_generate_coinmoves (2,000,000, Postgres):
Time (from start to end of l2 node): 231 seconds
Worst latency: 4.8 seconds

Note the values compare against 25.09.2 (Postgres):

sqlite3:
Time (from start to end of l2 node): 403 seconds

Postgres:
Time (from start to end of l2 node): 671 seconds

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100

This is a routine performance optimization. It replaces a linear scan through a list of JSON-RPC commands with a hash map lookup, making command lookups faster when there are many commands. There is no security-relevant change here.

AI review queuedlightningd: avoid race when runtime-added plugins register hooks.by Rusty Russell · a4f772ef · Nov 20, 2025 · 8 filesMessage 73 · AdequateModerate 61Details
Commit message · Rusty Russell

lightningd: avoid race when runtime-added plugins register hooks.

If we add a new hook, not at the end, while hooks are getting called,
then iteration could be messed up (e.g. calling a plugin twice, or
skipping one).

The simplest thing is to defer updates until nobody is calling the
hook. In theory this could livelock, in practice it won't.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Moderate 61/100

This patch fixes a race condition in Core Lightning's plugin hook system. If a plugin was added or removed while a hook (like the one that decides whether to accept a payment) was actively being called, the internal list of plugins could be modified mid-iteration. That could cause a plugin to be called twice or skipped entirely, potentially leading to incorrect payment handling or other unexpected behavior. The fix defers updates to the hook list until all current callers are finished.

AI review queuedlightningd: support "filters" in plugins manifest to restrict when hooks are called.by Rusty Russell · d76a9050 · Nov 20, 2025 · 7 filesMessage 73 · AdequateLow 30Details
Commit message · Rusty Russell

lightningd: support "filters" in plugins manifest to restrict when hooks are called.

We're going to use this on the "rpc_command" hook, to allow xpay to specify that it
only wants to be called on "pay" commands.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 30/100

This commit adds a new plugin feature called 'filters' that lets plugin authors tell Core Lightning to only call their plugin's hook under certain conditions. For example, a plugin can now say 'only call me for pay commands' on the rpc_command hook. The change is a feature addition, not a bug fix, and there is no direct evidence in the commit that it addresses a security vulnerability.

Lower-prioritypyln-client: support hook filters.by Rusty Russell · 81f0d054 · Nov 20, 2025 · 1 fileMessage 68 · AdequateInformational 19Details
Commit message · Rusty Russell

pyln-client: support hook filters.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: pyln-client: optional filters can be given when hooks are registered (for supported hooks)

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 19/100

This is a small feature addition to the Python plugin client library for Core Lightning. It lets plugin authors optionally specify 'filters' when registering hooks, and passes those filters along to the lightningd daemon during plugin registration. There is no indication of a security bug or fix in the change itself.

Lower-prioritylightningd: fix race with mutual connect.by Rusty Russell · 55d622bd · Nov 19, 2025 · 1 fileMessage 68 · AdequateLow 33Details
Commit message · Rusty Russell

lightningd: fix race with mutual connect.

65dccea5bde4 "pytest: fix flake in test_reconnect_signed" accidentally
introduced a bug, where the connect command may not return.

If we call "connect" while a connection is still being processed
through the peer_connected hooks, we would call peer_channels_cleanup(),
which (if the peer has no channels) would free the peer.

Then when the peer_connected hook returned, it would lookup the peer,
see it was gone, and silently return. The connect_succeeded() function
was never called, and the connect command never woken.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None: bug introduced this release.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 33/100

This is a bug fix for a race condition in Core Lightning's peer connection handling. If a user or automated process called the 'connect' command while a peer connection was still being finalized through internal hooks, the connection command could hang forever and never return a response. The fix ensures the command waits properly during the 'connecting' state instead of cleaning up the peer prematurely. There is no direct evidence this was exploited as a security vulnerability; it appears to be a reliability bug.

Lower-priorityconnectd: don't complain if lightningd is unresponsive while doing dev-memleak.by Rusty Russell · 79e60946 · Nov 19, 2025 · 4 filesMessage 73 · AdequateInformational 18Details
Commit message · Rusty Russell

connectd: don't complain if lightningd is unresponsive while doing dev-memleak.

We had a flake of form:

```
2025-11-18T04:42:23.489Z **BROKEN** 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-connectd: wake delay for WIRE_CHANNEL_REESTABLISH: 6789msec
```

Which happened as we're shutting down. Some investigation revealed
the cause: `dev-memleak` can be extremely slow. Fair enough.

So we change `dev-memleak` to call connectd first, and connectd uses
that as a trigger to stop complaining about delays.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 18/100

This is a developer-only fix for a flaky test. The `dev-memleak` diagnostic tool can take so long that another component (connectd) thought the main daemon had hung, logging a scary but harmless 'BROKEN' message that broke automated tests. The patch makes connectd suppress that complaint while `dev-memleak` is running. It is not a security vulnerability fix and does not change normal node behavior.

Lower-prioritypytest: fix flake when htlc_timeout_tx gets short sig:by Rusty Russell · 989d59f7 · Nov 19, 2025 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell

pytest: fix flake when htlc_timeout_tx gets short sig:

```
check_channel_moves(l1, expected_channel1)
> check_chain_moves(l1, expected_chain1)

tests/test_coinmoves.py:942:
...
'account_id': 'wallet',
'blockheight': 115,
'created_index': 15,
- 'credit_msat': Decimal('6358000.00000000'),
- 'debit_msat': 0,
? --
+ 'credit_msat': 6366000,
? +++ ++++++
+ 'debit_msat': 0,
'extra_tags': [],
- 'output_msat': Decimal('6358000.00000000'),
+ 'output_msat': 6366000,
'primary_tag': 'deposit',
'utxo': '4a16b7aceac233ed68bed0f18adfc1ab338b5fc55b696d1376eea173adeac8e3:1',
},
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit fixes a flaky test in Core Lightning's accounting test suite. The test sometimes failed because the amount of 'change' returned from a specific Bitcoin transaction could vary slightly depending on the signature length. The fix makes the test read the actual transaction output value from the blockchain instead of hardcoding an expected value. There is no security issue here—only a test reliability improvement.

Lower-prioritypytest: fix flake in test_connect_ratelimitby Rusty Russell · 9d803cae · Nov 19, 2025 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Rusty Russell

pytest: fix flake in test_connect_ratelimit

Delay can cause bogus complaints:

```
2025-11-13T23:50:03.6643632Z lightningd-3 2025-11-13T23:37:29.947Z **BROKEN** 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: wake delay for WIRE_CHANNEL_REESTABLISH: 5708msec
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100

This commit fixes a flaky test in the project's automated test suite. The test sometimes failed because it intentionally paused nodes during reconnection, which could cause harmless timing warnings in the logs. The fix tells the test framework to ignore those specific warnings instead of treating them as test failures. There is no security issue here.

Security candidatelightningd: another gossip transition corner case.by Rusty Russell · 215294bc · Nov 19, 2025 · 1 fileMessage 81 · StrongInformational 19Details
Commit message · Rusty Russell

lightningd: another gossip transition corner case.

If we see a close tx at the same time we see the channel reach announce depth (here, 104x1x0 confirms
and we process blocks 109 and 110), we see it go from:

CGOSSIP_WAITING_FOR_ANNOUNCE_DEPTH->CGOSSIP_CHANNEL_UNANNOUNCED_DYING (Channel closing before 6 confirms)

Then:
CGOSSIP_CHANNEL_UNANNOUNCED_DYING->CGOSSIP_CHANNEL_ANNOUNCED_DEAD

```
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: State changed from CHANNELD_NORMAL to CHANNELD_SHUTTING_DOWN
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: gossip state: CGOSSIP_WAITING_FOR_ANNOUNCE_DEPTH->CGOSSIP_CHANNEL_UNANNOUNCED_DYING (Channel closing before 6 confirms)
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: billboard: Channel ready for use. They've sent shutdown, waiting for ours
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: Trying commit
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: Can't send commit: nothing to send, feechange not wanted ({ RCVD_ADD_ACK_REVOCATION:3755 }) blockheight not wanted ({ RCVD_ADD_ACK_REVOCATION:109 })
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: peer_out WIRE_SHUTDOWN
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: billboard: Channel ready for use. Shutdown messages exchanged.
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: pid 35692, msgfd 86
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-channeld-chan#2: Status closed, but not exited. Killing
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: State changed from CHANNELD_SHUTTING_DOWN to CLOSINGD_SIGEXCHANGE
DEBUG hsmd: new_client: 2
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: Expected closing weight = 772, fee 2895sat (min 1447sat, max 1006268sat)
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: out = 506268sat/500000sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: dustlimit = 546sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: fee = 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: fee negotiation step = 50%
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: billboard perm: Negotiating closing fee between 1447sat and 1006268sat satoshi (ideal 2895sat) using step 50%
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: billboard: Waiting for their initial closing fee offer
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: peer_in WIRE_CLOSING_SIGNED
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: Making close tx at = 506268sat/500000sat fee 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: Received fee offer 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: ...offer is reasonable
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Their actual closing tx fee is 2895sat vs previous 4220sat: weight is 772
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: performing quickclose in range 1447sat-8492sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: Making close tx at = 506268sat/500000sat fee 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-hsmd: Got WIRE_HSMD_SIGN_MUTUAL_CLOSE_TX
DEBUG hsmd: Client: Received message 21 from client
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: sending fee offer 2895sat
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: peer_out WIRE_CLOSING_SIGNED
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-closingd-chan#2: billboard perm: We agreed on a closing fee of 2895 satoshi for tx:7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: State changed from CLOSINGD_SIGEXCHANGE to CLOSINGD_COMPLETE
DEBUG wallet: Owning output 1 506268sat (p2tr) txid 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: We have 1 anchor points to use
DEBUG lightningd: Broadcasting txid 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce
DEBUG lightningd: sendrawtransaction: 020000000001016f50e5481abf2482ed719dde6014cf9da9b3076fe12af7c8bbccfb705150ffbe0000000000ffffffff02d195070000000000225120eed745804da9784cc203f563efa99ffa54fdf01b137bc964e63c3124070ffbe69cb90700000000002251208a73bb281433f2b5db5461c6778aa2afd28e011de6bd04799a5991662c61d7a80400473044022015af4ffc277e44ab701507e017194b1e3ab8598397efab02c59dbe72340790b50220762065e91ce0a2c73f36fdf3a4d54732ef91d075c0887cfb28580220e081e81a01473044022050730b9d051a3fdecb368750ecbd558d625a1acaa42e59586c7187407319dda402202f2f6e099b2e092698fe528260e2b56be8de325bc985a17945c724514fb65b9c014752210259b3cb48220dc2016f4d320bb8105cc2c92bd8c79fc25c2ad96f37b496e491c62103bbee60c395056b8a1201e06ed79e2914c11a61d7b1aa781846468d02489dba6952ae00000000
DEBUG lightningd: Adding block 108: 4e6ba3059c6890797a29acd306e82d6f4e85ad62a6aa6d0ee5bc6ead3e6329cd
DEBUG hsmd: Client: Received message 5 from client
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-connectd: peer_downgrade
DEBUG plugin-bcli: sendrawtx exit 0 (bitcoin-cli -regtest -datadir=/tmp/ltests-laf51vlg/test_buy_liquidity_ad_check_bookkeeping_1/lightning-2/ -rpcclienttimeout=60 -rpcport=41847 -rpcuser=... -stdinrpcpass sendrawtransaction 020000000001016f50e5481abf2482ed719dde6014cf9da9b3076fe12af7c8bbccfb705150ffbe0000000000ffffffff02d195070000000000225120eed745804da9784cc203f563efa99ffa54fdf01b137bc964e63c3124070ffbe69cb90700000000002251208a73bb281433f2b5db5461c6778aa2afd28e011de6bd04799a5991662c61d7a80400473044022015af4ffc277e44ab701507e017194b1e3ab8598397efab02c59dbe72340790b50220762065e91ce0a2c73f36fdf3a4d54732ef91d075c0887cfb28580220e081e81a01473044022050730b9d051a3fdecb368750ecbd558d625a1acaa42e59586c7187407319dda402202f2f6e099b2e092698fe528260e2b56be8de325bc985a17945c724514fb65b9c014752210259b3cb48220dc2016f4d320bb8105cc2c92bd8c79fc25c2ad96f37b496e491c62103bbee60c395056b8a1201e06ed79e2914c11a61d7b1aa781846468d02489dba6952ae00000000)
DEBUG lightningd: Adding block 109: 540a47d6b316aec8d1b56efca22ffb384403659e3b29cddd3d68f87df72065a6
DEBUG lightningd: Adding block 110: 1931e9ea62324d0fb50188df525e84ee7021e1910cf3534b343db05cc4639851
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Got UTXO spend for beff505170fbccbbc8f72ae16f07b3a99dcf1460de9d71ed8224bf1a48e5506f:0: 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce
UNUSUAL 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Peer permanent failure in CLOSINGD_COMPLETE: Funding transaction spent: onchain txid 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce (reason=unknown)
UNUSUAL 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Not dropping our unilateral close onchain since we already saw 7685256e6e4632bd601f42bb85b6f22b7a0db8d55c468dfbb1703c3ab2e4d9ce confirm.
INFO 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: State changed from CLOSINGD_COMPLETE to FUNDING_SPEND_SEEN
**BROKEN** 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-chan#2: Illegal gossip state transition: CGOSSIP_CHANNEL_UNANNOUNCED_DYING->CGOSSIP_CHANNEL_ANNOUNCED_DEAD
DEBUG 0266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c03518-onchaind-chan#2: pid 35721, msgfd 86
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
update trust
AI analysis · Informational 19/100

This commit fixes a rare internal state-machine error in Core Lightning that could occur when a channel was closing at exactly the same moment it would normally be announced to the network. Previously, the code did not allow the transition from 'unannounced and dying' directly to 'announced and dead,' causing a 'BROKEN' log error. The patch simply adds that missing allowed transition. It is a bug fix for a corner case, not a security vulnerability that an attacker can exploit.

Security candidatelightningd: save funding PSBT to database if we're to withhold it.by Rusty Russell · ff433a17 · Nov 18, 2025 · 11 filesMessage 73 · AdequateInformational 21Details
Commit message · Rusty Russell

lightningd: save funding PSBT to database if we're to withhold it.

Normally we don't care, but if we're withholding it, keep it around
so we can sign & broadcast later.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 21/100

This commit adds plumbing to remember whether a new Lightning channel's funding transaction is being deliberately withheld from broadcast, and to store the unsigned funding PSBT in the database so it can be signed and broadcast later. The actual feature is not yet enabled for users (a comment says 'FIXME: Set by option' and the flag is hard-coded to false). It is a preparatory/refactoring change, not a fix for an active security bug.

Security candidatepytest: test failure if we crash after fundchannel_complete but before sendpsbt.by Rusty Russell · 409beb69 · Nov 18, 2025 · 2 filesMessage 75 · AdequateInformational 12Details
Commit message · Rusty Russell

pytest: test failure if we crash after fundchannel_complete but before sendpsbt.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 12/100

This commit only adds a new automated test and a small test helper plugin. The test deliberately crashes a node between two internal steps of opening a payment channel, then checks whether the channel eventually opens after the node restarts. It is marked as expected to fail (xfail), meaning the test documents a known bug rather than fixing it. There is no production code change here.

Security candidatesendpsbt: update channel psbts if this is a channel PSBT.by Rusty Russell · ae9ecba3 · Nov 18, 2025 · 4 filesMessage 65 · AdequateLow 32Details
Commit message · Rusty Russell

sendpsbt: update channel psbts if this is a channel PSBT.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 32/100

This change makes the sendpsbt RPC command smarter: if the transaction being sent matches a PSBT that was promised for a new or spliced Lightning channel, the node now saves the final signed version with that channel so it can re-send it after a restart. It also updates the saved channel PSBT during splice signing. This is a reliability improvement for channel funding and splicing, not a fix for an obvious exploit.

AI review queuedpytest: test case where we crash before bitcoind gets the opening tx.by Rusty Russell · 21d19546 · Nov 18, 2025 · 1 fileMessage 75 · AdequateInformational 11Details
Commit message · Rusty Russell

pytest: test case where we crash before bitcoind gets the opening tx.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 11/100

This commit only adds a new pytest test case. It does not change any production code. The test simulates a crash scenario during a Lightning channel opening to make sure the software handles it correctly in the future. It is marked as expected to fail (xfail), meaning it documents a known problem rather than fixing it.

Security candidatecommon: don't abort() if wally_psbt_output_taproot_keypath_add() fails.by Rusty Russell · f284489c · Nov 18, 2025 · 7 filesMessage 81 · StrongModerate 60Details
Commit message · Rusty Russell

common: don't abort() if wally_psbt_output_taproot_keypath_add() fails.

It fails on duplicates. It would ideally succeed, but bug reported:

https://github.com/ElementsProject/libwally-core/issues/509

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `signpsbt` no longer crashes if asked to sign an already-signed PSBT with taproot paths.

81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet path
AI analysis · Moderate 60/100

This update fixes a crash in Core Lightning's wallet command `signpsbt`. When asked to sign a PSBT (a Bitcoin transaction format) that already contains taproot signatures, the underlying library would fail and the program would call `abort()`, killing the node. The patch turns that fatal crash into a normal error message. It also removes a test marker that expected the crash, confirming the bug is now fixed.

Security candidatepytest: test for signing a signed PSBT.by Rusty Russell · eaf7ac19 · Nov 18, 2025 · 1 fileMessage 70 · AdequateLow 43Details
Commit message · Rusty Russell

pytest: test for signing a signed PSBT.

Spoiler: we crash!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 43/100

This commit adds a test showing that Core Lightning crashes when asked to sign a PSBT (a Bitcoin transaction format) that has already been signed. The test is marked as expected to fail for now. It is a test-only change, not a fix, so the crash itself remains in the codebase. The crash appears to be triggered through a normal RPC call by an authenticated user.

Security candidatelightningd: save funding_psbt in channel, database.by Rusty Russell · 5cbab33d · Nov 18, 2025 · 11 filesMessage 73 · AdequateInformational 20Details
Commit message · Rusty Russell

lightningd: save funding_psbt in channel, database.

Interestingly, @niftynei added a funding_psbt column to the db in 2020,
but we don't use it (it was removed early 2021 with the "inflight"
architecture). So we don't need to add a new column, just plumb it
back in.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 20/100

This commit restores the use of an existing database column called funding_psbt in Core Lightning. It stores the unsigned Bitcoin transaction (PSBT) used to fund a Lightning channel in the channel record and database. The change itself is a data plumbing fix, not an obvious security patch. There is no direct evidence in the commit that it fixes an active vulnerability, but storing sensitive transaction data securely matters because the PSBT contains details about the funds being committed.

Security candidatelightningd: remove withheld flag when we see sendpsbt.by Rusty Russell · ead680eb · Nov 18, 2025 · 1 fileMessage 65 · AdequateLow 41Details
Commit message · Rusty Russell

lightningd: remove withheld flag when we see sendpsbt.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 41/100

This change fixes a bookkeeping bug in Core Lightning's wallet code. When a user calls the `sendpsbt` RPC to broadcast a funding transaction, the code now clears an internal 'withheld' flag on the relevant channel. Previously, this flag could remain stuck, which might prevent the channel from advancing normally after the PSBT (partially-signed Bitcoin transaction) was sent. The patch is small and only adjusts internal state tracking; it does not appear to introduce a direct remote exploit.

Security candidatelightningd: expose funding PSBT (if we have it) in JSON API.by Rusty Russell · 606aad07 · Nov 18, 2025 · 6 filesMessage 73 · AdequateInformational 19Details
Commit message · Rusty Russell

lightningd: expose funding PSBT (if we have it) in JSON API.

Changelog-Added: JSON-RPC: `psbt` field in `funding` in listpeerchannels, and `funding_psbt` in listclosedchannels.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Informational 19/100

This commit adds a new read-only field to two JSON-RPC API responses that exposes the funding PSBT (a Bitcoin transaction planning document) for a channel, if one is stored. It is an informational API enhancement and does not change how transactions are signed, validated, or broadcast. There is no indication in the commit that this fixes a security bug.

Security candidatelightningd: don't rebroadcast withheld channels' funding_psbt on restart.by Rusty Russell · 33e5876d · Nov 18, 2025 · 1 fileMessage 65 · AdequateLow 46Details
Commit message · Rusty Russell

lightningd: don't rebroadcast withheld channels' funding_psbt on restart.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
signing boundary
AI analysis · Low 46/100

This change stops Core Lightning from re-announcing the funding transaction for channels that are marked as 'withheld' when the node restarts. A withheld channel is one whose funding transaction should not be broadcast yet (for example, because it is waiting for a peer or some other condition). Re-broadcasting it could leak the channel's existence or funding details prematurely, or cause the transaction to be mined before the protocol is ready. The fix is a one-line guard that skips these channels during restart rebroadcast.

Security candidatespender: look for unsigned PSBT on awaiting channels on startup, and re-send.by Rusty Russell · df5f38db · Nov 18, 2025 · 4 filesMessage 85 · StrongLow 30Details
Commit message · Rusty Russell

spender: look for unsigned PSBT on awaiting channels on startup, and re-send.

This covers the other corner case, where we crash before actually
signing and sending the PSBT. We can spot this because the channel is
in AWAITING_LOCKIN and we have a PSBT, but it's not signed yet.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
signing boundary
AI analysis · Low 30/100

This commit fixes a crash-recovery bug in Core Lightning's channel-opening plugin. If the node crashed after receiving a funding PSBT but before signing and broadcasting it, the channel could get stuck in an 'awaiting lock-in' state. On startup, the plugin now scans for such stuck channels, signs the PSBT, and re-sends it so the opening process can continue. The change is defensive and improves reliability rather than introducing a security vulnerability.

AI review queuedlightningd: re-xmit funding txs on startup.by Rusty Russell · d44fa2f3 · Nov 18, 2025 · 8 filesMessage 68 · AdequateLow 31Details
Commit message · Rusty Russell

lightningd: re-xmit funding txs on startup.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Protocol: we now re-transmit unseen funding transactions on startup, for more robustness.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 31/100

This change makes Core Lightning re-broadcast funding transactions when the node restarts. Previously, only closing transactions were re-sent on startup. If a funding transaction was lost by the Bitcoin network (for example, due to a restart or mempool eviction), a new channel could be stuck waiting indefinitely. The fix improves reliability of opening channels, and the included test that was previously expected to fail now passes.

Lower-prioritylightningd: immediately close without broadcast whenever we close a withheld channel.by Rusty Russell · 8d99c5b8 · Nov 18, 2025 · 5 filesMessage 65 · AdequateLow 35Details
Commit message · Rusty Russell

lightningd: immediately close without broadcast whenever we close a withheld channel.

There's no funding tx to spend.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Low 35/100

This change fixes how Core Lightning handles closing channels where the funding transaction was deliberately withheld (not broadcast). Previously, the node tried to broadcast a unilateral close transaction for a channel that had no funding transaction on the blockchain, which is impossible and could cause errors or confusion. Now it immediately marks the channel as closed without broadcasting anything. This is a correctness and robustness fix rather than a direct theft-of-funds vulnerability.

Lower-prioritylightningd: add withhold option to fundchannel_complete.by Rusty Russell · b74d32f6 · Nov 18, 2025 · 8 filesMessage 73 · AdequateLow 28Details
Commit message · Rusty Russell

lightningd: add withhold option to fundchannel_complete.

This is just a polite way of telling us that if we close, don't bother broadcasting
since we didn't broadcast the funding tx.

Changelog-Added: JSON-RPC: `fundchannel_complete` new parameter `withhold` (default false).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 28/100

This commit adds a new optional 'withhold' flag to the fundchannel_complete command in Core Lightning. When set, it tells the node that the funding transaction has not been broadcast yet, so if the channel is closed before broadcasting, the node can skip trying to broadcast a closing transaction. It is a user-facing workflow convenience, not a fix for a known security flaw.

Lower-prioritylightningd: add withheld flag to listpeerchannels and listclosedchannels.by Rusty Russell · 39349965 · Nov 18, 2025 · 12 filesMessage 73 · AdequateInformational 18Details
Commit message · Rusty Russell

lightningd: add withheld flag to listpeerchannels and listclosedchannels.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `listpeerchannels` `funding` object `withheld` flag, and `listclosedchannels` `funding_withheld` flags, indicating fundchannel_complete was called with the `withheld` parameter true.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 18/100

This commit adds new read-only information fields to two JSON-RPC commands that list channel details. It exposes whether a channel's funding transaction was intentionally withheld from broadcast and, in one case, the associated PSBT (partially-signed Bitcoin transaction). There is no code change that alters how funds are handled, how transactions are signed, or how peers communicate; it only reports existing internal state through APIs.

Lower-prioritypytest: test withhold parameter to fundchannel_complete.by Rusty Russell · 2520bd5b · Nov 18, 2025 · 2 filesMessage 75 · AdequateInformational 15Details
Commit message · Rusty Russell

pytest: test withhold parameter to fundchannel_complete.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
AI analysis · Informational 15/100

This commit is a test-only change. It adds a new test for an existing feature called 'withhold' in the fundchannel_complete RPC, and updates the Python client library to pass the withhold parameter. There is no code change to the actual lightning node behavior, and nothing in the commit suggests a security fix or vulnerability.