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

Merge bitcoin-core/secp256k1#1918: refactor: split `ge_parse` into explicit variants (compressed, uncompressed, uncompressed+hybrid)

Public commit record

What the developer wrote

Authored by merge-script

100/100 · Strong
Merge bitcoin-core/secp256k1#1918: refactor: split `ge_parse` into explicit variants (compressed, uncompressed, uncompressed+hybrid)

de02108c51ca052245c7ba154b02a890e6815fdb tests: cover compressed pubkey parsing/serialization in `_ec_pubkey_parse` test (Sebastian Falbesoner)
31b1b300e812038e5b52f534370f7bd0cae01a79 refactor: split `ge_parse` helper into explicit variants (Sebastian Falbesoner)

Pull request description:

This PR is a follow-up to #1915, see the suggestion https://github.com/bitcoin-core/secp256k1/pull/1915#pullrequestreview-4962713401.

Splits the `ge_parse` function into three explicit variants for parsing from:
- compressed public keys (33-bytes, prefixes 0x02 or 0x03)
- uncompressed public keys (65-bytes, prefix 0x04)
- uncompressed and hybrid public keys (65-bytes, prefixes 0x04, 0x06 or 0x07)

The first two are the counter-parts for the existing serialization functions `ge_serialize{33,65}`. The latter one is only needed for legacy reasons and likely not needed in the future. Having it named explicitly helps to avoid accepting hybrid pubkeys unintentionally. `ge_parse65` is currently unused outside of tests, but one potential use-case would be the serialization of the prevouts_summary in the silentpayments light-client API PR #1912 (see commit https://github.com/bitcoin-core/secp256k1/pull/1912/changes/82b95fde6fe2c75ec940ade339013939b8ecc5ea), unless we want to define a custom serialization there (where we e.g. remove the constant prefix byte).

ACKs for top commit:
fjahr:
Code review ACK de02108c51ca052245c7ba154b02a890e6815fdb
real-or-random:
utACK de02108c51ca052245c7ba154b02a890e6815fdb

Tree-SHA512: 8bc92f6f53eb5ce3546ecf0a1fa72a909ee6231a08e25a3a9f4070e7d630379fc3e5b2f9bc6dea25726b7d9c97c2cfd8ee39be413328c4159134ec55ec1a59c6
✓ 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✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit is a code cleanup (refactor) that splits one internal public-key parsing helper into three clearly named versions. It does not change what keys the public API accepts or rejects, and it adds more tests. There is no security vulnerability being fixed here.

Recommended action

No security action required. Treat as normal code-quality / maintainability improvement.

Security signals we found

01

Refactor only: no change to accepted public-key formats or validation rules

02

Public API behavior preserved: 33-byte compressed and 65-byte uncompressed/hybrid still accepted

03

Internal fixed-size callers now use size-specific parser, reducing risk of accidental hybrid acceptance in future code

04

New tests added for compressed key parsing round-trip and edge cases

Risk score

Why this scored 15/100

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