RECOVERING THE FORGOTTEN RECIPE BEHIND BITCOIN'S STARTING POINT
Investigation checkpoint | 17 October 2026

STATUS

The original recipe has NOT been recovered. This investigation reproduces the
known numerical fingerprint, proves exclusions for specific simple recipes,
and supplies positive controls for bounded historical-software checks.
The exclusions are independently checked; their novelty is not established.

THE OBJECT WE ARE TRYING TO EXPLAIN

Bitcoin's secp256k1 curve has a standardized public generator G. The question
is how its designers originally selected that particular point. We studied
all four related SEC prime-field k1 curves, because they contain the same
striking fingerprint. SEC2 v1 supplies the authoritative curve parameters [1].

Let H = ((n+1)/2)G, with n the published odd group order. This is the unique
half of G in that subgroup: doubling H produces G. Exact arithmetic gives:

curve       bits  x(H)
secp160k1   159   48ce563f89a0ed9414f5aa28ad0d96d6795f9c62
secp192k1   187   554123b78ce563f89a0ed9414f5aa28ad0d96d6795f9c66
secp224k1   166   3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63
secp256k1   166   3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63

Their common 152-bit interior is:
                 8ce563f89a0ed9414f5aa28ad0d96d6795f9c6

All four H points have even y. The verifier checks G and H on each curve,
nG=infinity, and 2H=G. This fingerprint is PRIOR ART, not a discovery made
here: it appears in the public discussion, Zweng's reproducible script, and
Heninger's October 2024 slides [2-5]. The 192-bit curve's H.x is 187 bits.

WHAT WE CAN NOW RULE OUT EXACTLY

Model A: choose one common nonnegative integer T; on each curve start at
x=T mod p; increase x by one until ANY curve point exists; select a root;
then double. No additional rejection rules or curve-specific transforms.

For each observed H.x, the immediately preceding valid x bounds the possible
starting values. The permitted increments are:

  160: 0       192: 0,1,2,3,4       224: 0       256: 0,1

There are just ten combinations. For each, the Chinese remainder theorem
gives the least common T. The smallest has 829 bits. Thus NO integer of at
most 828 bits fits this particular construction. In particular, one plain
SHA-1, SHA-256, or SHA-512 digest cannot explain all four points through this
reduce-and-increment model. This is a bound on a candidate integer, not on
seed entropy or the computational difficulty of the historical mystery.

The corresponding model reducing modulo group orders, then using the
residues as x coordinates, has a minimum of 827 bits. This is not a claim
about scalar multiplication by an unknown scalar.

Model B: keep the low field-width bits of one common T, then use the same
first-valid-x retry rule. This is impossible for ANY T: the 224-bit result
forces a 166-bit starting value. Its low 192 bits cannot produce the required
187-bit starting interval of the 192-bit curve. Clearing each field's top
bit does not resolve that contradiction.

Model C: apply Certicom's published hash-expansion formula to ONE common
seed, then increment x to the first valid point. That too is impossible.
Writing A=SHA1(seed) and B=SHA1(seed+1), the relevant prime-field expansions
are X192=(A mod 2^31)*2^160+B and X224=(A mod 2^63)*2^160+B.
Hence X192=X224 mod 2^191, contradicting the permitted starting intervals.
The historical document retries seed selection; the x-increment retry is a
separate hypothesis tested here, not a claim that Certicom used that retry.

These proofs do NOT exclude curve-dependent seeds, rehashing, different
packing, manual edits, extra rejection criteria, or other constructions.
The full ten-case CRT certificates are in hypothesis-results.json. A second,
independently written incremental CRT implementation agreed with the direct
product implementation delivered here.

HISTORICAL POSITIVE CONTROLS

Certicom published a SHA-1 expansion recipe and challenge parameter tables
[6-7]. Using fixed 20-byte big-endian seeds, seed increments modulo 2^160,
truncation, and prime-field high-bit clearing reproduces 48 of 48 published
point x coordinates. Binary controls use U_x/V_x before cofactor clearing;
prime controls use P_x/Q_x. These controls do not check root selection or
full cofactor multiplication.

Both prime Algorithms 7 and 8 in the inspected PDF print seedE inside the
point expansion. Using seedP reproduces the published points. This is a
documentary inconsistency resolved by the numerical controls; no claim is
made that this investigation first noticed the typo. The challenge launched
in 1997, but the downloaded older PDF was generated in 2003 according to its
metadata; it is not an authenticated original 1997 edition. The later SEC1
base-point recipe dates to 2009; it
should not be silently projected backward onto SEC2's 2000 parameters [8].

BOUNDED SEARCH RESULTS

No match was found in the following explicitly limited checks:

* SHA-1: 65 distinct published Certicom seeds, each with offsets 0..255;
  16,640 hash evaluations, testing all nine possible 152-bit windows in each
  digest. Evaluation counts may include overlapping neighborhoods.
