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

Merge rust-bitcoin/rust-bitcoin#6805: crypto: Add NonStandardSighashType wrapper

Public commit record

What the developer wrote

Authored by Andrew Poelstra

100/100 · Strong
Merge rust-bitcoin/rust-bitcoin#6805: crypto: Add NonStandardSighashType wrapper

1c4a09ba6e218100fd620b3f3dff4f56c5ee1b2c crypto: Derive PartialEq, Eq and Hash for EcdsaSighashType (jrakibi)
54210869336f3cbb7fd00c3a1aa2e51ba58d762e crypto: Add `NonStandardSighashType` wrapper (jrakibi)

Pull request description:

Currently a value in the `NonStandard` variant can be anything, including a standard value, which makes the enum redundant (eg. EcdsaSighashType::All and EcdsaSighashType::NonStandard(0x01)).

Instead we can change the `NonStandard` variant to hold a type with private inner `u32`, so that `EcdsaSighashType::NonStandard` **_cannot_** represent a standard sighash type.

Users who need a non-standard sighash type can use `EcdsaSighashType::from_consensus`.

Closes https://github.com/rust-bitcoin/rust-bitcoin/issues/6795


ACKs for top commit:
apoelstra:
ACK 1c4a09ba6e218100fd620b3f3dff4f56c5ee1b2c; successfully ran local tests; nice!


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

What changed, and why it matters

This change is a code-quality and type-safety improvement, not a security fix. It replaces a raw number in the 'NonStandard' sighash variant with a dedicated wrapper type so that the variant can only hold genuinely non-standard values. This prevents accidental misuse where a standard sighash type could be represented both as a normal enum variant and as a 'NonStandard' number, but it does not close an exploitable vulnerability on its own.

Recommended action

No urgent action required. Treat as a normal refactor/API-improvement. Review downstream code that pattern-matches on EcdsaSighashType::NonStandard(_) or constructs it directly, because direct construction is no longer possible; use EcdsaSighashType::from_consensus instead.

Security signals we found

01

Type-system hardening to prevent representation of standard sighash types as NonStandard

02

No memory-safety, cryptographic, or consensus bug is fixed in the diff

03

No advisory, CVE, or security disclosure is referenced in the commit or PR

Risk score

Why this scored 19/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 2/15
Confidence 9/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.