Eclair

This commit adds a new optional plugin hook that lets Eclair node operators write custom checks for Bitcoin transactions used in Lightning channel funding or splicing. It is a defensive feature, not a vulnerability fix. The same change also improves error messages when a transaction is rejected and slightly refactors how input confirmation checks are run. There is no evidence in the commit of an active security bug being patched.

This commit adds an optional setting that lets node operators disable an automatic fee refresh for existing payment channels when Eclair restarts. By default, the old behavior is preserved (fees are still refreshed). The change is framed as a performance improvement for operators with hundreds of channels, not as a security fix. There is no direct evidence in the commit that this resolves a vulnerability or that an attacker can exploit the old behavior.

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 changes how Eclair (a Bitcoin Lightning node) loads stored peer data when the node restarts. Previously, every peer's stored data was read from the database immediately at startup. Now it is loaded only when the peer first reconnects. The stated goal is to avoid a 'herd effect'—a large burst of database reads all at once after a restart. There is no direct security vulnerability in the diff; it is a performance and reliability improvement. The change does not alter who can request data or what data is stored.

This commit fixes a bug where Eclair would automatically enable a feature called `scid_alias` for public Lightning Network channels, even though the Lightning protocol rules (BOLTs) only allow that feature for unannounced (private) channels. Public channels with `scid_alias` could violate protocol rules and cause interoperability or routing problems, though it is not a direct theft-of-funds vulnerability.

This commit adds a documentation file called CLAUDE.md that gives the Claude AI coding assistant general context about the Eclair Lightning Network project. It contains no code changes, no configuration changes, and nothing that affects how the software runs or processes data. It is purely informational for AI-assisted development.

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 simply adds a new pattern to the project's .gitignore file so that files and folders created by the Claude AI assistant are not accidentally committed to the repository. It has no security relevance to the Eclair Lightning node software itself.

This commit changes how Eclair selects a Lightning channel type when opening a channel automatically. Previously, the caller had to explicitly provide a channel type. Now, if no type is provided, Eclair will automatically pick a preferred type based on what both the local node and the remote peer support. If no compatible type can be found, the channel opening is rejected. This is a feature improvement, not a security fix, and the commit message does not describe it as fixing a vulnerability.

This commit only changes test code. It fixes flaky balance fuzz tests in Eclair by giving simulated channels more starting money so they can afford higher transaction fees under anchor outputs. There is no change to production code, no real-world security fix, and no vulnerability being patched.

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 only improves monitoring/observability. It adds a new label ('error-type') to internal error-counting metrics so developers can see what kind of channel errors are happening, in addition to whether they came from the local node or a remote peer. There is no user-facing behavior change, no bug fix in business logic, and no security fix.

This commit changes how Eclair lightning nodes pick which outgoing channel to use when forwarding payments. The new logic prefers private (unannounced) channels first, then smaller public channels, to avoid draining or disabling the larger public channels that other nodes rely on for routing. It is a routing-optimization and operational-hardening change rather than a fix for a known exploit. The commit message explicitly frames the change as avoiding public-channel exhaustion and disabled channel_updates, which has indirect security relevance for node availability and routing reputation.

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 adds new internal event notifications when a Lightning payment cannot be relayed through a node. It is a defensive, observability-only change: it does not alter payment handling logic, but gives node operators signals they can use to decide where to allocate channel liquidity. The commit message explicitly warns that the events can be gamed by malicious senders and should not be acted on blindly.

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.

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 only adds a new test case to a JSON test file. It checks that Eclair correctly rejects a specific malformed BOLT 12 offer string whose Bech32 padding bits are invalid. There is no code change, no fix, and no behavior change in the application itself.

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 change makes Eclair easier to run on Bitcoin test networks by using configured default transaction fee rates when Bitcoin Core cannot estimate fees due to limited block data. It also lowers the default fee rates to match current network conditions. This is a usability and operational improvement, not a security fix.

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 removes a database table that was used to store routine, mostly non-serious channel error events. It is a cleanup change: the events are still logged to normal log files, but they are no longer written to the audit database. There is no indication this fixes a security vulnerability; it is described by the project as a way to reduce database noise and storage use.

This commit fixes a bug where Eclair would keep advertising Lightning channels that had already been spent (for example, as part of a splice operation) while waiting for the spending transaction to be confirmed. This caused the node to send stale or misleading routing information to its peers, which looks like network spam and could confuse other nodes' routing decisions. The fix filters those spent-but-pending channels out of gossip broadcasts and immediately tells front-end nodes to stop relaying them.

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.