Eclair

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.

This commit only changes test configuration and test code. It increases the timeout used in automated tests for onion message handling from milliseconds to seconds, and adds a way for one specific test to keep using a very short timeout. There is no change to production code, no security fix, and no vulnerability.

This commit fixes a bug in Eclair's Lightning payment channels that use the newer taproot format. When two nodes reconnect after a temporary network interruption, the local node used to resend the exact same cryptographic signature it had sent before. For taproot channels, the remote peer may choose a fresh random 'nonce' after reconnecting, which makes the old signature invalid. The fix makes the local node re-sign the next commitment using the latest nonces received during reconnection, preventing the channel from getting stuck or failing to advance after reconnect.

This commit only adds extra checks to a test file to make an existing integration test more reliable. It does not change production code, user-facing behavior, or any security mechanism. There is no security issue here.

This commit fixes a flaky automated test and makes a tiny production-code ordering change. The main code now subscribes to 'HTLC settled' events before 'HTLC added' events, so a very brief race during startup cannot leave a payment stuck. The rest of the change only alters test code to avoid using the event bus in tests, which removes test flakiness. There is no direct evidence this is a security vulnerability or that it was exploited.

This commit adjusts the estimated transaction size (weight) Eclair reserves when closing or updating Taproot Lightning channels. It makes Eclair's estimate match lnd's more pessimistic assumption about how many bytes are needed to count transaction inputs and outputs. If the estimate is too low, a channel partner could be forced to pay unexpectedly high on-chain fees or a cooperative close could fail; if too high, funds get locked up longer than necessary. The change is a small numeric tweak from 960 to 968, not a clear-cut vulnerability fix.

This commit is a large cleanup of old code in the Eclair Lightning node software. It removes support for reading very old channel data formats (before version 0.13) and removes the built-in tool that migrated data from SQLite to PostgreSQL. The change is intentional and documented: users on versions older than 0.13 must first upgrade to 0.13, which will convert their data, before installing this newer version. There is no evidence of a security vulnerability being introduced; the main risk is that an unprepared operator could accidentally make their node fail to start by skipping the required intermediate upgrade.

This commit simply updates Eclair's required Bitcoin Core version from 28.1 to 29.1. It changes download URLs, version checks, documentation, and adjusts a couple of test expectations to match Bitcoin Core 29.1's behavior. There is no security vulnerability in this change.

This commit is a routine post-release housekeeping change. It bumps the project version from 0.13.0 to 0.14.0-SNAPSHOT, re-enables a Maven trusted-checksum feature used for build verification, creates a placeholder release notes file, and adds a safety guard in the startup code that refuses to run development snapshot builds unless a special override flag is set. None of these changes fix or introduce a security vulnerability; the startup guard is a deliberate safety measure, not a bug.

This commit is a routine version-bump release for Eclair v0.13.0. It updates Maven project versions from 0.13.0-SNAPSHOT to 0.13.0, removes a temporary startup safety guard that blocked the previous development build from running, adds the release notes, and disables Maven's trusted-checksum post-processor (with a note on how to re-enable recording). There is no security patch or vulnerability fix in the diff itself.

This commit fixes a flaky test, not a security issue. The test simulates three Lightning nodes (Alice, Bob, Carol) and previously did not give all nodes complete knowledge of each other's funding transactions. The change makes the test setup more consistent so the test passes reliably. There is no production code change and no security impact.

This commit only adds a new test case to Eclair's invoice parsing tests. It checks that a specific Bitcoin Lightning invoice with a non-standard 'high-S' signature can still be decoded and that the sender's public key is recovered correctly. There is no code change to the actual invoice handling logic.

This commit removes a technical rule that required a specific Lightning feature flag (simple close) to be enabled whenever another experimental taproot feature flag (taproot staging) was enabled. Some lnd nodes were setting taproot staging without also setting simple close, causing Eclair nodes to disconnect from them. The change makes Eclair more tolerant of this behavior for the staging feature bit, while keeping the stricter rule for the final taproot feature bit. It is a compatibility/interoperability fix, not a security patch.

This commit fixes how the Eclair Lightning node compares its on-chain Bitcoin funds (UTXOs) when computing balance changes. Previously, it compared entire UTXO objects, which include fields that can change even when the same coin is still owned (for example, confirmation count). This could cause the node to incorrectly think UTXOs were added or removed, producing noisy or misleading balance logs and metrics. The fix compares UTXOs only by their unique identifier (outPoint), which is the correct way to tell whether the same coin is still present. There is no direct evidence in the commit that this is exploitable by an attacker or that it causes loss of funds.

This patch fixes a state-handling bug in Eclair, a Bitcoin Lightning Network node implementation. When a new dual-funded channel was stuck waiting for both parties to sign, and the node went offline, a force-close command was silently ignored. The fix makes the node properly abort the channel and roll back the funding transaction attempt, preventing funds from being left in limbo.