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

Merge pull request #11003 from SomberNight/202609_tx_any_segwit

Public commit record

What the developer wrote

Authored by ThomasV

73/100 · Adequate
Merge pull request #11003 from SomberNight/202609_tx_any_segwit

transaction: rename `is_segwit`->`is_any_segwit`, and add `is_all_segwit`
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit renames Electrum's transaction 'is_segwit' check to 'is_any_segwit' and adds a new 'is_all_segwit' check. It then uses the stricter 'all inputs are segwit' rule when validating Lightning channel funding transactions and timelock-recovery transactions. The change is defensive: a transaction that mixes segwit and non-segwit inputs still has a malleable transaction ID, which can cause problems for protocols that rely on a stable txid. The commit does not claim to fix an active exploit, and one new code comment explicitly flags that a related zeroconf check is still incomplete and unsafe.

Recommended action

Treat as a defensive hardening commit. Reviewers should verify that no other security-critical callers still rely on the weaker 'any segwit' semantics when they actually need txid non-malleability, and that the zeroconf TODO in lnpeer.py is tracked and resolved before any mainnet deployment.

Security signals we found

01

Renamed ambiguous 'is_segwit' to 'is_any_segwit' and introduced stricter 'is_all_segwit'

02

Funding transaction validation in Lightning channel establishment now requires all inputs to be segwit (non-malleable txid)

03

Timelock recovery plugin now asserts all inputs are segwit for alert/recovery/cancellation transactions

04

txid() malleability guard updated to use is_all_segwit()

05

New code comment explicitly marks zeroconf channel path as still incomplete/unsafe for mainnet

Risk score

Why this scored 44/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 7/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.