Core Lightning

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 adds a new bookkeeping flag, 'i_sent_sigs', to track whether a splice signature has already been sent. It changes how the node decides that question: previously it inspected the active PSBT, but now it records the fact explicitly in memory, wire messages, and the wallet database. The change is described as a refactor to support generating splice signatures earlier. There is no direct evidence in the commit of a security vulnerability, but any mismatch in this flag could in principle cause a node to send signatures twice, omit them, or resume a splice incorrectly after a restart.

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 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 commit fixes a small bug in how Core Lightning builds Bitcoin witness data from a PSBT. Previously, when a witness item had a declared length of zero, the code would still try to copy data from a pointer that could be NULL. The fix skips the copy when the length is zero and adds an assertion that the pointer is valid when length is non-zero. This is a defensive correctness fix; it likely prevents a potential NULL-pointer read or undefined behavior rather than an obvious remote exploit.

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