Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This commit updates Eclair's underlying Bitcoin library from version 0.47 to 0.48 and makes small code adjustments to match the new library's API. The changes touch how private keys are derived and how test data is converted. There is no d…
Dependency version bump of cryptographic Bitcoin libraryPrivate key derivation code modifiedTaproot/MuSig2 test vector code adjusted
This commit adds an experimental new Lightning channel type to Eclair called 'zero-fee commitments.' It is a large feature patch implementing a draft BOLT specification (PR 1228), not a fix for a known vulnerability. The change introduces …
Large feature addition (+1618/-276 across 42 files) touching consensus-sensitive transaction construction and signingNew experimental channel type disabled by default; requires explicit opt-in via eclair.confImplements draft BOLT specification (lightning/bolts#1228), not a finalized standard
This commit updates the PostgreSQL database driver used by the Eclair Lightning node software from version 42.7.8 to 42.7.11. The commit message says this fixes a vulnerability that could allow denial-of-service (DoS) attacks if a node con…
Dependency version bump for security fixVendor-disclosed potential DoS vector via untrusted database hostChecksum file updated for reproducible builds
This commit only adjusts a flaky unit test that checks transaction weight estimates. It widens the allowed tolerance for variable-length ECDSA signatures when two signatures are involved instead of one. There is no change to production cod…
This commit adds official Lightning channel splicing support to Eclair and replaces an experimental protocol. It includes backwards-compatibility shims for older Phoenix wallets, changes how reconnection messages request retransmission of …
Protocol state machine changes for interactive transaction signing and reconnection retransmissionBackwards-compatibility shim that multiplexes two protocol versions based on peer feature bitsTLV type-number collision handling between official and experimental splicing protocols
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 arr…
MuSig2 nonce handling changed: local partial signatures are now stored and reused instead of regeneratedEarly signature validation added for peer's partial signature before final transaction aggregationRemoved CloserNonces helper that generated three random nonces per closing attempt
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 '…
Adds disambiguation of commitment signatures by funding transaction ID, reducing risk of applying a signature to the wrong commitment during multi-funding splicingIntroduces a new odd-length message (start_batch) and odd TLV (FundingTx), which unknown peers should ignore per Lightning spec conventionsMaintains legacy experimental batch TLV for backwards compatibility
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 …
New test-only fuzzing module addedNo production code changesNo network-facing or cryptographic logic modified
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…
Dependency version bump for bitcoin-lib and secp256k1-kmpRefactor of ECDSA signature encoding/signing code pathsRemoval of local DER conversion helpers in favor of library-provided methods
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 derive…
Refactoring of payment event data model with new timestamp fieldsPayment hash now derived from preimage instead of passed separatelyRemoval of WaitingToRelayPayment from JSON type hints
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, caller…
Dependency version bump (bitcoin-lib 0.45.1 -> 0.46)Taproot script construction API refactorNo explicit security claim in commit message or diff
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 th…
Dependency version bump onlyNo source code changes in commitNo security-related wording in commit message or diff
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, …
Fee-estimation mismatch between implementations could cause interactive-tx negotiation failuresUnder-estimated weight could lead to insufficient fees if a 73-byte high-S signature is accepted by minersChange aligns with BOLT 3 recommendation and LDK behavior
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 ke…
Fixes a denial-of-service / availability issue where upstream HTLCs were held until near CLTV expiry after a peer-aborted liquidity purchaseAdds explicit handling for tx_abort after local signing in dual-funded opens and splicesIntroduces LiquidityPurchaseAborted event and matching cleanup in Peer
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 loggin…
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 operatio…
Removal of legacy commitment format support reduces attack surface for fee-manipulation and transaction-malleability issues present in pre-anchor channels.Simplified fee tolerance removes the 'too low' feerate check, relying on anchor/taproot CPFP/RBF behavior.Explicit channel_type requirement prevents silent downgrade to weaker channel types.
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…
DoS mitigation: channels that never confirmed or had nothing at stake are no longer persisted in the databaseDatabase schema migration removes foreign key constraint on htlc_infosNew closed-channel data class stores only minimal, stringified fields to avoid future backwards-compatibility issues
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 ar…
Dependency version bump of core cryptographic library (bitcoin-lib 0.41 -> 0.43.2, secp256k1-kmp 0.18.0 -> 0.19.0)Refactoring of MuSig2 nonce handling and Taproot script tree constructionRemoval of Kotlin interop conversions around cryptographic types
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. P…
Fixes a signing failure in taproot interactive dual-funding/splicingPSBT now includes all remote inputs, satisfying BIP-341 all-inputs signature commitmentPreviously tests hid the bug by sharing a single dummy wallet between both parties
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 correctl…
Test-only change: no production code modifiedRelates to BOLT 11 signature malleability / high-S acceptanceReferences upstream BOLT specification change (bolts PR 1284)
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Security candidateAdd `DATA_CLOSED` class when active channel is closed (#3170)by Bastien Teinturier · 16a309e4 · Sep 30, 2025 · 26 filesMessage 81 · StrongLow 29Details
Commit message · Bastien Teinturier
Add `DATA_CLOSED` class when active channel is closed (#3170)
We introduce a `DATA_CLOSED` class with minimal information about a past channel that has been fully closed. This will let us deprecate legacy channels without having backwards-compatibility issues with very old closed channels inside our DB.
When channels have never been properly opened or used, we don't bother storing them in our DB, as it would open the door to DoS attacks.
We create a dedicated table to store `DATA_CLOSED`. We migrate the existing DB and remove the foreign key constraint on `htlc_infos`.
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
explicit security languagesigning or wallet path
AI analysis · Low 29/100
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.
✓ Descriptive subject✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
nonce handlingcryptography-sensitive pathsigning or wallet pathparser or protocol path
AI analysis · Low 35/100
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.
Security candidateKill the connection if a peer sends multiple ping requests in parallel (#3172)by pm47 · 08a1fc66 · Sep 19, 2025 · 2 filesMessage 81 · StrongTriage 15Details
Commit message · pm47
Kill the connection if a peer sends multiple ping requests in parallel (#3172)
We keep track of the number of pings that we have not yet sent a pong for. If there is more than 1, our peer is malicious and we close the connection.
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Correctly fill PSBT for taproot `interactive-tx` (#3169)
When using tapoot for our inputs, our signatures will cover *all* inputs of the transaction, even those that don't belong to us. If our peer adds inputs, we must thus fill them in the PSBT we create, otherwise signing will fail.
This was the reason why we were previously sharing the same dummy wallet between Alice and Bob in our unit tests, otherwise we were seeing that kind of failures in unit tests, but we never figured out why before.
Now that this is fixed, we can improve the unit tests by having separate wallets for Alice and Bob, and remove the unused `NoOpOnChainWallet`.
100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarycryptography-sensitive pathsigning or wallet path
AI analysis · Moderate 60/100
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.
We must accept both high-S and low-S signatures in Bolt 11 invoices when performing public key recovery (which matches secp256k1's behavior).
See https://github.com/lightning/bolts/pull/1284
91/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundaryfuzzing or regression evidence
AI analysis · Informational 12/100
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.
Allow omitting `previousTx` for taproot splices (#3143)
When splicing a taproot channel, both participants will provide a signature for a segwit v1 input: this signature will cover every spent `txOut`, including their amount and script. This ensures that attackers cannot reuse a signature while replacing a segwit input with a non-segwit input, which could be used to steal funds.
A side-effect of this change in signature behavior is that we don't need to provide the entire previous transaction when both channel participants sign a taproot input. For simplicity, we only allow this simplification when splicing taproot channels for now. We can also allow channel creation based on swap-in-potentiam, which also uses musig2 and has the same non-malleability guarantee (on feature branches for phoenix users).
86/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
explicit security languagesigning boundaryparser or protocol path
AI analysis · Low 28/100
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.
We add new commitment formats and TLV extensions to include musig2 nonces. This includes a specific commitment format for phoenix taproot channels.
The old v1 channel establishment protocol is updated to include nonces and partial signatures.
The v2 channel estalishment protocol, based on the interactive tx constuction protocol, is also updated, and the interactive tx session now includes: - an optional funding nonce for the shared input (i.e. the funding tx that is being spent) - a nonce for the commit tx that is being created, and another nonce that will become the channel's "next remote nonce" once the session completes The funding nonce is random and its lifecycle is bound to the interactive session.
Side note: the new v2 protocol is both simpler to extend and gives us support for dual-funding and splices.
Since there can be several different commitment transactions that valid at the same time while splices are pending, revoke_and_ack and channel_restablish are extended to include a list of funding_tx_id -> nonce tuples (one for each active commitment).
channel_restablish also includes as an optional "current commit nonce": if we got disconnected while a splice was in progress before both nodes exchanged their commit signatures: if that is the case, we need to re-send our peer's current signature and will use this nonce to compute it.
We also update the simple close protocol to include closing nonces.
We allow upgrading channels to taproot during splices, with an optional channel_type TLV added to splice_init/splice_ack. This is not part of the BOLT proposal, and upgrading is currently limited to phoenix taproot channels from phoenix anchor channels.
71/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarynonce handlingcryptography-sensitive pathsigning or wallet pathparser or protocol path
AI analysis · Low 32/100
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.
Extract `CommitParams` to individual commitments (#3118)
We introduce a new channel codec version where:
- we extract per-commitment parameters (commitment format and params such as `dust_limit` which we may want to dynamically update in the future) - we clean-up the splice iterations on the `Commitments` structure - we remove the funding transaction from the confirmed local funding status (once confirmed, we don't need it anymore: it is wasting DB space for no good reason, we can get it from the blockchain) - we add a `maxClosingFeerate_opt` to the closing state, to allow limiting the feerate used in RBF attempts for safe transactions - we add the commitment format to interactive-tx parameters - we make channel type feature non permanent
We add a mechanism to prevent the node from starting-up, unless an override is provided. This provides an opportunity to iterate on codecs while knowing that node operators won't be affected if we make changes that are backwards-incompatible. This is meant to be temporary.
93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Low 35/100
This is a large internal refactoring of Eclair's Lightning channel data structures. It moves commitment-specific settings (such as dust limits and HTLC limits) from the overall channel parameters into each individual commitment, so future splices can change them. It also removes the full confirmed funding transaction from the local database record, adds a cap on closing fee rates for RBF attempts, and introduces a startup-blocking guard when the database serialization format changes. The commit is not described by the vendor as a security fix; it is a forward-looking infrastructure change with some safety mechanisms.
