Core Lightning

This commit adds two new internal plugin commands, addblockdepthwatch and delblockdepthwatch, to the bwatch plugin in Core Lightning. They let another part of the node ask bwatch to track how many blocks have passed since a chosen starting block height. There is no indication in the commit that this fixes a bug or addresses a security issue; it appears to be a normal feature addition.

This commit only adds new automated tests for an existing Core Lightning feature called 'bwatch' (a block-watching plugin). It does not change the actual production code that users run, so it cannot introduce a security vulnerability or fix one in the shipped software. A few existing tests were also updated to disable the bwatch plugin so their datastore checks remain accurate.

This commit adds a routine background loop to a new Core Lightning plugin called bwatch. The plugin periodically asks Bitcoin for the latest block, downloads any missing blocks one at a time, keeps an in-memory history, and saves each block to the plugin's datastore. It is described by the author as the 'happy path' only; handling of chain reorganizations, watch notifications, and matching logic is explicitly left for later commits. There is no security-relevant behavior, vulnerability, or incident described in the commit or supplied references.

This commit adds helper functions for converting Bitcoin block IDs between hex strings and internal binary structures, and exposes them through JSON parsing/serialization helpers. It is a straightforward code refactoring and feature addition with no apparent security relevance.

This commit adds a brand-new, empty plugin called 'bwatch' to the Core Lightning build system. It contains only placeholder files, a basic plugin entry point, and no actual block-scanning logic. It is not yet connected to the main lightningd process. There is no security issue here—this is just the first scaffolding commit for a future feature.

This commit adds a new internal engine that can replay older Bitcoin blocks so newly created transaction watches can catch up on past confirmations. It is purely additive code: the new rescan function is defined but not yet connected to any user-facing command, so it cannot be triggered by users today. There is no obvious security bug in the added code, and nothing in the commit claims to fix a security issue.

This commit adds a new block-scanning step in Core Lightning's 'bwatch' plugin. After the existing checks for transaction scripts and outpoints, it now also checks 'short channel ID' (scid) watches. If a watched scid's encoded block height matches the block just processed, it looks up the exact transaction and output number encoded in the scid and reports the result to lightningd. If the encoded position doesn't exist, it reports 'not found' so lightningd can clean up the watch. There is no indication in the commit that this fixes a security vulnerability; it appears to be a missing functional feature.

This commit fixes a bug in Core Lightning's blockchain-watch plugin (bwatch). When the Bitcoin chain reorganizes (a block that was considered part of the chain gets replaced by a different one), bwatch was removing the old tip block without telling the rest of the node. The fix makes bwatch notify all relevant 'watch owners' before the block is discarded, so lightningd can undo any state changes tied to that now-orphaned block. Without the fix, the node could keep stale or incorrect state after a reorg, which in a Lightning node can lead to incorrect channel balances or missed on-chain events.

This commit adds an opt-in flag called --experimental-bwatch. The bwatch plugin still loads, but it will not poll the Bitcoin blockchain or process any chain watches unless the user explicitly enables the new flag. It is a feature-gating change, not a fix for an active security bug.

This commit only adds documentation for an existing configuration option called bwatch-poll-interval. It describes how long the bwatch plugin waits between checks for new blocks from bitcoind. There are no code changes and no security implications.

This change fixes a functional gap in Core Lightning's block watcher plugin. Previously, if you asked the node to watch for a transaction or output that had already been confirmed in the past, the watch would be recorded but the node would not look back through old blocks to find it. Now, when a watch is added for a starting block at or behind the current chain tip, the plugin automatically triggers a rescan over the relevant historical range for that specific watch, and keeps the RPC call pending until the rescan finishes. This is a correctness/reliability improvement rather than a typical security vulnerability patch.

This commit adds a new read-only RPC command called listwatch to the bwatch plugin. It simply lets users and tests see what blockchain watches are currently active. There is no change to how watches are created, deleted, or processed, and no security-sensitive logic is modified.

