Eclair

This commit adds new internal event notifications when a Lightning payment cannot be relayed through a node. It is a defensive, observability-only change: it does not alter payment handling logic, but gives node operators signals they can use to decide where to allocate channel liquidity. The commit message explicitly warns that the events can be gamed by malicious senders and should not be acted on blindly.

This commit is a refactoring and observability improvement for the Eclair Lightning node. It adds the node identifier (node_id) of channel peers to various payment events and restructures how payment events are represented in code. It does not fix a security vulnerability, nor does it introduce obvious new attack surface. The database schema is intentionally not yet updated, so some stored data uses a placeholder node_id. The change touches many files but is mostly internal plumbing for metrics and audit logging.

This commit is a refactoring and observability improvement for the Eclair Lightning node. It adds start/end timestamps to payment events and failures, renames some timestamp fields for consistency, and updates how payment hashes are derived from preimages. There is no direct security vulnerability visible in the diff; the changes are primarily for monitoring, metrics, and database/event-stream hygiene. A few places now use the current time instead of a previously stored request time when recording relay settlement, which is a behavioral change but not an obvious exploit.

This commit only adds a new test case to a JSON test file. It checks that Eclair correctly rejects a specific malformed BOLT 12 offer string whose Bech32 padding bits are invalid. There is no code change, no fix, and no behavior change in the application itself.

This commit only adds new test cases for an existing feature called 'accountability' in the Eclair Lightning node software. It does not change any production code, so it cannot introduce a new security vulnerability or directly fix one. The tests verify that invoice and payment onion data containing an 'UpgradeAccountability' marker are encoded and decoded correctly.

This change makes Eclair easier to run on Bitcoin test networks by using configured default transaction fee rates when Bitcoin Core cannot estimate fees due to limited block data. It also lowers the default fee rates to match current network conditions. This is a usability and operational improvement, not a security fix.

This is a routine GitHub Actions CI workflow change. It adds a build flag to disable an optional Bitcoin Core multiprocess feature that the project does not use, so that automated tests against the latest bitcoind version can compile without needing an extra dependency (capnproto). There is no change to Eclair's production code, no user-facing behavior change, and no security relevance.

This commit is a routine internal refactoring of Eclair's channel-lifecycle event system. It renames and splits events (for example replacing 'channel-opened' with 'channel-confirmed' and 'channel-ready') so the software can correctly track normal channels, zero-confirmation channels, and splice transactions. It also records more details in the audit database, such as the funding transaction ID for each splice. There is no direct security vulnerability in the diff; it is a maintainability and observability improvement.

This commit removes a database table that was used to store routine, mostly non-serious channel error events. It is a cleanup change: the events are still logged to normal log files, but they are no longer written to the audit database. There is no indication this fixes a security vulnerability; it is described by the project as a way to reduce database noise and storage use.

This commit fixes a bug where Eclair would keep advertising Lightning channels that had already been spent (for example, as part of a splice operation) while waiting for the spending transaction to be confirmed. This caused the node to send stale or misleading routing information to its peers, which looks like network spam and could confuse other nodes' routing decisions. The fix filters those spent-but-pending channels out of gossip broadcasts and immediately tells front-end nodes to stop relaying them.

This commit replaces an older 'endorsement' anti-jamming signal with a new 'accountable' signal for Lightning HTLCs, following a draft specification update. It changes how invoices, payment onions, and channel messages carry and propagate this signal. Importantly, the release notes state the protections are not yet enforced: the node only collects data and logs what it would have rejected. The change is a protocol update and data-collection feature, not an active enforcement that directly blocks payments today.

This change tightens validation of Bitcoin fallback addresses embedded in Lightning invoices (Bolt 11). Previously, Eclair would accept invoices containing fallback addresses that were malformed or invalid for the invoice's network. Now it rejects such invoices during decoding. This is a defensive correctness fix that prevents downstream bugs or confusion, but the commit itself does not describe a specific exploitable vulnerability.

This commit adds a new optional setting called maxCltvExpiryDelta to Eclair's route-finding APIs. It lets users tell the Lightning node not to return payment routes whose total time-lock delay exceeds a chosen limit. The change is a feature addition, not a fix for an active vulnerability, and it does not alter default behavior when the new parameter is omitted.

