AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 28 Bitcoin

Allow omitting `previousTx` for taproot splices (#3143)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

86/100 · Strong
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).
✓ 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
The short version

What changed, and why it matters

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.

Recommended action

Review that the TaprootCommitmentFormat check cannot be bypassed when no shared input exists, and confirm that all code paths constructing or validating remote inputs enforce the same non-segwit and replaceability checks. Consider whether older segwit-v0 channels correctly reject PrevTxOut in mixed-feature deployments.

Security signals we found

01

New wire protocol TLV (PrevTxOut, type 1107) for reduced transaction disclosure

02

Validation gate restricts previousTxOut omission to taproot commitment formats

03

Explicit defense against non-segwit input substitution / malleability

04

Sequence-number validation now enforced for both full-previous-tx and previousTxOut paths

05

Test added to ensure previousTxOut is rejected for non-taproot channels

Risk score

Why this scored 28/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 5/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.