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

units: Change hex parsing on Height and MedianTimePast

Public commit record

What the developer wrote

Authored by Mitchell Bagot

85/100 · Strong
units: Change hex parsing on Height and MedianTimePast

Height and MedianTimePast both have an existing from_hex function that
parses from an optionally prefixed hex string. In order to match the
other integer wrapper types in units, this should be split to from_hex
and from_unprefixed_hex.

Change from_hex to only parse prefixed hex in Height and
MedianTimePast. Introduce from_unprefixed_hex in Height and
MedianTimePast to parse unprefixed hex. Adjust ParseTimeError and
ParseHeightError accordingly.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit changes how two Bitcoin locktime types (block height and median-time-past) parse hexadecimal strings. Previously, a single function accepted hex with or without a '0x' prefix. Now there are two separate functions: one that requires the '0x' prefix and one that rejects it. This is an API-consistency cleanup, not a fix for an exploitable vulnerability. Existing callers that relied on the old flexible behavior could break at compile time or runtime if they still pass unprefixed hex to from_hex, but the change is intentional and documented.

Recommended action

Treat as a normal API-breaking refactor. Downstream users should audit calls to Height::from_hex and MedianTimePast::from_hex: any caller passing unprefixed hex must switch to from_unprefixed_hex. No urgent security patch is indicated by the diff alone.

Security signals we found

01

API behavior change: from_hex now rejects unprefixed hex strings

02

New from_unprefixed_hex function introduced for explicit unprefixed parsing

03

Error type expanded with prefixed/unprefixed hex error variants

04

No bounds-checking or overflow weakness visible in the new parsing path

05

No vendor security disclosure or CVE references present in commit or supplied materials

Risk score

Why this scored 18/100

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