Eclair

This commit only adds new test cases for an existing feature called 'accountability' in the Eclair Lightning node software. It does not change any production code, so it cannot introduce a new security vulnerability or directly fix one. The tests verify that invoice and payment onion data containing an 'UpgradeAccountability' marker are encoded and decoded correctly.

This is a routine GitHub Actions CI workflow change. It adds a build flag to disable an optional Bitcoin Core multiprocess feature that the project does not use, so that automated tests against the latest bitcoind version can compile without needing an extra dependency (capnproto). There is no change to Eclair's production code, no user-facing behavior change, and no security relevance.

This commit is a routine internal refactoring of Eclair's channel-lifecycle event system. It renames and splits events (for example replacing 'channel-opened' with 'channel-confirmed' and 'channel-ready') so the software can correctly track normal channels, zero-confirmation channels, and splice transactions. It also records more details in the audit database, such as the funding transaction ID for each splice. There is no direct security vulnerability in the diff; it is a maintainability and observability improvement.

This commit replaces an older 'endorsement' anti-jamming signal with a new 'accountable' signal for Lightning HTLCs, following a draft specification update. It changes how invoices, payment onions, and channel messages carry and propagate this signal. Importantly, the release notes state the protections are not yet enforced: the node only collects data and logs what it would have rejected. The change is a protocol update and data-collection feature, not an active enforcement that directly blocks payments today.

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 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 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 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 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 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 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 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 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 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 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 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 adds a missing validation rule for a type of Bitcoin Lightning payment request called a BOLT12 offer. Previously, Eclair would accept offers that named a fiat currency (like USD) but did not include an amount. That combination is invalid according to the Lightning specification, because a currency without an amount is meaningless. The fix rejects such malformed offers and adds a test case. The main risk is that an attacker could trick a node into accepting or acting on an ambiguous offer, potentially leading to incorrect pricing, payment routing confusion, or interoperability failures with other implementations.