* FreeLIP: its default seed and the six seeds from Anthropic's published
  base-point reconstruction; 26/30/62-bit limbs, five stated bounds, start
  offsets 0..9999. 1,050,000 candidate comparisons. The published P-192
  reconstruction passes as a positive control [9-10].
* Historical MIRACL: default seed zero, 16/32-bit output words with 32-bit
  long state, two source-listed recurrence parameter sets, five bounds,
  offsets 0..9999. 200,000 comparisons. All 128 recorded control words match
  independently compiled functions from the archived source [11].
* Current MIRACL: both documented seed-zero and actual quick-start defaults,
  32/64-bit words, two recurrence parameter sets, five bounds, offsets
  0..9999. 400,000 comparisons; 128 compiled-source control words match [12].
* Published lrand48 runs: reproduce all 14 seeds in Anthropic's article,
  then look for the fingerprint within those ten known streams through
  their last listed successful candidate: 436,660 draws and 3,530,170 bit
  windows [9].

These are fixed public-seed replays, not exhaustive searches over unknown
seeds. No negative rules out an entire library. MIRACL's historical default
and bigrand behavior differ from current upstream code; the package keeps
them separate. No evidence establishes that MIRACL generated these points.
Control coverage is recorded explicitly; the compiled MIRACL controls check
PRNG words, while integer packing was reconstructed from the source.

WHAT REMAINS MISSING

We still need an independently justified input or original source fragment
that explains the common interior AND the differing prefixes/suffixes.
An arbitrary formula that merely embeds the known constants is not recovery.
The hypothesis that doubling came from reused binary-curve cofactor code
was already proposed by Thomas Pornin and discussed by Gregory Maxwell [3].
The most useful next evidence would be pre-2000 Certicom generation source,
SECG working drafts, or original parameter-generation notes. Nothing in
this checkpoint demonstrates a Bitcoin vulnerability.

REPRODUCTION

Requires Python 3.8+ and its standard library. From the extracted directory:

  python verify.py
  python hypotheses.py
  python certicom_controls.py
  python replay_public_prng_checks.py

The first three scripts emit JSON. The last has its usage in public-prng-audit-note.txt
and writes its bounded-replay result. No network access is needed to replay.
Saved result files are supplied, along with a SHA-256 manifest. Research
scripts use assertions; do not invoke Python with optimization (-O).

SOURCES

[1] SEC2 v1.0, September 2000:
https://www.secg.org/SEC2-Ver-1.0.pdf
[2] John Zweng's reproducible half-generator script, April 2022:
https://gist.github.com/johnzweng/863f412689ee383cc41ac7c709ca662c
[3] Firsthand discussion of the special half-generator; Maxwell's answer
dates November 2019 although the encompassing question dates 2018:
https://crypto.stackexchange.com/questions/60420/what-does-the-special-form-of-the-base-point-of-secp256k1-allow
https://crypto.stackexchange.com/posts/76010/revisions
[4] Nadia Heninger, ECC 2024, slide 44; unresolved preimage question:
https://troll.iis.sinica.edu.tw/ecc24/slides/4-05-ecc.pdf
[5] Firsthand 2023 discussion, including already-proposed hash/PRNG ideas:
https://bitcointalk.org/index.php?topic=5469657.0
[6] Certicom ECC Challenge, older downloadable revision:
https://www.certicom.com/content/dam/certicom/images/pdfs/cert_ecc_challenge.pdf
[7] Certicom published public parameter table:
https://www.certicom.com/content/certicom/en/curves-list.html
[8] SEC1 versions and the 2009 additions:
https://www.secg.org/SEC1-Ver-1.0.pdf
https://www.secg.org/sec1-v2.pdf
https://www.secg.org/sec1-v1.99.dif.pdf
[9] Anthropic, Claude reveals ECDSA curve origins, October 16, 2026:
https://www.anthropic.com/research/ecdsa-curve-origins
[10] FreeLIP source mirror:
https://github.com/lrobot/freelip/blob/master/lip.c
https://github.com/lrobot/freelip/blob/master/lip.h
[11] MIRACL archive listing dated April 1996; source carries 1988-1993 dates:
https://www.mirrorservice.org/sites/ftp.wiretapped.net/pub/security/cryptography/libraries/math/miracl/
https://www.mirrorservice.org/sites/ftp.wiretapped.net/pub/security/cryptography/libraries/math/miracl/miracl.zip
[12] Current upstream MIRACL source and documentation:
https://github.com/miracl/MIRACL/blob/master/source/mrcore.c
https://github.com/miracl/MIRACL/blob/master/source/mrrand.c
https://github.com/miracl/MIRACL/blob/master/include/miracl.h
https://github.com/miracl/MIRACL/blob/master/docs/miracl-explained/reference-manual/low-level-routines.md

LITERATURE-SEARCH LIMIT

This was a bounded search of primary sources, not an exhaustive literature
review. The shared half-generator pattern was already public; no recovered
historical recipe was found in the sources inspected. The mathematical
exclusions above may be useful research contributions, but priority has not
been established. No publication or contact with third parties was made.
