Core Lightning

This is a small cleanup in Core Lightning's plugin helper library. It changes how memory ownership is documented for plugin notification messages so the code's automatic memory tracking matches what actually happens. The change itself is defensive and unlikely to be directly exploitable, but it fixes a mismatch that could hide real memory-management bugs in plugins.

This commit simply adds a new helper function for formatting relative time values as JSON numbers. It is a routine, non-security code addition with no bug fix or behavior change to existing features.

This commit only adds new automated tests for the xpay feature's notification system. It does not change any production code, so it cannot introduce a security vulnerability or fix one. The tests verify that plugins receive messages when a payment starts and ends, including failure cases.

This commit adds a new internal batching mechanism so that multiple Lightning protocol messages can be grouped together, split apart again inside the connection daemon, encrypted individually, and then sent as one stream to the peer. It is a feature implementation, not a clear security fix. There are no disclosed security references or incident claims supplied, and the commit message does not describe it as fixing a vulnerability.

This commit adds code to handle a new peer message called 'start_batch' in Core Lightning's channel daemon. Previously, the message type existed but was ignored (the case just returned). Now the daemon parses the message, checks that it is requesting a batch of 'commitment_signed' messages, and forwards the batch size into the existing batch signature handling logic. The change itself is a feature completion rather than a clear security fix, but it removes a place where a protocol message was silently ignored and could have caused mismatched state between two channel peers.

This commit adds a safety check in Core Lightning's channel daemon to verify that incoming peer messages are actually the expected 'commitment signed' type before processing them. If a different message type arrives, the daemon now logs a clear error and fails the peer connection rather than potentially misinterpreting the data. It is a defensive hardening change, not a fix for a known exploitable bug.

This commit updates Core Lightning's implementation of the Lightning Network splicing protocol to match a newer version of the specification. It removes a 'batch_size' field from the 'commitment_signed' message and moves that information to a different message ('start_batch'). The code changes are mostly mechanical: updating data structures, removing checks that used batch_size, and adjusting how messages are parsed and compared. There is no direct evidence in the commit or supplied references that this fixes a security vulnerability; it appears to be a protocol compatibility/spec-compliance update.

This commit adds support for two new Lightning protocol messages used in splicing: `start_batch` and an internal-only `protocol_batch_element`. The code mostly ignores or routes these messages; it does not appear to fix a security bug. The change is a feature addition matching a draft specification, with no clear security relevance in the diff itself.

This commit simply removes inline number comments (like '// 0', '// 1') from SQL UPDATE statements in the wallet code. These numbers used to help match database bind parameters, but are no longer needed after an earlier code change. There is no functional change to the program's behavior, no bug fix, and no security relevance.

This commit fixes a database migration in Core Lightning that was supposed to ensure every channel has a local alias (a routing identifier), but it missed channels that didn't yet have a stable channel ID (SCID). The patch moves and broadens the migration so all channels without a local alias get one, and then simplifies the code to always expect the field to be present. It is a data-integrity bug fix rather than an obvious remote exploit, but if a channel lacked a local alias it could lead to inconsistent routing behavior or crashes in later code paths that assume the alias exists.

This commit is a small code cleanup: it creates a shared helper function called random_scid() that generates a random channel identifier, and replaces two places that previously did this directly with calls to the new helper. It also adds a couple of test setup lines so wallet tests don't reuse stale channel maps. There is no security fix here—just refactoring and test hygiene.

This commit is a code-cleanup change in Core Lightning that makes the local channel alias a required value when creating a channel record, instead of allowing it to be optional/NULL. It removes a fallback that generated a random alias if one was missing. The change is defensive: it ensures every channel has a known local alias and avoids subtle bugs where a missing alias could lead to inconsistent channel lookup tables. There is no direct evidence in the commit or supplied references that this fixes an active security vulnerability.

This commit adds bookkeeping for previous channel identifiers (short_channel_ids) when a Lightning channel is spliced. Splicing changes the channel's identifier, so the software now remembers old identifiers in memory and in the wallet database. This is a routing/reliability improvement, not a security fix, and the commit message does not describe any vulnerability.

This commit adds a test showing that, after a Bitcoin 'splice' operation changes a Lightning channel's short channel ID (SCID), payments routed using the old SCID fail. The test is marked as expected-to-fail, meaning the bug is known but not yet fixed. It could cause legitimate post-splice payments to fail until the network learns the new routing identifier.

This is a performance improvement that replaces a slow search through every peer and channel with a fast hash table lookup when finding a channel by its short channel ID. The commit message and code show the same privacy rules were preserved. There is no security bug being fixed here.

This commit only adds a new test case to the project's test suite. It checks that old channel identifiers (short channel IDs, or SCIDs) remain usable for routing payments even after a channel has been spliced multiple times and a node has restarted. There is no change to production code, no bug fix, and no security-relevant behavior introduced.

This commit is a performance and code-organization change. It builds a fast lookup table (hash map) so the node can quickly find a channel from any of its short channel IDs, including old IDs and aliases. It also centralizes how channel IDs are set so the table stays consistent. There is no security fix or vulnerability described in the commit.

This commit fixes a routing bug in Core Lightning related to channel splicing. After a channel is spliced (a procedure that changes its identifying short-channel-id), the software previously refused to route payments using the old identifier for about six blocks, causing a temporary service gap. The fix makes the node also look up channels by their old identifiers, restoring routing continuity. There is no direct evidence this is a security vulnerability; it appears to be a protocol/routing reliability fix.

This commit only adds extra debug logging to a transaction-handling routine. It does not change program logic, fix a bug, or introduce a security weakness. It is a diagnostic improvement.

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 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 commit only adds a new automated test to the project's test suite. It exercises a feature called 'cross-channel splicing'—combining updates to two payment channels into a single Bitcoin transaction. There is no change to production code, no bug fix, and no security-related content.

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 only adds extra details to existing error log messages during a Lightning channel splicing operation. It does not change program logic, fix a bug, or alter security behavior. It is a diagnostic/logging improvement.

This commit adds tracking for whether a node has sent its own splice signatures during a channel-splicing negotiation. It also changes the logic so that the node updates its internal 'inflight' funding record when it either receives the peer's signature or sends its own. The change appears to fix a state-tracking gap that could cause a splice to stall or leave the channel in an inconsistent state, but the commit message does not frame it as a security fix and no exploit is directly evident from the diff alone.