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

Merge rust-bitcoin/rust-bitcoin#6755: crypto: Extend `EcdsaSighashType` to non-standard values

Public commit record

What the developer wrote

Authored by Andrew Poelstra

91/100 · Strong
Merge rust-bitcoin/rust-bitcoin#6755: crypto: Extend `EcdsaSighashType` to non-standard values

619e16acbc65593fed9c7d4100bc3d551829c19f crypto: replace EcdsaSighashType derives with manual impls (jrakibi)
baa6ee0e71b871c29aa7b75027c3d3ed4771a144 Add tests for non-standard sighash types (jrakibi)
3fb16c665b4ba562b81ca1df544d7f4136b02010 crypto: Make from_slice accept non-standard sighash types (jrakibi)
50c06af4b3c4274f44ec751bfef06fd987343a08 crypto: extend EcdsaSighashType to accept NonStandard (jrakibi)

Pull request description:

The current segwit v0 sighash API takes `EcdsaSighashType`, which only accepts _standard_ values. This means we cannot compute the correct sighash for _consensus-valid_ transactions that use _non-standard_ sighash type, so verifying their signatures fails.

We extend `EcdsaSighashType` to accept any u8 value (solution proposed by Apoelstra in https://github.com/rust-bitcoin/rust-bitcoin/issues/1657#issuecomment-1456876763).

This is a step to make legacy encoding also take `EcdsaSighashType` instead of u32 to close #1657 (will open a separate PR for it after getting feedback on this one)

Closes https://github.com/rust-bitcoin/rust-bitcoin/issues/6647 and https://github.com/rust-bitcoin/rust-bitcoin/issues/4133

_This might also address #777_


ACKs for top commit:
apoelstra:
ACK 619e16acbc65593fed9c7d4100bc3d551829c19f; successfully ran local tests


Tree-SHA512: a446767f920c691a9f11774e5a7329036154c1a3d762cf293565a7ac9e3aa7a96bd94a4177b28661aa417334f4d4cd001065c37dfc11c69a2b944425c026c6e3
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change fixes a bug where the library rejected certain unusual but Bitcoin-network-valid signature hash types. Before the fix, users could not verify signatures from real mainnet transactions that use these non-standard values, which could cause valid transactions to be incorrectly rejected. The patch extends the type system to accept any valid value while still treating the standard ones normally.

Recommended action

Review downstream callers that previously relied on EcdsaSighashType only containing standard values, especially any code that exhaustively matches the enum or assumes From<EcdsaSighashType> for TapSighashType. Ensure the new TryFrom is handled. Consider whether any APIs that previously rejected non-standard sighash types should now accept them or remain restrictive.

Security signals we found

01

Fixes inability to verify consensus-valid signatures with non-standard sighash types

02

Changes signature parsing from standard-only to consensus-accepting

03

Adds NonStandard(u32) variant preserving full u32 value for sighash computation

04

Adds regression test against real mainnet transaction

05

Converts Ecdsa->Tap conversion to fallible to prevent invalid Taproot sighash types

Risk score

Why this scored 47/100

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