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 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 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 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,…
New wire protocol TLV (PrevTxOut, type 1107) for reduced transaction disclosureValidation gate restricts previousTxOut omission to taproot commitment formatsExplicit defense against non-segwit input substitution / malleability
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 p…
New cryptographic signing path using MuSig2 partial signatures and noncesNew validation exceptions for missing or invalid commit/funding/closing noncesProtocol message extensions for nonce exchange during channel lifecycle
✓ Descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
cryptography-sensitive pathsigning or wallet path
AI analysis · Informational 22/100
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 direct evidence in the commit that this fixes a security vulnerability, but library updates can include bug fixes or improvements that affect cryptographic handling.
Security candidateAdd support for zero-fee commitment format (#3192)by Bastien Teinturier · 35403401 · May 20, 2026 · 42 filesMessage 100 · StrongLow 34Details
Commit message · Bastien Teinturier
Add support for zero-fee commitment format (#3192)
* Add support for zero-fee commitment format
We add support for the zero-fee commitment format specified in https://github.com/lightning/bolts/pull/1228.
Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the `update_fee` mechanism, have less dust exposure risk, and use an overall simpler state machine.
In this commit, we simply introduce the commitment format and create the corresponding transactions.
* Rename `ClaimRemoteDelayedOutputTx`
It isn't delayed anymore for v3 transactions. We could use static wallet public key, but in most cases it wouldn't work and adds extra complexity so we don't do it. We add a comment in the documentation of this class to explain why we're always making a 2nd-stage transaction.
* Validate channel parameters
We apply slightly different validation for zero-fee commitments:
- the commit feerate must be `0 sat/byte` - the max number of accepted HTLCs must be at most 114 - `update_fee` cannot be used
We verify those requirements during channel creation and add tests for normal channel operation.
* Handle force-closing zero-fee channels
We add support for force-close zero-fee channels. When publishing the local commit, this works mostly the same way as other channel types. The only difference is that we don't even attempt to publish the commit tx individually: we always bundle it with the anchor transaction.
When we detect the remote commit though, we're able to introduce some new behavior:
- if we have a large enough main output, we use that to pay the fees of the remote commit tx (unless it is already confirmed), which avoids using a wallet input - otherwise, we spend the anchor output, which competes with the remote peer package
Since we're only using the anchor transaction or our main output to spend the ephemeral anchor, we cannot publish HTLC txs until the commit tx is confirmed. We will in the future make *all* transactions go through the `ReplaceableTxPublisher`, and at the point we'll be able to simplify this, but it's too early for this refactoring, so for now we simply wait for the commit tx to be confirmed before publishing HTLC txs.
* Don't force-close on remote `error`
When using zero-fee commitments, we don't force-close when receiving an `error` from our peer: if they want to force-close the channel, they can publish their commitment instead of forcing us to publish ours. It is especially true when the commit tx doesn't pay any fees, because the publisher will pay the entire fees for the force-close.
Note that for wallet peers, we could introduce a mechanism where they send us their signed commit tx in the error message if they don't have any wallet input to pay the fees, and we could be nice and publish it while paying the fees from our main output (which isn't delayed since it is the remote commit from our point of view).
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
explicit security languagedefensive validationsigning or wallet path
AI analysis · Low 34/100
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 new transaction formats, validation rules, and force-close behavior. Because it is experimental, disabled by default, and extensively tested, it is unlikely to be an immediate security issue, but any large change to consensus-sensitive transaction code carries risk of subtle bugs.
Security candidateBump org.postgresql:postgresql version (#3305)by Bastien Teinturier · 76da19f1 · May 7, 2026 · 2 filesMessage 81 · StrongLow 36Details
Commit message · Bastien Teinturier
Bump org.postgresql:postgresql version (#3305)
This fixes a vulnerability, which doesn't apply to eclair in known deployements, but is worth fixing in case some nodes use untrusted database hosts which could lead to DoS attacks.
81/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
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 connects to an untrusted database host. The developers state it does not affect known Eclair deployments, but they are patching it as a precaution.
Security candidateFix flaky DER signature weight test (#3299)by Bastien Teinturier · 0f5d4b89 · May 5, 2026 · 1 fileMessage 100 · StrongInformational 15Details
Commit message · Bastien Teinturier
Fix flaky DER signature weight test (#3299)
This test was flaky because for the funding output, we provide two signatures, which means that we need twice the slack for the variable DER encoding length.
100/100 · StrongMessage clarity
✓ 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✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100
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 code, no security fix, and no vulnerability.
Security candidateAdd support for the official splicing protocol (#2887)by Bastien Teinturier · 68b0096a · Apr 30, 2026 · 24 filesMessage 93 · StrongLow 35Details
Commit message · Bastien Teinturier
Add support for the official splicing protocol (#2887)
We replace our experimental version of `splice_init`, `splice_ack` and `splice_locked` by their official version. If our peer is using the experimental feature bit, we convert our outgoing messages to use the experimental encoding and incoming messages to the official messages.
We also change the TLV fields added to `tx_add_input`, `tx_signatures` and `splice_locked` to match the spec version. We always write both the official and experimental TLV to updated nodes (because the experimental one is odd and will be ignored) but we drop the official TLV if our peer is using the experimental feature, because it won't understand the even TLV field.
We do the same thing for the `commit_sig` TLV. For peers who support the official splicing version, we insert the `start_batch` message before the batch of `commit_sig` messages.
This guarantees backwards-compatibility with peers who only support the experimental feature.
We introduce a `retransmit_flags` field to `my_current_funding_locked` and `next_funding` to ask our peer to retransmit `commitment_signed` or `announcement_signatures` if we're expecting them. With this change, we don't need to retransmit `splice_locked` on reconnection anymore to trigger the exchange of `announcement_signatures`. We don't need to retransmit it to let our peer know that we've seen enough confirmations for the splice either, since `my_current_funding_locked` implies that.
This allows us to completely remove retransmission of `splice_locked` on reconnection, and also get rid of the `your_last_funding_locked` TLV, which greatly simplifies the reconnection logic. We do keep them for backwards-compatibility with existing Phoenix users though, but we'll be able to clean it up once they have updated.
Note that this works with taproot channels since we will simply provide nonces in `channel_reestablish` when we need our peer to send announcement signatures (not supported yet since taproot channels are never announced).
We rollback using the `next_commitment_number` to let our peer know that we haven't received their `commit_sig` and instead use the retransmit flags added to the `next_funding` TLV, unless our peer is using the legacy splicing protocol.
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
signing boundarysigning or wallet pathauthentication pathparser or protocol path
AI analysis · Low 35/100
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 signatures, and renumbers some protocol feature bits. The changes are broad and touch consensus-critical wire protocol and channel state logic, so bugs could affect channel safety, but the commit itself is a feature implementation rather than a clear security fix.
Security candidateStore our closing_complete in the simple close session (#3289)by Fabrice Drouin · da7cd962 · Apr 21, 2026 · 4 filesMessage 96 · StrongLow 32Details
Commit message · Fabrice Drouin
Store our closing_complete in the simple close session (#3289)
In the simple close session, which is never persisted, we just need to remember our closing_complete and the partial signatures it contains, instead of keeping our musig2 nonces and generating our partial signatures a second time to build the final closing tx when we receive our peer's partial signatures. We also check our peer's partial signature and fail early if they're not valid, instead of building a fully sign closing tx and then verify that it is correct.
96/100 · StrongMessage clarity
✓ Specific, 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 boundarynonce handlingsigning or wallet path
AI analysis · Low 32/100
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.
Security candidateAdd duration information to payment events (#3241)by Bastien Teinturier · 9856db85 · Jan 20, 2026 · 32 filesMessage 81 · StrongInformational 19Details
Commit message · Bastien Teinturier
Add duration information to payment events (#3241)
We now record start and end time for payment events, and for remote failures, which lets us easily identify slower paths and faulty nodes. We properly track the settlement of each individual payment now.
We also clean-up field names and harmonize those events. Note that we don't update the DB schema at that point: this will be done in another PR that batches all DB schema changes.
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
cryptography-sensitive pathseed or entropy path
AI analysis · Informational 19/100
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.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive pathsigning or wallet pathparser or protocol path
AI analysis · Low 27/100
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.
✓ Descriptive subject✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
signing boundarycryptography-sensitive path
AI analysis · Informational 12/100
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.
Use 73 bytes der-encoded signatures in weight estimation (#3210)
While 73 bytes der-encoded signatures aren't standard (they're only possible with high-S signatures), miners could accept such signatures.
Most of our tests use 72 bytes der-encoded signatures because we will never generate 73 bytes der-encoded signatures ourselves. But it's more safe to use a 73 bytes signature in our weight estimation because:
- it's what the BOLTs recommend - it's what other implementations use (e.g. LDK) which means they may reject our interactive-tx attempts by thinking we're under-paying fees
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✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 35/100
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.
Allow aborting liquidity purchases after signing (#3206)
When a liquidity purchase is signed, we eagerly add it to our DB before receiving the remote `interactive-tx` signatures. If we reach that step, our peer should always finalize the signing steps, so we didn't bother handling the case where they would instead send `tx_abort`. When that happened, we kept the upstream HTLCs pending until they got close to their expiry, at which point we failed them.
We've seen cases where seemingly non-malicious mobile wallets abort that kind of liquidity purchases after a disconnection. It is harmful for an honest sender to keep the HTLCs pending, so we now immediately fail them in that case.
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
signing boundarysigning or wallet path
AI analysis · Low 47/100
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.
Security candidateRemove support for non-anchor channels (#3173)by Bastien Teinturier · 9911cb73 · Oct 27, 2025 · 86 filesMessage 98 · StrongLow 34Details
Commit message · Bastien Teinturier
Remove support for non-anchor channels (#3173)
We remove support for `static_remotekey` channels and `default` channels, as advertised in the v0.13 release. This lets us remove some code related to feerate management and simplifies the test matrix.
Node operators that still have such channels must not run this version of `eclair`, which will otherwise fail to start.
Note that for now, we keep sending `update_fee` whenever necessary. We could remove that now that package relay allows 1p1c packages to propagate even when the parent is below the mempool minimum feerate, but we defer that to a later PR for simplicity.
98/100 · StrongMessage clarity
✓ 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
cryptography-sensitive pathsigning or wallet pathauthentication pathparser or protocol path
AI analysis · Low 34/100
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.
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.
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.
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.
