Eclair

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.

This commit adjusts how Eclair estimates the 'weight' (a measure of transaction size used to calculate Bitcoin mining fees) for funding inputs in Lightning channel transactions. It increases the assumed signature size from 72 to 73 bytes, matching what the Lightning specification recommends and what other implementations like LDK use. The change is defensive: it helps prevent Eclair's interactive transaction proposals from being rejected by peers who think Eclair is under-paying fees, and it avoids edge cases where miners might accept a slightly larger signature than Eclair accounted for.

This commit fixes a bug in Eclair, a Bitcoin Lightning Network node implementation. When a user tried to buy extra spending capacity (a 'liquidity purchase') and the remote peer backed out after the local node had already signed, Eclair kept the related incoming payments stuck in limbo until they nearly expired. The patch makes Eclair immediately fail those stuck payments when the peer aborts, which is fairer to honest senders and avoids unnecessary delays. It is a correctness/availability improvement rather than a direct theft-of-funds vulnerability.

This commit adds a server-side check to make sure users cannot set negative Lightning Network routing fees through the API. Previously, the API accepted negative values for base and proportional relay fees, which could cause a node to pay others when forwarding payments or create confusing, loss-inducing channel policies. The fix rejects such inputs with a validation error.

This commit adds a new internal-only message format called CommitSigBatch so that Eclair nodes running in cluster mode can send groups of commit_sig messages between internal machines. It is not a change to the public Lightning network protocol; peers still receive commit_sig messages one at a time. The change is a straightforward codec addition with a matching unit test.

This commit is a routine observability/monitoring change. It renames a few internal actor identifiers (for example from 'zmqblock' to 'zmq-block') and adds a Kamon monitoring configuration so that specific singleton actors report their mailbox size. There is no security fix or vulnerability present in the diff.

This commit only adds extra logging messages around Lightning channel commitment signatures. It does not change any security logic, validation rules, or cryptographic checks. The goal is to make debugging easier when a peer's signature is rejected, which can sometimes lead to a channel force-close. There is no vulnerability being fixed here.

This commit is a small cleanup pull request titled 'Nits'. It fixes a typo in documentation, corrects a log message to show the right commitment format name, changes a debug log to info level for transaction signing, adds structured logging context for authenticated peer connections, and removes an outdated ASCII diagram comment. None of these changes affect security.

This commit only widens the allowed margin in a test assertion about DER-encoded ECDSA signature sizes, from plus/minus 2 bytes to plus/minus 3 bytes. It is a test-only change and does not alter production code, transaction validation, or cryptographic handling.

This change adjusts how Eclair sets on-chain fees for channels with mobile wallets (specifically Phoenix). Instead of repeatedly sending fee-update messages and using higher feerates, it now pins the commitment transaction feerate to 1 satoshi per byte and stops sending update_fee for those channels. The goal is to simplify fee handling during complex operations like splicing and shutdown, relying on Bitcoin's package relay to still allow force-closes to propagate. The commit notes a trade-off: mobile wallets without their own on-chain funds may struggle to confirm force-close transactions via CPFP, but that was already the case because the LSP (the node running Eclair) controlled the feerate anyway.

This commit removes support for older Lightning channel types ('static_remotekey' and 'default' channels) from the Eclair node software. It is a deliberate feature-removal change announced in the previous release. The main risk is operational: node operators who still have legacy channels and upgrade to this version will find Eclair fails to start, potentially leaving them unable to manage funds until those channels are closed with an older version. The patch also simplifies fee-rate handling because anchor-style channels handle fees differently, and it removes wallet-public-key caching code that was only needed for the obsolete channel types.

This commit changes Eclair's database startup checks so that the node refuses to start unless the operator has already run the v0.13.0 and v0.13.1 releases to migrate channel data. The migration code that used to run automatically when Eclair started has been removed from the startup path and replaced with a hard requirement. This is a defensive, operational-safety change, not a remotely exploitable vulnerability fix. It prevents accidental data loss for operators who skip intermediate releases, but it does not patch a security bug that an attacker could abuse.