This is a tiny one-line bugfix in Eclair's code for spending funds sent to Lightning channel addresses. The change corrects which Bitcoin script is checked to decide whether a channel uses the newer taproot format. Previously it checked the script of the destination address the user provided; now it checks the script of the actual output being spent from the funding transaction. Using the wrong script could cause the code to choose the wrong spending path or signature scheme, potentially making it impossible to recover funds sent to a taproot channel address or, in the worst case, constructing an invalid or insecure transaction. There is no claim in the commit that this is a security issue, and the fix is a follow-up to a recently added feature, so it likely fixes a functional bug rather than an active vulnerability.

This commit updates Eclair to use a newer version of its underlying Bitcoin library (bitcoin-lib 0.46). The main change is a code refactor in how Taproot addresses and scripts are created: instead of passing an optional script tree, callers now explicitly choose between a 'key path' tweak (for simple key-spending) or a 'script path' tweak (for script-spending). The commit also updates related cryptographic checksums and test code. There is no direct evidence in the commit message or diff that this fixes a known security vulnerability; it appears to be a routine dependency and API refactor.

This commit fixes a performance and usability bug in the Eclair Lightning node. When the node learned about an old public channel that had already been closed, it would wastefully scan the entire Bitcoin blockchain looking for the closing transaction, which could be very slow and produced scary 'funds at risk' log messages even though no user funds were actually in danger. The fix makes the node simply check whether the channel output is already gone and, if so, remove the channel from its routing map without hunting for the closing transaction.

This commit lowers the maximum dust-limit Eclair will accept from a remote Lightning peer from 10,000 satoshis to 5,000 satoshis. Dust limits determine which tiny channel outputs can be created on-chain. The change is framed as a defensive tightening: with Eclair's default dust tolerance of 50,000 sats, it still allows at least 10 tiny HTLCs to be pending before the node stops relaying them. The commit message itself describes the change in security-relevant terms (preventing uneconomical on-chain HTLC claims), but the diff is a single configuration value change and does not fix an obvious, exploitable bug.

This commit fixes a routing bug in the Eclair Lightning node. When a payment failed somewhere along the path, the software used to identify the failing node only by its public key. That caused confusion when the same node appeared more than once in a route (for example, in circular rebalancing payments), because the wrong occurrence could be blamed. The fix adds the failing node's position (index) in the route so the correct hop is identified. This is a correctness/reliability improvement rather than a direct theft-of-funds vulnerability, but misidentifying the failing hop could lead to poor routing decisions, unnecessary retries, or incorrect blacklisting of channels/nodes.

This commit fixes a resource cleanup issue in the Eclair Lightning node. After a channel is upgraded via a 'splice' transaction, the old funding transaction output is permanently spent. Previously, Eclair kept watching that old output indefinitely if the channel stayed open and the peer stayed disconnected, wasting memory and processing power in the blockchain watcher. The change explicitly tells the watcher to stop watching those old, already-spent outputs. It also adds logging so operators can spot similar leftover watches. There is no direct evidence in the commit that this was exploitable to steal funds or attack other nodes; it appears to be a performance and robustness improvement.

This commit adds new API methods to let users spend funds that were accidentally sent to taproot-style Lightning channel addresses. It extends existing recovery tools to support a newer address format. There is no indication in the commit that this fixes a security vulnerability; it appears to be a feature addition.

This commit only updates two broken documentation links in markdown files. It does not change any program code, configuration, or security behavior. There is no security issue.

This commit adds a periodic log message to an internal bookkeeping actor so developers can spot if pending payment records are piling up unexpectedly. It does not fix a known bug or change how payments are processed; it is purely an observability/monitoring improvement.

This commit changes default settings and timing logic for a database cleanup task that removes old Lightning channel data after channels close. The old defaults deleted very large chunks very infrequently, which could slow down or stress busy nodes. The new defaults use smaller, more frequent deletions and avoid stacking up cleanup jobs when the database is already busy. There is no direct security vulnerability being patched; it is a performance and operational-stability improvement.

This commit raises the maximum dust limit Eclair will accept from remote Lightning peers from 600 to 10,000 satoshis. Dust limits determine the smallest transaction output a channel will create. The change is framed as a forward-compatibility and economic-spendability improvement for newer 'anchor output' channels, not as a security fix. It does not change Eclair's own dust limit (still 546 satoshis).

This is a routine dependency update for Eclair, a Bitcoin Lightning node. It bumps the internal 'bitcoin-lib' library from version 0.45 to 0.45.1 and its related 'bitcoin-kmp-jvm' component from 0.28.0 to 0.28.1. The commit message says the purpose is to add support for 'P2A PSBTs' (a new Bitcoin transaction format feature). The change only updates version numbers and recorded checksums; no application code is modified in this commit. There is no mention of a security fix, bug, or vulnerability.