Core Lightning

This commit adds three new database tables to Core Lightning's wallet module: one for account names and two for recording on-chain and off-chain fund movements. It is a straightforward schema migration with no logic changes, no bug fixes, and no security-sensitive operations visible in the diff.

This commit adds read-only helper functions to pull coin-movement records out of the wallet database. It does not change how funds are handled, does not fix any bug, and does not introduce any obvious security issue. It is a straightforward data-access addition.

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 change updates Core Lightning's internal accounting records when a payment channel closes. Previously, records in the `chain_moves` and `channel_moves` database tables kept pointing to the closed channel's internal database ID. After this patch, they are rewritten to reference a stable text identifier (the channel ID) instead. The commit message says this avoids dangling references to closed channels and makes future cleanup easier. There is no direct evidence in the commit of an exploitable security vulnerability; it looks like a data-integrity and maintainability fix.

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 hardens how Core Lightning records coin-movement tags in its database. It locks the numeric values of an internal enum so future code changes cannot silently reorder them, adds a translation helper to ensure the stored database values stay stable, and validates tag sets before writing them. There is no direct exploit here; it is a defensive fix to prevent data corruption or accounting mismatches if the enum were ever changed.

This commit adds new bookkeeping routines that record money movements into two database tables, one for on-chain transactions and one for channel (off-chain) transactions. It also adds a database index to speed up duplicate-checking for on-chain records. There is no indication this fixes a security bug; it appears to be a normal feature addition for accounting/audit logging.

This commit moves the bookkeeper accounting data from a separate plugin database into the main lightningd database at startup. It adds a one-time migration that reads the old accounts.sqlite3 file and copies its records into new internal tables. The change is mostly a refactor of where data lives, but it touches startup code, database migrations, and option handling. There is no direct evidence in the commit that this fixes an active security vulnerability; it appears to be architectural cleanup.

This change makes Core Lightning save every on-chain and channel coin movement to its internal database before sending out a notification. Previously, some coin movements were only notified and not persisted. It is an accounting/audit-logging improvement rather than a fix for an exploitable security flaw.

This commit adds a new 'create' flag to Core Lightning's database-opening code. When create is false, the code tries to open an existing database but refuses to create a new one if it is missing, returning an error instead of crashing. This is a defensive change that makes the wallet startup behavior safer in some situations, but it does not by itself fix a known exploitable bug.

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