Core Lightning

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This is a small bug-fix patch for Core Lightning's internal channel gossip state machine. It adds one previously missing allowed transition between two internal states, preventing the daemon from logging a 'BROKEN' error and potentially misbehaving when a special type of channel (zeroconf, or soon a 'withheld' funding flow) is closed before the funding transaction is mined. There is no indication this allows an attacker to steal funds or take control; it is a robustness fix for an edge case in protocol handling.

This is a small internal refactoring change in the Core Lightning 'offers' plugin. It changes one helper function so it can check for multiple peer features at once (using a bitmap) instead of only one feature at a time. The callers are updated to pass their single feature as a bitmap bit. There is no security fix or behavior change visible to users.

This change tightens which network peers Core Lightning will choose when creating hidden (blinded) payment paths for incoming invoices. Previously it only required support for route blinding; now it also requires support for onion messages. The reason given is that LND nodes were reportedly not forwarding these hidden payments correctly, which could cause payment failures or routing problems. It is a robustness fix rather than a clear-cut security patch, and there is no evidence in the commit of funds being stolen.

This commit only adds and adjusts Python test code for the Core Lightning project. It extends existing tests to verify that a 'channel_state_changed' notification is correctly emitted when a payment channel transitions into the CLOSED state. There are no changes to production code, no bug fixes, and no security-sensitive behavior being altered.

This is a routine API cleanup, not a security fix. The commit changes how Core Lightning tells plugins about channel state changes: instead of sending `"message": null` when there is no message, it will eventually stop including the `message` field at all. For now it still sends `null` unless the user has opted into strict 'no deprecated features' mode. The code also removes a general helper for adding `null` values to JSON and adds private copies in two places that still need it temporarily.

This commit updates two JSON schema files used by Core Lightning to document and validate a notification message. It adds 'CLOSED' as a permitted value for the channel state field in the 'channel_state_changed' notification, along with a note that this value was introduced in version 25.12. There is no code behavior change, no runtime logic change, and no security fix or vulnerability present in the diff.

This commit adds a new plugin notification so that plugins are told when a Lightning channel finishes closing and reaches the CLOSED state. It also makes the optional human-readable 'message' field in that notification truly optional in the generated API bindings. This is a routine feature addition, not a security fix or vulnerability.

This change adjusts how Core Lightning's xpay plugin splits payments. It limits multi-part payments to 6 pieces when the destination is not publicly known, matching a known limit used by Phoenix wallets. If routing fails with that limit, xpay removes it and retries. Previously, xpay could send too many payment pieces through private channels, causing payments to fail at the recipient. This is a compatibility and reliability fix, not a security vulnerability in the traditional sense, but it prevents a real-world payment failure scenario.

This commit only adds a new test case to the project's test suite. It does not change any production code. The test checks that the xpay payment feature limits how many simultaneous payment paths it tries to use when one of the channels is unannounced and has a low limit. Because no actual software behavior is changed, this commit by itself does not create or fix a security vulnerability.

This commit adds a test showing a bug in Core Lightning's routing-reservation system. When two separate routing layers use the same fake channel ID, a reservation made through one layer is incorrectly counted against the other layer too. The test is marked as expected to fail, meaning it documents the bug rather than fixing it. This could cause valid payment routes to be rejected because the system thinks capacity is already reserved when it should not be.

This commit adds an optional 'layer' field to the askrene-reserve and askrene-unreserve commands in Core Lightning. The purpose is to let different plugins (like xpay) reserve capacity on fake or aliased channels without their reservations colliding with each other. It is a feature addition that improves correctness of route planning, not a fix for an active security bug.

This fix corrects a bug in Core Lightning's 'xpay' plugin where temporary, made-up channel identifiers used for private payment routes (routehints and blinded paths) were being treated as real, globally-known channels. When two payments ran at the same time, they could reserve the same fake identifier and interfere with each other, potentially causing one payment to fail or be delayed. The fix marks these channels as fake and keeps their reservations private to each payment.