Core Lightning

This commit removes a notification that was previously sent when the wallet tried to record a blockchain movement that it had already seen. The change is described as cleanup because another component (bookkeeper) now uses list commands instead of relying on this duplicate notification. There is no direct evidence in the commit that this fixes an active security vulnerability.

This commit finishes a previously-stubbed database migration that invents historical accounting records ('coin movements') for nodes that never ran the optional bookkeeper plugin. It does not change how funds are secured on the blockchain; it only backfills internal ledger entries so balances displayed by the accounting plugin look correct after an upgrade. There is no obvious way for an external attacker to exploit it, but any migration that writes made-up ledger entries carries a risk of miscounting funds or confusing downstream tools if the invented numbers are wrong.

This commit adds two new notification categories, 'chainmoves' and 'channelmoves', to the existing 'wait' command in Core Lightning. It also lets users paginate the related list commands with standard index options. There is no indication this fixes a security bug; it appears to be a normal feature addition.

This commit adds two new internal-only JSON commands, injectutxodeposit and injectutxospend, that let the bookkeeper plugin manually insert records of coins moving into or out of the node's accounting ledger. It also moves a helper for parsing outpoints into shared code. There is no direct evidence in the commit that these commands are exposed to untrusted users or that they introduce a vulnerability, but any command that can write arbitrary ledger entries deserves careful access control review.

This commit fixes a bug in Core Lightning's 'reckless' plugin installer tool. The bug was that very verbose dependency-resolution output from the 'uv' Python package manager was being dumped all at once as JSON to the reckless-rpc plugin, potentially overloading it. The fix both removes the verbose '-v' flag from uv and adds a rate-limiting helper that prints large JSON output in small chunks with tiny delays. It is a reliability/DoS-style bug fix, not a code-execution vulnerability.

This commit fixes a notification formatting inconsistency in Core Lightning's plugin system. Plugin-generated notifications (channel_hint_update, pay_failure, pay_success) now wrap their data inside an object named after the notification, matching how core notifications already work. The old unwrapped format is kept as a deprecated option for backward compatibility. This is primarily an API consistency and compatibility fix, not a security vulnerability fix.

This is a small code cleanup that switches to a helper function which unescapes JSON strings without making an extra copy. The only behavior change is that invalid escape sequences in command usage strings are now rejected instead of silently accepted unchanged. There is no obvious security vulnerability being fixed, and no evidence of an exploit or disclosure.

This commit is a code-quality refactor in Core Lightning's internal accounting system. It replaces formatted channel ID strings with direct pointers to channel objects, and introduces a small helper structure that can hold either a channel pointer or an alternative account name. The change removes unnecessary string formatting and lookups, and updates the wire serialization format for on-chain coin movement records. There is no indication of a security vulnerability being fixed or introduced.

This commit is a straightforward code cleanup: it moves the literal strings 'external' and 'wallet', plus small helper functions that test account names, into a single shared header file. Previously these strings and functions were duplicated across many files. There is no change to program behavior, no bug fix, and no security-related change.

This commit only adds the C keyword 'const' to function parameters and test stubs. It does not change any program logic, data flow, or behavior. It is a code-quality/cleanup change with no security relevance.

This is a routine internal code cleanup in Core Lightning. It changes how the node reports coin movements (on-chain and channel transactions) to plugins, switching from a single generic data structure to two more specific ones. There is no indication this fixes a security bug or introduces a vulnerability.

This commit is a straightforward internal refactoring: it replaces a variable-length list of text labels (called a 'tal_arr') with a compact 64-bit bitmap (a 'struct mvt_tags') for tracking coin-movement tags. The change touches many call sites but does not alter what the tags mean, how money moves, or any security boundary. It is not a security fix and introduces no obvious vulnerability.

This commit changes several database helper functions so they receive monetary amounts by copy (passing the value directly) instead of by pointer (passing a memory address). The commit message says this is just to match how the rest of the codebase now handles these types. There is no direct evidence in the diff or message that this fixes a security bug; it appears to be a code-consistency cleanup. Passing by copy can sometimes prevent certain classes of mistakes (for example, accidentally passing a NULL pointer or a pointer to uninitialized memory), but the diff does not show any such bug being fixed.

This commit is a simple code cleanup: it renames a set of internal bookkeeping labels (called enum mvt_tag values) so they all start with 'MVT_'. For example, CHANNEL_OPEN becomes MVT_CHANNEL_OPEN. The change touches many files but only renames symbols; it does not alter program logic, data formats, network behavior, or security checks.

This commit is a straightforward internal code cleanup: it moves the logic for converting a text tag into an internal coin-movement tag out of the JSON parser and into a dedicated helper function. There is no visible security fix, behavior change, or vulnerability being addressed.

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