Eclair

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.

This commit is a pure code cleanup: it replaces nested constructor calls like FeeratePerKw(FeeratePerByte(x)) with new helper methods like x.perKw. The math and behavior are unchanged; only the syntax is shorter and more readable.

This commit is a planned database migration for the Eclair Lightning node software. When users upgrade, it automatically re-encodes all stored payment-channel data to a newer internal format (v5). The change also warns users that older 'non-anchor' channels will no longer be supported in the next release and should be closed. There is no direct security vulnerability in the patch itself; it is a cleanup step to let the developers remove legacy code later.

This commit improves Eclair's Lightning payment routing by optionally using past payment successes and failures to estimate how much money each channel can forward, instead of assuming balances are random. It is a feature enhancement, not a security patch. There is no indication in the commit or supplied references that it fixes a vulnerability.

This commit changes the Eclair Lightning node software so that either party—not just the channel opener—can propose a fee bump (RBF) during dual-funded channel creation. It also adds a guard to prevent the non-opener from overriding a liquidity purchase. The change is a feature alignment with splicing behavior, not a reported security fix, and the commit message does not describe any vulnerability.

This commit adds an optional API parameter to the Eclair Lightning node that lets an operator override the maximum on-chain fee rate when force-closing a channel. It is a feature enhancement, not a fix for a known vulnerability. The change gives node operators more control over how quickly force-close transactions confirm, but it does not by itself create a way for an outsider to steal funds or take over the node. The main security consideration is that a user who sets the override too high could pay unexpectedly large transaction fees during a force close.

This commit fixes a data migration bug in the Eclair Lightning node. When older channel data is upgraded to a newer storage format, the code now uses the actual commit transaction input to identify the channel's funding output, instead of relying on the shortChannelId. The old approach could pick the wrong output for private channels where the shortChannelId is not reliably set, potentially leading to incorrect channel state after an upgrade.

This commit tweaks how Eclair nodes request network routing gossip from peers. It subtracts one minute from the starting timestamp filter so that very recent routing announcements that haven't yet reached the peer are still forwarded. The change is described by the authors as fixing flaky tests rather than a real-world security bug, and it slightly reduces the chance of a node missing fresh channel updates during sync.

This commit fixes a Lightning Network channel bug where, after a disconnect, one side could re-send an outdated 'batch_size' value in commitment signature messages. The peer would then wait forever for extra messages that no longer exist, causing the payment channel to stall. The fix recalculates the correct batch size from the current active commitments before retransmission.

This is a small internal maintenance patch for the Eclair Lightning node. It changes an experimental message code number to avoid clashing with another in-development feature, and it starts recording which previous transaction inputs were spent by confirmed funding transactions. There is no direct security fix for a currently exploitable bug; it is preparation/cleanup for feature branches.

This commit refactors how cryptographic nonces are packaged inside a Lightning protocol message called tx_complete. Previously, two unrelated nonce types were bundled together; now they are split into separate optional data fields. The change is a protocol cleanup and does not by itself fix a known exploit, but it removes a design ambiguity that could lead to incorrect nonce handling during taproot channel funding or splicing.

This commit changes how Eclair handles taproot channel splicing. Normally, when two parties build a shared Bitcoin transaction together, each must send the full previous transaction that created the coins being spent. For taproot channels, the commit allows sending only the relevant output details instead, because taproot signatures already protect against a specific malleability trick. The change is framed as a bandwidth optimization and is restricted to taproot splicing to preserve security guarantees.