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

Verify the holder provided valid witnesses and uses SIGHASH_ALL

Public commit record

What the developer wrote

Authored by Duncan Dean

100/100 · Strong
Verify the holder provided valid witnesses and uses SIGHASH_ALL

LDK checks the following:
* Each input spends an output that is one of P2WPKH, P2WSH, or P2TR.
These were already checked by LDK when the inputs to be contributed
were provided.
* All signatures use the `SIGHASH_ALL` sighash type.
* P2WPKH and P2TR key path spends are valid (verifies signatures)

NOTE:
* When checking P2WSH spends, LDK tries to decode 70-72 byte witness
elements as ECDSA signatures with a sighash flag. If the internal
DER-decoding fails, then LDK just assumes it wasn't a signature and
carries with checks. If the element can be decoded as an ECDSA
signature, the the sighash flag must be `SIGHASH_ALL`.
* When checking P2TR script-path spends, LDK assumes all elements of
exactly 65 bytes with the last byte matching any valid sighash flag
byte are schnorr signatures and checks that the sighash type is
`SIGHASH_ALL`. If the last byte is not any valid sighash flag, the
element is assumed not to be a signature and is ignored. Elements of
64 bytes are not checked because if they were schnorr signatures then
they would implicitly be `SIGHASH_DEFAULT` which is an alias of
`SIGHASH_ALL`.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds verification of Bitcoin transaction signatures that a user (the 'holder') provides when building a Lightning channel funding transaction. Before this change, the code trusted the holder's supplied witness data more blindly. The new checks ensure the holder's inputs are standard types (P2WPKH, P2WSH, or P2TR), that signatures use the safe SIGHASH_ALL mode, and that P2WPKH and simple Taproot signatures are actually valid. The commit message explicitly warns that without SIGHASH_ALL, 'your funds can be held hostage'—meaning a malicious or buggy counterparty could potentially prevent the transaction from being confirmed or lock up funds.

Recommended action

Treat this as a security-hardening fix and include it in the next release. Users running interactive-tx (dual-funded / splicing) code paths should upgrade. Review whether the partial validation for P2WSH and P2TR script-path inputs is sufficient for your threat model, since the commit deliberately does not fully execute or validate those scripts.

Security signals we found

01

New signature verification logic added to holder-provided witnesses

02

Explicit SIGHASH_ALL enforcement with warning about fund hostage risk

03

P2WPKH and P2TR key-path signature validation added

04

P2WSH/P2TR script-path only parse-and-check sighash, not full script execution

05

API documentation updated to describe security checks and failure modes

Risk score

Why this scored 68/100

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