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

Replace serde derive with call-through impl

Public commit record

What the developer wrote

Authored by Mitchell Bagot

68/100 · Adequate
Replace serde derive with call-through impl

The existing serde implementation for XOnlyPublicKey derives from the
implementation on the inner type. Once additional data is introduced,
like the parity, XOnlyPublicKey will no longer serialise or
deserialise correctly.

Replace serde derived implementations with manual implementations that
call through to inner type's serde implementations.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how a Bitcoin public-key type is serialized and deserialized when the optional serde feature is enabled. The old code automatically used the inner key type's format, which would break if extra data (such as key parity) is added later. The new code explicitly forwards to the inner type, keeping the wire format stable even as the wrapper type evolves. It is a hardening/preventive change rather than a fix for an active vulnerability.

Recommended action

Review the new manual serde implementations for correctness, especially that Serialize and Deserialize remain symmetric and that any future parity field is handled consistently. If this change affects persisted or network-exchanged data, add regression tests covering round-trip serialization and cross-version compatibility. No urgent patch is required unless downstream consumers rely on the previous derived format in a way that now differs.

Security signals we found

01

Serialization format stability for a cryptographic public-key type

02

Preventive hardening against future struct layout changes breaking serde compatibility

03

Manual serde delegation instead of derived forwarding

04

Potential for deserialization mismatch if inner and wrapper invariants diverge in the future

Risk score

Why this scored 29/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 5/15
Affected reach 5/15
Confidence 6/10
Evidence quality 3/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.