This commit adds two helper functions for managing blockchain watches in a new plugin called bwatch. It lets different parts of the program register interest in a transaction or output, merge duplicate registrations, and remove their interest when done. There is no obvious security bug in the change itself; it is routine infrastructure code.

This change only adjusts a test to wait for a background bookkeeping process to finish before stopping the node. It is not a security fix for production code; it makes a flaky test more reliable so the test's own database mirror does not miss a late write during shutdown.

This commit simply makes an existing internal helper function available for use by other parts of the codebase. It does not change any behavior, fix any bug, or introduce any new functionality that could be misused. There is no security relevance visible in the change itself.

This is a one-line fix in a helper library that builds JSON output. The function json_out_addstrn is supposed to add a string of a specific length, but it was escaping the entire string using a function that ignores the requested length. This could cause a string that contains bytes beyond the intended length to be incorrectly included in JSON output, potentially leaking nearby memory or producing malformed JSON. The patch makes the escaping respect the intended length.

This commit simply moves two small helper functions that decode hex strings into numbers from two plugin files into a shared library. It is a routine code cleanup/refactoring change with no security relevance visible in the diff or commit message.

This commit adds a new internal notification path in Core Lightning's block-watching plugin. It makes the plugin send a depth update to other parts of the node every time a new block arrives, so components waiting for confirmation milestones (like channel-close handling) wake up on time. The change itself is a feature/fix for reliability in hibernating environments such as Greenlight, not a patch for an externally reported security vulnerability. There is no evidence in the commit or supplied references of an exploitable weakness.

This change is a defensive startup fix for the bwatch plugin in Core Lightning. It makes the plugin check Bitcoin's sync status and share it with another component (watchman) before starting normal block polling. It also rolls back the plugin's stored block tip if Bitcoin appears to have a shorter chain at startup. The commit does not appear to fix an active exploit; it is more like adding a safety check to prevent inconsistent state when a node restarts while Bitcoin is still syncing or has reorged.

This commit simply moves an existing helper function that parses a JSON array of strings from one file (inside the xpay plugin) to a shared common library. No behavior changes, no bug fixes, and no security implications are visible.

This commit adds a new feature to the bwatch plugin that remembers recent Bitcoin block history in the node's internal database. It is a reliability improvement for handling blockchain reorganizations, not a security fix. There is no indication of a vulnerability being patched.

This commit hardens crash recovery in Core Lightning's new block-watching plugin (bwatch). Previously, bwatch would immediately fetch the next Bitcoin block after saving one. Now it waits for lightningd's 'watchman' component to confirm it has also recorded the same block height before continuing. This prevents a situation where bwatch moves ahead of the main daemon, so if the node crashes and restarts, no block that bwatch acted on is invisible to the rest of the system.

This commit adds two new internal plugin commands, addscidwatch and delscidwatch, to the bwatch plugin in Core Lightning. They let lightningd ask the plugin to start or stop monitoring a specific Lightning channel identifier (short_channel_id) for a particular owner. The change is purely additive and exposes existing watch functionality through a new, more precise lookup path. There is no indication of a security bug or fix.

This commit only updates three test strings in a Python test file. It changes the expected help output from one RPC command name ('addpsbtinput') to another ('addoutpointwatch'). There is no code change, no bug fix, and no security relevance visible in the diff.

This commit adds blockchain reorganization (reorg) handling to Core Lightning's 'bwatch' plugin. A reorg happens when the Bitcoin network temporarily replaces a known block with a different one. Previously, bwatch appears to have blindly trusted each new block's parent hash, which could have left the plugin tracking an invalid or forked chain. The patch detects mismatched parent hashes, rolls back its internal tip one block at a time, and tells another component ('watchman') to do the same. It is a defensive correctness fix rather than an active exploit patch; the commit message notes that notifying users whose transactions were affected is deferred to a later commit.