Core Lightning

This commit only adds test data files (compressed SQLite snapshots) and a new pytest test case for the bookkeeper module. It is a testing-only change with no modifications to production code, so it has no security impact on running Core Lightning nodes.

This commit is a code cleanup in Core Lightning's bookkeeper plugin. It removes support for tracking multiple currencies per account and simplifies how account balances are calculated. The change is described by the developer as removing a concept they no longer want. There is no indication in the commit message or diff that this fixes a security vulnerability.

This commit moves bookkeeping of penalty-related channel balance adjustments from the bookkeeper plugin into the main lightningd process. It adds new internal accounting tags and a message so the on-chain subsystem can tell lightningd when to record these adjustments. There is no direct security vulnerability visible in the diff; it is a refactor of how internal accounting events are generated.

This commit is a straightforward internal code cleanup: it changes a data structure so that a transaction reference (outpoint) is stored directly inside the structure rather than as a separate pointer. The commit author states the pointer was always expected to be set anyway, and the change removes a misleading comment suggesting it could be absent. There is no indication this fixes a security bug or changes externally observable behavior in a risky way.

This commit moves the timestamp for coin movement records from being generated at the moment of notification into the coin movement data structure itself. It is a straightforward internal refactoring to prepare for future list commands. There is no security issue here.

This commit is a routine API cleanup, not a security fix. It splits the coin_movement notification's old 'tags' array into two new fields: 'primary_tag' and 'extra_tags'. The old 'tags' array is kept for backward compatibility but marked as deprecated. Nothing in the change fixes a vulnerability or changes how funds are protected.

This commit is a small code cleanup: it introduces a helper function that converts internal 'tags' into strings, and uses that helper in two places where notifications are formatted as JSON. There is no visible change in behavior and no security issue is apparent.

This commit adds internal safety checks to ensure that financial movement records in Core Lightning always start with a main category tag, with any extra tags treated as secondary. It does not change user-facing behavior in production builds, but it helps prevent bookkeeping mistakes that could misclassify transactions.

This change only affects internal test helper code. It makes test comparisons of tag lists ignore the order of tags by sorting them first. There is no security issue; it is a test robustness fix.

This commit changes a spelling-check script so it ignores uppercase and lowercase when filtering out the word 'highlight'. It is a build/tooling fix to prevent false positives in the project's spell checker and has no security relevance.

This commit extends the internal message format used between parts of a Core Lightning node so that extra optional data fields (TLVs) attached to forwarded payments are preserved when HTLCs are passed between sub-daemons. The change itself is a data plumbing/plumbing extension, not a fix for a known vulnerability. There is no vendor statement that this is a security patch, and no independent researcher is credited.

This commit only updates developer documentation. It adds a description of an existing feature called extra_tlvs to the htlc_accepted_hook documentation. There is no code change, no bug fix, and no security issue visible in the commit itself.

This commit changes how Core Lightning stores extra data fields (called TLVs) attached to HTLC payment messages. Previously, only known fields like the blinded path were kept. Now, any unknown extra TLV fields are preserved inside the internal HTLC record too. The stated purpose is to later forward these extra fields to the htlc_accepted_hook plugin interface. There is no direct security fix here; it is a data-preservation change that could affect how future features or plugins handle payment data.

This commit refactors how Core Lightning reads and writes optional extra TLV data attached to HTLC messages. The main functional change is adding a length check when reading these wrapped TLV streams, so a malformed message cannot claim a length larger than the remaining data. The commit message explicitly calls out that the length was not being checked properly before.

This patch fixes a memory-management bug when handling extra TLV (type-length-value) data attached to Lightning Network HTLCs (payment hops). The bug involved the 'taken()' memory ownership marker: when the caller had marked the extra_tlvs array to be 'taken' (transferred), the old code would still make a full copy and deep-copy of every value buffer, which is unnecessary and could lead to use-after-free or double-free problems because the original array's value buffers were not re-parented correctly. The patch introduces a helper that checks whether the array is already 'taken' and, if so, avoids the redundant deep copy, ensuring the value buffers are attached to the correct parent object.

This is a trivial change to a spell-checking script used during development. It tells the spell-checker to ignore package-lock.json files because their randomly-generated hash strings can accidentally contain the letters 'ctlv', which the script flags as a misspelling of 'cltv'. There is no security issue here.

This commit only adds new automated tests and a test plugin. It does not change any production code, so it cannot by itself introduce a security vulnerability or fix one. The tests exercise an existing feature that lets plugins attach custom data fields to forwarded Lightning payments, and verify that malformed data triggers a 'BROKEN' log warning.

This commit adds a new plugin hook feature to Core Lightning that lets plugins inspect and replace optional extra data (TLV fields) attached to forwarded Lightning payments. It is a feature addition, not a direct bug fix. The code includes validation of those extra fields and a note that they are not saved to the database. There is no claim in the commit that this fixes a security vulnerability.

This commit changes how Core Lightning passes extra data fields (TLVs) when forwarding or storing payment instructions inside the channel daemon. It adds a new field to an internal message and recombines those extra fields with a blinding key before the HTLC is added to the channel. There is no direct evidence in the commit that this fixes a security bug; it appears to be a protocol-correctness or feature-completeness change for blinded routes.

This commit adds a brand-new plugin called cln-bip353 to Core Lightning. The plugin lets users look up Bitcoin/Lightning payment instructions from human-readable addresses like send.some@satsto.me using DNS (BIP-353). It also exposes a new RPC command and gRPC method named fetchbip353. Because this is a large feature addition touching RPC, gRPC, generated Python code, documentation, and tests, it increases the attack surface of the node: any bugs in DNS resolution, DNSSEC proof handling, or parsing of returned payment instructions could affect the node. However, the commit itself is a feature addition, not a documented security fix, and no specific vulnerability is visible in the diff.

This change moves two helper functions from a source file into a header file and marks them 'inline' so the compiler can optimize common calls. It is a performance cleanup, not a security fix. The functions behave the same way as before; only how the compiler sees them changes. Test stub files are updated to match the new internal layout.

This commit fixes a bug in Core Lightning's handling of multiple ping commands sent at the same time. Previously, if two ping commands were issued in parallel, the replies could arrive out of order and be matched to the wrong command, potentially causing incorrect responses or confusion in the node. The fix adds a unique request ID to each ping so replies can be correctly paired with their original commands.

This change adds a warning log when the Lightning node's connection handler has ignored incoming peer messages for more than 5 seconds. It does not fix the underlying delay; it only makes the delay visible in logs so operators and developers can spot when message processing stalls.

This is a small change to a developer-only diagnostic tool called 'gossipwith'. It adds a new optional command-line flag that makes the tool return a failure exit code if it does not receive the expected number of messages. There is no indication this fixes a security bug or affects normal Lightning node operation.

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.