Eclair

This commit changes how Eclair (a Bitcoin Lightning node) remembers its own closing signatures during a mutual channel close. Previously, the code re-generated signing nonces and re-signed closing transactions when the peer's signature arrived. Now it stores the original closing message and reuses its signatures. It also adds an early check that the peer's partial signature is valid before trying to build a final signed transaction. The change is a defensive correctness improvement rather than a clear fix for an active exploit.

This commit fixes two related bugs in how Eclair handles Lightning network 'ping' messages. First, it corrects an off-by-one error so pings asking for a 65532-byte reply are now ignored (matching the BOLT1 spec), instead of being answered. Second, it stops treating these 'reply-less' pings as a flood attack, so they no longer count toward the pending-ping limit that disconnects peers. The practical effect is that legitimate cover-traffic pings no longer risk getting a peer disconnected, and the protocol boundary now matches the specification.

This commit updates the Eclair Lightning node software to support a new, backwards-compatible draft of the official Bitcoin Lightning 'splicing' protocol. It adds a funding transaction identifier to commitment signatures and introduces a 'start_batch' message so peers know when multiple signatures belong together. It also keeps the older experimental batching mechanism for compatibility with older Phoenix wallets. The changes are primarily a protocol upgrade and compatibility shim, not a clear security fix, though they reduce ambiguity about which signature applies to which funding transaction during splices.

This commit adds a new testing-only module that uses a fuzzing tool called Jazzer to automatically throw random data at Eclair's Lightning message parsers. It does not change any production code, network behavior, or security logic. It is purely a defensive testing improvement.

This commit updates Eclair to use a newer version of its underlying Bitcoin library (bitcoin-lib 0.47). Most changes are mechanical: replacing local helper functions with new library-provided equivalents for encoding signatures and signing transaction inputs. There is no direct evidence in the commit message or diff that this fixes a specific security vulnerability, but it does touch cryptographic code and updates a dependency, which can sometimes address bugs or weaknesses in the library itself.

This patch fixes a bug in Eclair, a Bitcoin Lightning Network node implementation. Previously, if a peer sent a message that Eclair couldn't properly decode (for example, a corrupted or unexpected 'commit_sig' message), Eclair would log a warning but otherwise ignore it and keep processing later messages. This could cause the two peers' views of the channel state to drift out of sync, potentially leading to incorrect behavior or security issues. The fix makes Eclair send a warning back to the peer and immediately close the connection when it fails to decode a message it expected to understand.

This commit updates the PostgreSQL JDBC driver used by the Eclair Lightning node software from version 42.6.0 to 42.7.8, and also bumps the embedded PostgreSQL test library from 2.0.1 to 2.2.0. The accompanying checksum file is updated to match the new library versions and their transitive dependencies. The commit message frames this as a routine minor library upgrade. There is no direct code change in Eclair itself, and no explicit security advisory or CVE is referenced in the commit materials.

This commit is a refactoring and observability improvement for the Eclair Lightning node. It adds start/end timestamps to payment events and failures, renames some timestamp fields for consistency, and updates how payment hashes are derived from preimages. There is no direct security vulnerability visible in the diff; the changes are primarily for monitoring, metrics, and database/event-stream hygiene. A few places now use the current time instead of a previously stored request time when recording relay settlement, which is a behavioral change but not an obvious exploit.

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 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 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 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 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 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 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 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 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 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 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 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.

This is a large feature commit that adds support for a new kind of Bitcoin Lightning channel using Taproot and MuSig2 signatures. It changes how channels are opened, spliced, re-established after disconnections, and closed. The commit is primarily a protocol upgrade, not a stated security fix. However, because it touches sensitive signing logic and introduces new nonce handling, there is a moderate risk that mistakes in the new code could affect channel safety or allow a malicious peer to cause problems. The commit message does not describe this as fixing a known vulnerability.