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

transaction: add method tx.is_all_segwit()

Public commit record

What the developer wrote

Authored by SomberNight

45/100 · Thin
transaction: add method tx.is_all_segwit()
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit adds a helper method to check whether every input of a Bitcoin transaction uses SegWit, and starts using it in place of a weaker 'any input is SegWit' check when validating Lightning funding transactions. SegWit fixes 'transaction malleability,' where the transaction ID (txid) can be changed by someone else after signing. For Lightning, the funding txid must be stable because both parties rely on it to set up the channel. The old check only required at least one SegWit input, which could still allow non-SegWit inputs to be re-signed or malleated, changing the txid. The commit also adds a TODO noting that a zero-confirmation code path still doesn't perform this check at all, which the authors already flag as unsafe.

Recommended action

Review whether the zero-confirmation channel_establishment_flow path in lnpeer.py should enforce is_all_segwit() before mainnet use, as the commit's own TODO states the current behavior is unsafe. Otherwise, this commit appears to be a defensive hardening fix and should be included in the next release.

Security signals we found

01

Replaced weaker malleability check with stronger all-inputs SegWit check in Lightning funding transaction validation

02

Code comment explicitly tied the change to transaction malleability and funding txid stability

03

Prior code contained a '# FIXME needs is_all_segwit' indicating the old check was known to be insufficient

04

New helper includes references to BIP-62 and Bitcoin Core policy explaining malleability risks

05

A TODO marks the zero-confirmation channel path as still missing the check and explicitly calls it unsafe

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.