Eclair

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.

This commit refactors how Eclair stores closed Lightning channels. Instead of keeping all closed channel data in the same table as active channels, it moves them to a dedicated table with only essential summary information. The main stated security benefit is preventing denial-of-service (DoS) attacks by not storing channels that were never properly opened or used. It also removes a database foreign-key constraint and changes the API response format for closed channels. The commit is primarily a data-model and migration change, not a fix for an active vulnerability.

This commit updates Eclair's underlying bitcoin-lib dependency from version 0.41 to 0.43.2 and adjusts Eclair's code to match the new library's API. The changes are mostly mechanical: switching how Musig2 nonces and Taproot script trees are represented, removing Kotlin-to-Scala conversion helpers, and updating Maven checksums. There is no explicit mention of a security fix in the commit message or diff, and no independent security advisory was supplied. The update could include upstream security fixes, but that is speculation based on the version bump, not direct evidence in this commit.

This commit fixes an accounting display bug in Eclair's balance reporting. When a mutual close transaction has been published or recently confirmed, the same funds could be counted both as 'closing' balance and as regular off-chain balance for a short time. The patch makes the off-chain balance exclude the channel in that situation, so the total shown to the user is not temporarily doubled. It does not move, lose, or expose any funds; it only changes how balances are reported.

This commit lowers a default setting that controls how many incoming connections Eclair will accept from strangers who have no payment channel with the node. The old default of 250 could let someone open a large number of connections to a routing node and waste its resources, a form of denial-of-service. The new default of 64 reduces that exposure while still allowing node operators to change the value if they need more for wallet-style services.

This commit fixes a wire-encoding bug in Eclair's Lightning splicing messages. The channel type field was being wrapped twice, which produced an incorrect byte layout. The fix removes the extra wrapper so the messages encode and decode correctly. It is a protocol-compatibility bug rather than a direct theft-of-funds vulnerability, but it could cause peers to reject or misinterpret splice messages.

This commit adds a new Lightning protocol feature bit called 'phoenix_zero_reserve' and simplifies how Eclair handles a Phoenix-specific taproot channel type. It is a feature addition and refactoring change, not a fix for a known security bug. There is no evidence in the commit or supplied references that this resolves an active vulnerability.

This commit tightens validation of Bitcoin Lightning 'Bolt 12' offers and invoices. Previously, an offer or invoice could include certain list fields (such as payment paths or supported chains) that were technically present but contained zero entries. The code now rejects these empty-but-present fields during parsing. The change prevents malformed or unpayable offers/invoices from being accepted, which could otherwise confuse wallets, break routing, or be used to probe implementations.

This commit removes an older, less effective way of choosing Lightning payment routes (called PaymentWeightRatios) and switches the code to use a newer route-scoring system based on estimated success probability. It is a routine cleanup/refactoring change, not a security fix. There is no evidence in the commit message or diff of a vulnerability being patched.

This update makes Eclair disconnect a Lightning peer if it sends more than one ping message before getting a reply. The goal is to stop a 'ping flood' attack, where a malicious peer could overwhelm the node with many ping requests and possibly cause it to run out of memory or become unresponsive. The change is defensive and includes a test showing the connection is closed when two pings arrive back-to-back.

This change fixes how Eclair counts time-lock delays when finding payment routes through the Lightning network. Previously, when calculating a route starting from the user's own node, the software ignored the delay on the first local channel. This could lead to choosing routes that look cheaper or faster but actually require longer lock-up times than expected, potentially causing payments to fail or funds to be locked longer than the user intended. The fix now always includes that first-channel delay in route calculations.

This commit fixes a bug in Eclair's dual-funded Lightning channel logic. When opening or splicing a channel using taproot (P2TR) inputs, each participant's wallet needs full details about every input in the transaction, not just its own. Previously, the PSBT (a data structure used to pass transaction signing information to the wallet) only included the shared splice input, but omitted the other peer's inputs. That caused the local wallet to fail when signing taproot inputs, because it couldn't compute the signature that covers all inputs. The fix adds all remote inputs to the PSBT before signing. The rest of the diff is mostly test cleanup: separate wallets for Alice and Bob and removal of an unused test helper.