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#6688: crypto: Remove `alloc` gating from `WifKey` methods

Public commit record

What the developer wrote

Authored by Andrew Poelstra

91/100 · Strong
Merge rust-bitcoin/rust-bitcoin#6688: crypto: Remove `alloc` gating from `WifKey` methods

b3f8712f932d101d2b3eae5ea44e585f63bb3a60 Remove FromWifError::InvalidBase58PayloadLength and inner error (Mitchell Bagot)
e09f6582dd41b9a8229d1b61bb955f652f1cfa98 Remove alloc gating from WifKey::from_wif and FromStr (Mitchell Bagot)
20039ae24c721493fee9ef6139df089272e99eb9 Remove alloc gate from WifKey::fmt_wif (Mitchell Bagot)

Pull request description:

With the new base58 no-alloc functionality, the WifKey fmt_wif and from_wif functions can be made no-alloc. This allows users without alloc to parse and write out WIF keys if needed and removes the last of the major alloc parts in the key module. Those that remain directly rely on alloc/std types.

- Patch 1 removes the alloc requirement for fmt_wif.
- Patch 2 removes the alloc requirement for from_wif.
- Patch 3 removes the unused error type InvalidBase58PayloadLengthError and variant from FromWifError.


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


Tree-SHA512: 01b67b3f8c59d8645025de3c3fc9811c988498340926fe1ed164f6edbb9a119ab7d7deff602290708869b0f3b1167ebfe18807f46abdd5fc46250dbaf935aeeb
✓ 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 lets a Bitcoin key-handling library work in environments without a memory allocator by removing an unnecessary requirement that memory allocation be available for certain WIF (Wallet Import Format) key operations. It also removes an unused error type. There is no direct security vulnerability being fixed; it is a feature-portability improvement.

Recommended action

No security action required. Treat as a normal portability/refactoring change. Reviewers may want to verify that the new fixed-size base58 decode/encode paths preserve the previous 33/34-byte length validation behavior, which the diff indicates they do.

Security signals we found

01

No security-relevant signal in commit message or diff

02

Refactoring to remove alloc feature gates

03

Removal of unused error variant and type

04

Use of `.expect()` on fixed-size base58 encode (infallible by construction for known-length inputs)

Risk score

Why this scored 19/100

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