Eclair

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.

This commit is a routine post-release housekeeping change. It bumps the project version from 0.13.1 to 0.14.0-SNAPSHOT, re-enables Maven trusted checksum verification for development builds, adds a placeholder release notes file, and intentionally prevents accidental production use of the new development snapshot by refusing to start unless a special override flag is set. There is no security vulnerability here.

This commit is a routine version-bump release tag for Eclair v0.13.1. It updates version numbers in Maven project files, finalizes release notes, removes a temporary 'unsafe startup' guard that was only meant for pre-release development builds, and tightens some error messages about upgrade requirements. There is no security patch or vulnerability fix visible in the diff itself.

This commit changes how Eclair picks which network address to use when reconnecting to another Lightning node. It makes the choice more flexible when a Tor proxy is configured: instead of always preferring Tor when available, it now lets clearnet IPv4/IPv6 addresses be used directly when the proxy is set to only handle Tor. This is a configuration/logic improvement, not a clear-cut security fix or vulnerability.

This commit updates Eclair's Bitcoin Core integration to use taproot (bech32m) addresses by default and fixes a fee-calculation bug where the anchor output amount was not being counted. The fee bug caused on-chain fees to be undercounted by 330 satoshis, which was previously hidden by test tolerances but surfaced when switching to smaller taproot inputs. The fix is in the ReplaceableTxFunder component, which funds transactions for force-closing Lightning channels. There is no evidence this was a remotely exploitable vulnerability; it is best characterized as a correctness/robustness fix that could lead to slightly overpaying on-chain fees.

This commit simply bumps the project's `bitcoin-lib` dependency from version 0.44 to 0.45 and updates the corresponding cryptographic library checksums. The commit message says the new version changes how the app binds to the secp256k1 library and adds support for a new Bitcoin output type called P2A. There is no code change in this repository itself, and no security fix or vulnerability is mentioned.

This commit simply updates the version of Bitcoin Core used by Eclair's automated tests from 29.1 to 29.2, along with the matching download URLs and SHA-256 checksums. It does not change Eclair's own production code or introduce any security vulnerability in Eclair. It is a routine dependency bump for the test suite.

This commit fixes a bug in Eclair's on-the-fly funding feature where a payment fee could be calculated as a negative number. The patch hard-codes a minimum HTLC value used by Phoenix and prevents the fee from dropping below zero. It is a defensive fix that avoids later validation failures rather than a clear exploitable vulnerability.

This change tightens which Bitcoin transactions Eclair remembers after a Lightning channel closes. Previously, Eclair might have recorded remote 'anchor' transactions that spend the commitment transaction, even though those transactions don't belong to the node. Now it only records transactions that spend outputs the node actually cares about. The main risk is that storing the wrong transactions could have led to incorrect channel-state tracking, possibly affecting fee bumping or recovery logic, but the commit itself does not describe an active exploit or loss of funds.

This commit removes the storage of Bitcoin 'anchor' transactions inside Lightning channel state and stops re-watching those anchor outputs after the commitment transaction is confirmed. The stated goal is to save database space and avoid redundant work. The change also tweaks how the code decides whether a transaction is 'relevant' to a closing channel, explicitly excluding anchor outputs from being treated as spending the commitment transaction. There is no direct evidence in the commit that this fixes an active security bug, but it does reduce the surface area for state-mismatch and watch-related edge cases during channel closes.

This commit changes how the Eclair Lightning node splits a single large payment across multiple routes. It adds a new optional strategy that tries to maximize the expected amount that actually gets delivered, and refactors the existing random and full-capacity strategies. There is no direct evidence in the commit that this fixes a security vulnerability; it reads as a routing/performance improvement.

This commit simply updates the project's dependency on ACINQ's bitcoin-lib library from version 0.43.2 to 0.44, along with matching updates to related cryptographic libraries (secp256k1-kmp) and their checksums. The change itself is a routine version bump in the build file. There is no direct code change shown, and the commit message does not say this is a security fix. Because we have no release notes or changelog for bitcoin-lib 0.44, we cannot tell from this diff alone whether the new version fixes a security issue or introduces one. It is a dependency change that could affect how the Lightning node handles Bitcoin transactions and signatures, so it deserves review, but the diff does not prove any vulnerability.

This patch fixes a bug in the Eclair Lightning node that occurs when a channel is closing using the newer Taproot channel type and the connection drops after a shutdown message was sent. On reconnection, the node must resend shutdown, but it was reusing an old cryptographic nonce. For Taproot, each shutdown needs a fresh nonce, and the node must keep the matching private nonce to later sign the closing transaction. Without the fix, the node could be unable to produce its closing signature after reconnecting, potentially stalling or complicating mutual channel closure.

This commit contains two tiny cleanups: it fixes the order of flags in a shell command example in build documentation, and removes decorative ASCII table borders from a code comment describing the layout of an encrypted failure message. Neither change alters program behavior or fixes a security issue.

This commit only changes test code. It adds a 'zero-conf' test tag and adjusts assertions so that Phoenix taproot channel tests correctly exercise zero-confirmation funding scenarios. There is no change to production code, so it cannot directly affect live users or funds.