Core Lightning

This is a small cleanup change in the bookkeeping (bkpr) plugin. It changes how a payment identifier (a 32-byte hash value) is passed into a function: instead of 'stealing' ownership of the caller's copy, it now 'takes' a read-only pointer and makes its own duplicate if needed. The commit message says this is to make it easier to pass a temporary value created on the stack. This is defensive coding and reduces the risk of memory-management mistakes, but it does not by itself fix a known exploitable bug.

This commit rewrites the bookkeeper (bkpr) plugin so that most of its internal SQLite queries are sent through a new SQL plugin instead of being executed directly. The change is described as a refactoring to use a shared SQL backend. There is no claim in the commit that this fixes a security bug, and the diff does not show an obvious vulnerability. However, because the new queries are built by concatenating strings with user-influenced values (account names, transaction IDs, payment hashes) there is a small risk of SQL injection if the helper functions do not escape those values correctly. The commit also removes a duplicate-check when logging chain events, which could in principle allow duplicate records, but that is a data-integrity issue rather than a direct security flaw.

This is a small bug-fix in Core Lightning's bookkeeping plugin. Previously, if a user sent a deposit notification without specifying where the funds came from, the plugin would incorrectly record the origin account as the literal string "null". The fix makes the transfer_from field optional and treats a JSON null value as 'no origin account' rather than an account named "null". This is a data-correctness issue, not a direct way for an attacker to steal funds or take over a node.

This commit only changes a test file to add short waits before checking coin-move records. It is a test reliability fix, not a security patch, and does not change any production code that handles funds, networking, or cryptography.

This change lets Core Lightning plugins make synchronous (blocking) JSON-RPC calls at any time, not just during startup. To do that safely, it opens a second Unix socket connection to the lightningd RPC so the sync call does not collide with ongoing async traffic. The patch also fixes a memory-handling quirk so the returned response is a proper allocated object. There is no direct evidence this fixes an active security bug, but it removes a risky restriction and improves robustness.

This commit only adds a new test case to the project's test suite. It simulates a scenario where one side of a Lightning payment channel believes an HTLC was fulfilled while the other side does not, then verifies that the internal accounting records (called 'coinmoves') are produced correctly. There is no change to production code, no fix, and no vulnerability being patched.

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 is a performance optimization, not a security fix. It replaces a slow loop that searched through every peer and channel to find a channel by its database ID with a fast hash table lookup. The change makes the listcoinmoves command respond faster on large nodes but does not address any 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 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 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 change fixes a user-experience and protocol-courtesy bug in Core Lightning's channel-opening code. Previously, if you tried to open a channel smaller than your own configured minimum, the node would still ask the peer to open it and then blame the peer when the peer accepted. Now the node checks its own settings first and fails locally with a clear message before bothering the peer. It is not a funds-loss or remote-code-execution vulnerability.

This commit adds a test that reveals a bug in how Core Lightning handles channel openings that are below a user's own configured minimum. Currently the node lets the user try to open the channel and only fails after the remote peer gets involved, which is impolite and could leak information or cause unnecessary peer disconnects. The test is marked as expected to fail (xfail), meaning the bug exists but is not yet fixed by this commit.

This commit only adds a new command name to the documentation build lists. It does not change any executable code, security settings, or user permissions. There is no security relevance.

This commit adds a new feature to Core Lightning's xpay plugin: the ability to pay a human-readable BIP353 address (like a Bitcoin Lightning email address). It is a straightforward feature addition with no visible security bug or vulnerability in the code changes.

This commit adds a convenience feature to the Core Lightning `xpay` plugin so users can pay a simple BOLT12 offer directly, without first running `fetchinvoice` manually. The plugin now detects an offer string, validates it, calls `fetchinvoice` internally, and then proceeds with normal payment. There is no security-relevant change visible in the diff.

This commit only updates the macOS installation instructions in the project's documentation. It replaces the old Python setup using pyenv and poetry with a newer tool called 'uv' for managing Python dependencies. There are no code changes and no security implications.

This commit adds a new automated test to Core Lightning. The test checks that when a user tries to fetch a BOLT12 invoice through a peer that is currently disconnected, the software should not attempt to use that disconnected peer. The commit message shows the test previously failed with an 'unknown next peer' error, suggesting a bug where disconnected onion-message-capable peers were incorrectly selected as routing hops. This is a test-only change; no production code is patched here.