Eclair

This commit is a routine post-release housekeeping change. It bumps the project version from 0.14.3 to 0.15.0-SNAPSHOT across several build files, re-enables a Maven trusted-checksum feature used for build verification, adds a placeholder release-notes document, and deliberately prevents accidental startup of the new development snapshot by throwing an error unless a special override flag is set. There is no security vulnerability in this commit.

This change expands when Eclair will allow password-based authentication to a Tor control port. Previously, only loopback addresses (the same machine) were considered safe enough for password auth. Now, private/site-local and link-local networks are also treated as local, so password auth is permitted there too. This is intentional for cluster deployments, but it slightly relaxes a security boundary around how Eclair talks to Tor.

This commit is a routine post-release housekeeping change. It bumps the project version from 0.14.2 to 0.15.0-SNAPSHOT, re-enables a Maven trusted-checksum feature used for build verification, adds a placeholder release-notes file, and deliberately prevents the new development snapshot from starting in production by throwing an error unless a special override flag is set. There is no security vulnerability here; the change is a safety guard, not a flaw.

This change makes the Eclair Lightning node force-close a payment channel if a peer tries to add a payment whose timeout value (cltv_expiry) is 500,000,000 or higher. Such large values are invalid according to the Lightning BOLT 2 specification because they would be interpreted as a Unix timestamp rather than a Bitcoin block height, which could confuse the node and lead to incorrect fund-locking behavior. Previously Eclair rejected these values without force-closing; now it explicitly closes the channel as the spec recommends.

This commit fixes five low-severity security or robustness issues in the Eclair Lightning node. It removes a risky type cast that could crash the node on corrupted channel data, forces encrypted cluster communication to prevent private data exposure, stops API error messages from leaking internal details, and makes onion message handling more resistant to spam by ignoring unknown data fields and limiting how many times a node can be inserted into a message path.

This commit fixes a bug in how Eclair handles 'liquidity ads' data embedded in Lightning node announcements. Previously, if a peer broadcast a node_announcement containing a liquidity-ads field with empty funding rates or empty payment types, the node could not re-encode the message correctly, which could cause it to relay or store invalid gossip. The patch now rejects such malformed announcements immediately. It also improves codec performance by storing the raw payment-type bitfield instead of eagerly decoding unknown payment types.

This commit is a routine post-release housekeeping change. It bumps the project version from 0.14.1 to 0.15.0-SNAPSHOT, re-enables a Maven trusted-checksum feature used for build verification, adds a placeholder release-notes file, and includes a safety guard that refuses to start the development snapshot unless a special override flag is set. There is no security vulnerability in the diff itself; the startup guard is an intentional protective measure, not an exploit.

This commit hardens the Eclair Lightning node against two related problems when opening payment channels: it prevents the same channel ID from being reused by two different channels at the same time, and it aborts channel creation if the very first database write fails (for example because a channel with that ID already exists from a backup). Before this change, a colliding or partially-restored channel ID could cause one channel's state to overwrite another's, potentially leading to loss of funds or an inconsistent node state.

This commit loosens Eclair's validation of BOLT12 invoice onion messages so that invoices may now include a reply path. Previously, Eclair rejected invoices that carried a reply path, which caused compatibility problems with LDK nodes. The change is framed as an interoperability fix, not a security fix, and it tightens some related validation rules at the same time.

This commit is a routine post-release housekeeping change. It bumps the software version from 0.14.0 to 0.15.0-SNAPSHOT across build files, creates a placeholder for future release notes, re-enables a Maven trusted-checksum feature used for build verification, and adds an explicit safety guard that refuses to start the node unless a special override flag is set. There is no vulnerability fix or security flaw introduced in the diff itself.

This commit updates the Eclair Lightning node software to use the official protocol feature bit and name for a new kind of Bitcoin payment channel called 'taproot channels.' It turns taproot channel support on by default, but only for private (unannounced) channels, because the public-announcement rules are not finalized. The change is mostly a rename and feature-bit swap from an earlier experimental/staging version, plus adding guards so users cannot accidentally open a public taproot channel. It is a protocol-alignment change, not a fix for an active security bug.

This commit only changes a test file to make an integration test less flaky by retrying a condition until two nodes' routing data match. It does not modify production code, so it has no direct security impact on real Eclair users.

