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

SFT-8167 SFT-8168: validate sighash types per input type

Public commit record

What the developer wrote

Authored by Jack

78/100 · Adequate
SFT-8167 SFT-8168: validate sighash types per input type

Sighash validation was shared across every input type, but the three
signers support different sets. Validate per input type instead:
SIGHASH_DEFAULT only exists for taproot (BIP-341), and the error now
names the input and the type.

Taproot takes both documented ALL modes. The rest of
make_txn_taproot_sighash() was already generic - it writes the hash type
byte into the message, and taproot_sign_key() already appends it as a
65th signature byte for anything but SIGHASH_DEFAULT - so only the
assertion had to change.

The legacy preimage also packs the type it is given rather than a
constant, and the assertions on the signing path carry messages.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit tightens how a Bitcoin hardware wallet (Passport) checks the 'sighash' flag for each transaction input. Previously the same allowed list was used for every input type, which meant a non-taproot input could in principle be asked to use SIGHASH_DEFAULT (a taproot-only value), or a taproot input could be asked to use an unsupported type. The code now validates sighash types per input type, uses the actual requested type when building the transaction digest, and gives clearer error messages. It also adds unit tests that independently recompute the digests and verify taproot signatures. The change is defensive hardening rather than a confirmed exploitable bug, but it removes a class of type-confusion risks in the signing path.

Recommended action

Treat as a security-hardening fix and include it in the next firmware release. Review whether any external PSBT generators ever relied on the old permissive behavior. Run the new psbt_sighash unit tests in CI. Consider whether additional sighash types (e.g., SIGHASH_SINGLE, SIGHASH_NONE) need explicit rejection or future support, and document the supported set clearly.

Security signals we found

01

Input-type-specific sighash validation

02

Removal of shared VALID_SIGHASHES check that allowed SIGHASH_DEFAULT on non-taproot inputs

03

Legacy preimage now commits to actual sighash_type instead of constant 0x01

04

Assertions on signing path now carry messages for safer error reporting

05

New independent unit tests recompute preimages and verify BIP-340 signatures

06

Defensive fix in exception handler for bare AssertionError

Risk score

Why this scored 59/100

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