Core Lightning

This commit tightens the conditions under which Core Lightning's channel daemon will abort a splice operation. Previously, the daemon treated a splice as unabortable if any signatures existed in the 'inflight' (pending) channel state. Now it only blocks abort if this specific node has actually sent its signatures to the peer. The change is one line and appears aimed at preventing a node from backing out of a splice after it has already committed to it cryptographically, which could otherwise let a malicious or buggy peer exploit inconsistent state.

This change only improves an error message shown when a splicing (channel funding update) negotiation fails because the remote peer did not send enough signatures. It adds a count of how many remote inputs need signatures and how many signature bundles were actually received. There is no code behavior change that fixes or introduces a vulnerability; it is purely a diagnostic/logging improvement.

This change adjusts how Core Lightning handles 'splicing' (a way to resize a Lightning channel's on-chain funding). When a user splices multiple channels at the same time, the software now signs a shared piece of the transaction earlier than before, so it can build a complete signatures message for all peers. The commit describes this as fixing a deadlock, not as a security vulnerability. There is no direct evidence in the commit or supplied references that this is exploitable by an attacker.

This change fixes a bug in Core Lightning's channel-splicing code. During a splice, two versions of a Bitcoin transaction structure (a PSBT) might look identical in their main transaction data but differ in their attached signatures. Previously, the code would skip copying the new PSBT if the main transaction hadn't changed, which could discard signatures from a related splice. The fix always copies the latest PSBT so signatures are preserved. The commit describes this as a bug that could affect 'cross splice' scenarios, but it does not label it as a security vulnerability.

This commit fixes a bug in Core Lightning's splicing feature where a transaction input could be incorrectly removed during a 'cross-channel splice' because the software compared a newly-added signature hash flag. The fix tells the comparison logic to ignore the signature-hash value so the input is not treated as changed and wrongly dropped. It is a functional bug fix rather than an obvious security vulnerability, but it could cause a splice to fail or funds to be handled incorrectly.

This commit adds two SQLite JSON helper functions, json_object and json_group_array, to the list of functions allowed by Core Lightning's SQL plugin. The change is a small whitelist expansion in the plugin's query authorization code. The commit message explicitly states this does not introduce new SQL injection risks and that the functions follow existing table and row permissions. There is no direct evidence in the commit of a security vulnerability.

This commit only updates two documentation/schema files to list two additional SQLite functions (`json_object` and `json_group_array`) as permitted. There is no code change, no behavior change, and no security-relevant change visible in the diff.

This commit only adds new automated tests for SQL JSON functions in the Core Lightning project. It does not change any production code, fix a bug, or introduce a security feature. There is no security relevance.

This change makes Core Lightning stricter during Lightning channel opening: it now refuses to open a channel if the other peer does not include a 'channel_type' field. Previously, Core Lightning would guess a default channel type when the peer omitted it. The commit author frames this as a simplification, but it also removes a fallback path that could have led to mismatched assumptions between nodes about what kind of channel they were creating.

This is a test-only change that renames plugin option names from using hyphens (zeroconf-allow, zeroconf-mindepth) to underscores (zeroconf_allow, zeroconf_mindepth). It only affects test files and a test helper plugin, making the tests work correctly with pytest's option handling. There is no security issue here.

This change makes a Lightning protocol feature called 'option_channel_type' mandatory instead of optional. It tells peers that Core Lightning will now require them to support this feature, which has been widely available since 2022. This is a protocol compatibility change, not a fix for an active security flaw, but it removes a path where older or non-standard peers could negotiate channels without this feature.

This commit only adds a new automated test to Core Lightning. The test checks that when a user explicitly requests a zero-confirmation (zeroconf) channel from a node that does not allow it, the node returns a clear refusal message. It then checks that adding the requester to an allowlist permits the channel. There is no code change to the actual lightning node behavior—only a test is added.

This commit adds a single assertion to an existing test to verify that private channels include the expected 'scid_alias/even' channel type. It is purely a test improvement and does not change any production code, fix a bug, or address a security issue.

This commit removes old compatibility workarounds in Core Lightning's channel-opening code. Previously, the software had to guess whether a peer wanted a private channel alias feature because older versions mishandled it. Now that all supported versions handle the feature correctly, the code simply sets it directly. This is a cleanup change, not a fix for an active security flaw, but removing compatibility shims can reduce hidden bug surface.

This commit changes how Core Lightning decides what kind of channel to open with another node. Previously, the opening daemon could fall back to a default channel type if none was specified. Now, the main lightningd process always picks and sends a specific desired channel type. A side effect is that if the peer signals support for zero-confirmation channels (by setting minimum_depth to 0), the returned channel type will include the zeroconf feature even if the user did not ask for it. The commit is described as a behavior change, not a security fix, and there is no evidence of a disclosed vulnerability.

This commit is a documentation-only change. It updates the developer getting-started guide to recommend a different helper command (`fund_nodes` instead of `connect`) when setting up a local test environment. There is no code change and no security relevance.

This commit only changes test code. It refactors how the reckless plugin-manager tests search through command output, replacing exact string checks with regular-expression searches and adding a small helper class. There is no change to production code, no security fix, and no vulnerability introduced.

This commit adds a new automated test for installing a Python plugin using the 'uv' package manager. It only touches test files and test data, not the actual Core Lightning node or wallet code. There is no security issue visible in the change itself.

This commit adds a new installer path in Core Lightning's reckless plugin manager so that older Python plugins using a simple requirements.txt file can be installed with the fast uv tool. The change creates symlinks to the plugin's pyproject.toml and requirements.txt, builds a virtual environment, and runs a shell command to install dependencies. The shell command is constructed as a single string and executed with shell=True, which is a well-known risky pattern, but the inputs come from local plugin metadata rather than remote or attacker-controlled data in the scenario shown. There is no direct evidence in the commit that this is a security bug or that it fixes a reported vulnerability.

This commit adds a new way for Core Lightning's reckless plugin installer to set up Python plugins using 'uv', a fast Python package manager. It is a feature addition with no apparent security relevance in the code itself.

This is a small bug fix in a helper tool called 'reckless' that installs plugins for Core Lightning. The tool tries several possible file names to find a plugin's main entry point. Before this fix, if an installer had fewer possible names than the loop expected, the code could crash with an index error. The patch simply skips installers once their list of possible names is exhausted. There is no direct security relevance in the commit itself.

This is a small bugfix in a helper tool called 'reckless' that installs plugins for Core Lightning. The change fixes how the tool handles installing a plugin directly from a subdirectory inside a local git repository. Previously, the tool could fail to find plugin details because it passed the wrong name/location. The fix reorders two steps so the local repository is treated like a plain directory before trying to read plugin details. There is no clear security issue here; it appears to be a normal correctness fix for a development/testing convenience feature.

This commit is a minor internal cleanup of a test helper. It moves an existing stderr-checking function into a class method and slightly expands the list of harmless warning strings that tests ignore. It does not change any production code, network behavior, or security logic.

This commit only adds and rewords comments in the source code to make it easier to find places where the project would like to require a newer SQLite version in the future. It does not change any actual behavior, fix any bug, or alter any security-related logic.

This commit removes support for very old SQLite versions (before 3.14) in Core Lightning. It deletes a fallback mechanism that used SQLite's tracing feature to log expanded SQL statements when the newer sqlite3_expanded_sql function wasn't available. The change simplifies the code and requires SQLite 3.14 or newer. There is no direct security fix here, but running outdated SQLite versions can carry general security risks.