This commit only adds new automated fuzz tests for Lightning Network message and onion-payload codecs. It does not change any production code, so it cannot introduce a runtime vulnerability by itself. The tests are designed to catch crashes or inconsistent encoding/decoding in existing codec code by feeding them random bytes.

This commit fixes a flaky automated test and, as a side effect, changes several PostgreSQL database queries to exclude the upper time bound instead of including it. The change is described by the author as a correctness fix for pagination, not a security fix. There is no direct evidence of an exploitable vulnerability.

This commit adds a new optional 'peer profit scoring' feature to the Eclair Lightning node. When enabled, it automatically tracks payment statistics, ranks peers by profitability, and can automatically open channels, close idle channels, and adjust relay fees. By default all automatic actions are disabled, so the change is primarily an operational automation feature rather than an immediate security patch or vulnerability. The main security consideration is that enabling the automatic actions gives the node software control over on-chain funds and channel pricing, which could in theory be abused or misconfigured, but the commit itself does not introduce a known exploit.

This commit fixes a timing bug in Eclair's message-delivery component called Postman. When sending an onion message that expects a reply, the code used to register for the reply *after* sending the message. In fast local tests (and potentially fast real networks), the reply could arrive before the registration completed, causing the reply to be lost. The fix registers the subscription *before* sending the message. The commit describes this as a test flakiness issue, not a security vulnerability.

This commit adds a new helper function that lets Eclair ask Bitcoin Core whether a given bitcoin address belongs to the user's own wallet. It is a feature addition with no visible bug fix or security patch. There is no indication in the commit that it fixes a vulnerability.

This commit fixes a bug where Eclair did not correctly recognize custom features added by plugins when checking if another node supports them. Previously, plugin features were treated as 'unknown' and `hasFeature` always returned false for them, even when both nodes supported the same plugin feature. The change stores the raw feature bits after decoding and uses them in feature checks, while removing the old 'UnknownFeature' class. It is a correctness and compatibility improvement rather than a critical security patch, but it could affect whether nodes agree on required features during connection.

This commit fixes a flaky automated test in the Eclair Lightning node software. It adds a wait step so that test nodes have time to learn about network channels before the test proceeds. There is no security issue here—only a test reliability improvement.

This commit tightens validation of Lightning Network 'offers' (a way for a merchant to publish a payment request). Previously, an offer could include an amount field set to zero, which the protocol designers consider invalid and confusing. The change makes Eclair reject such offers. The main risk is that an attacker or buggy peer could send a zero-amount offer and, before this patch, Eclair might have accepted or processed it in an unintended way. The commit itself is a straightforward validation fix and does not show an active exploit.

This commit removes the ability of the Eclair Lightning node to receive zlib-compressed channel-query data from peers. The Lightning protocol spec dropped zlib compression for these messages some time ago, and this change catches up by rejecting or ignoring compressed encodings. It is a hardening/cleanup change rather than a fix for an active vulnerability, though keeping a deprecated decompression path could in theory expose a node to memory or CPU issues if a peer sent malicious compressed data.

This commit adds a new notification event called ChannelFundingCreated to the Eclair Lightning node. It tells external listeners when a channel funding or splice transaction has been signed and is ready to be published. The change is purely additive: it emits an event at existing points in the code and exposes it over the WebSocket API. It does not alter security-critical logic such as transaction signing, validation, or channel state transitions. The release notes explicitly say the event is handy for detecting peers that use black-listed inputs so operators can close the channel early, but that is a monitoring/operational use case, not a vulnerability fix.

This commit only changes test code. It fixes flaky automated tests in the Eclair Lightning node by introducing a fake wallet that never completes funding transactions, so tests can reliably simulate error events during channel funding. There is no change to production code and no security vulnerability is being fixed or introduced.

This commit is a routine refactoring of internal event definitions in the Eclair Lightning node. It changes how channel and payment events are structured so they carry more detailed information (such as splitting mining fees into local and remote portions, adding timestamps, and exposing relay fees). There is no direct evidence in the commit that these changes fix a security vulnerability; they appear to be observability and accounting improvements.

This commit is a refactoring and observability improvement for the Eclair Lightning node. It adds the node identifier (node_id) of channel peers to various payment events and restructures how payment events are represented in code. It does not fix a security vulnerability, nor does it introduce obvious new attack surface. The database schema is intentionally not yet updated, so some stored data uses a placeholder node_id. The change touches many files but is mostly internal plumbing for metrics and audit logging.