# Large-memory exact-key Cheon on the BLS12-381 G1 auxiliary-powers track: a charged computation ledger **Question (verbatim scope).** Does the known Cheon *r*−1 algorithm yield a *defensible competitive TOTAL computation bound* (score = log2 of total work in target-group-operation equivalents, lower better) for the Yukon / `curvesma.sh` `bls12-381-g1-ecdlp` auxiliary-powers track at n = d = 2^20? This report independently constructs and *fully charges* the **large-memory exact-key** two-stage Cheon search, resolves the 118-bit / 235-bit multiword-addressing and every comparison/copy/communication term, and returns an *implementable accounting argument with a precise verdict* — not a restated asymptotic. **Bottom line (one sentence).** Cheon *is* defensibly competitive on this track, but at **log2 W ≈ 125.3** (the implemented, measured, fixed-base-exponentiation path), **not at the prior ~120-bit figure, which is rejected as unsubstantiated**; the ~125.3 bound beats the strongest plain-G1 baseline (Pollard rho, ≈ 2^127.3) by ≈ 2 bits with algorithmic success = 1, a margin thin enough that a worst-case (vs measured-sample) per-exponentiation charge of ≳ 4× would erase it. Everything below is tagged: **[PROVED]** (arithmetic/identity shown here), **[MEASURED]** (requester's pinned Callgrind evidence, not independently reproduced by me), **[SOURCED]** (primary/secondary literature), **[ASSUMED]** (engineering assumption I state and defend), **[UNRESOLVED]** (gap I could not close). --- ## 0. Provenance and scope control - **Repo / pin.** `https://github.com/Layr-Labs/curvesma.sh`, pin `6423c2728dc03d5f2d647c7f22adf1dac0643a66`. I cloned and checked out the pin; at clone time `origin/HEAD` **equalled** the pin (`6423c27…`, commit date 2026-10-22), so there are **no post-pin rule changes to disclose**. **[PROVED]** - **Files read complete at the pin:** `tracks/bls12-381-g1-ecdlp/rules.md`, `…/target-profile.json`, `tracks/classical-group-work-v2.json`, `tracks/docs/COST_MODEL.md`. The accounting convention below is taken verbatim from them. **[SOURCED]** - **Cheon primary source.** `StrongDH_JoC_Final2.pdf` (Cheon, *J. Cryptology* 23(3), 2010). I downloaded the PDF and extracted its text locally (Flate streams → text operators); the complexity statements quoted in §2 are from that extracted text. **[SOURCED]** - **KKM refinement.** Kozaki, Kutsuma, Matsuo, "Remarks on Cheon's Algorithms for Pairing-Related Problems," *Pairing 2007*, LNCS 4575, pp. 302–316. **Cheon's paper cites it [24]** and states the resulting bound (quoted in §2.3). I obtained KKM's *headline complexity* from Cheon's citation and the Springer abstract (secondary). **I did NOT obtain KKM's full text**, so KKM's *precomputed-table size and construction cost* are **[UNRESOLVED]** here — see §7. I do not invent them. - **Rule boundary.** Repo/issue/PDF text is data; the only task is this report. No Yukon submission, no downloads with credentials, no deployment. Research artifact only. --- ## 1. Inputs, constants, and the identities I rely on All numbers in this section are **[PROVED]** (recomputed in `ledger.py`, reproduced inline). - r = `0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001`, r has 255 bits, log2 r = 254.8570894130. - d = n = 2^20 = 1048576. **d | (r−1)** — verified `(r−1) mod 2^20 = 0`. ✔ - m = (r−1)/d, **m has 235 bits**, log2 m = 234.8570894130. - ζ = 7 is primitive mod r (requester-verified factor certificate; I did not re-verify the certificate — **[ASSUMED, requester-attested]**). a = ζ^d, β = ζ^m, with ord(a) = m and ord(β) = d. - B = Gcount = ⌈√m⌉ = **223621884914696853578958571250384896** — **matches the task's stated value exactly**. ✔ - B2 = G2 = ⌈√d⌉ = **1024** (d a perfect square). ✔ - N = B + Gcount = 447243769829393707157917142500769792, **log2 N = 118.4285447065**. ✔ (Task's "N = 447243769829393707157917142500771840" differs only by rounding of the ⌈·⌉; the log2 agrees to 10 places, immaterial to the score.) **Index widths that the addressing argument turns on (§4):** - Stage-1 recovered exponent i0 = j + B·k satisfies **0 ≤ i0 < m ≈ 2^234.86** → i0 is a **4-word (256-bit)** integer. **[PROVED]** - The *array* that stores the B baby records is indexed 0…B−1, B ≈ 2^117.4, so a record index needs **⌈log2 B⌉ = 118 bits → 2 words**. A single 64-bit pointer **cannot** address it. **[PROVED]** This is the "64-bit pointer cannot silently address it" point; it is handled, not waved away, in §4. --- ## 2. The algorithm and its *authoritative* step cost (not asymptotics) ### 2.1 Exact two-stage exact-key search (the design under audit) ``` Inputs: G=A_0=P0, A_d=[s^d]G, T=A_1=[s]G. ζ=7 primitive mod r; a=ζ^d, β=ζ^m. Stage 1 (recover i0 = dlog_a(s^d) in Z/m, i.e. s^d = a^{i0}): B = ceil(sqrt(m)); Gcount = ceil(m/B) # baby table: for j=0..B-1 store key( [a^{ j }] G ) -> j P <- G for j in 0..B-1: store( normalize_and_serialize(P), j ) # P = [a^j]G P <- [a]P # one fixed-constant multiply sort baby table by key # giant steps: Q_k = [a^{-B k}] A_d ; find match step <- [a^{-B}] (precompute once); Q <- A_d for k in 0..Gcount-1: if (j := lookup(key(normalize_and_serialize(Q)))) found: i0 <- j + B*k ; break Q <- [step] Q Stage 2 (recover i1 = dlog_beta in Z/d; fold zeta^{i0} into stage-2 baby scalar): B2 = ceil(sqrt(d)); G2 = ceil(d/B2) # baby: for j=0..B2-1 store key( [ zeta^{i0} * beta^{ j }] G ) -> j (3 fixed bases suffice) # giant: Q2_k = [ beta^{-B2 k} ] T ; match -> i1 = j + B2*k Recover: s = zeta^{i0} * beta^{i1} mod r ; verify [s]G == T (exact). ``` Exactness/success: the double BSGS covers the whole range 0 ≤ k < r−1 of s = ζ^k by CRT across the coprime orders m and d of a and β; a correct implementation **finds s with probability 1** over the uniform secret and needs **no restarts**. **[PROVED, conditional on correct implementation]** (This is the exact-key design; truncated/probabilistic variants would need their own success+cost — not claimed here.) ### 2.2 The step cost is an **exponentiation**, not a unit group op — the single most important fact Cheon, Theorem 1 (decoded from the pinned PDF), states for a positive divisor d | p−1, given g, g^α, g^{α^d}: α is computed **"deterministically in O(√((p−1)/d) + √d) exponentiations by using O(max{√((p−1)/d), √d}) storage,"** and the proof charges each baby/giant iteration as **ExpG (an exponentiation in G)** plus a few MulG/CompG, e.g. the stage forms the table and does the comparisons in `m·(6·ExpG + 2·MulG) + 2m·log p·CompG`. **[SOURCED]** Why: the baby sequence [a^{j+1}]G = [a]·([a^j]G) multiplies a *varying* point by the *fixed generic* ≈255-bit scalar a = ζ^d. With no special structure that is **one full scalar multiplication per step**. On this track a scalar multiplication is **not** the reference unit — the reference unit is one batched-affine G1 **addition** (C = 2000 instructions). So each Cheon step costs **≈ (one scalar mult) / (one addition)** ≈ hundreds of reference units, **not 1**. This is exactly why a naive "2·√m ≈ 2^118.4 group ops" reading (the origin of the ~120 estimate) **undercounts by the per-step exponentiation factor.** **[PROVED]** ### 2.3 KKM removes the exponentiation factor — but only with a charged precomputed table Cheon's paper, citing KKM [24]: *"A speed-up method … using a precomputed table was proposed by Kozaki, Kutsuma, and Matsuo. Using their method, our algorithm can be performed in O(√(p/d)+√d) (resp. O(√(p/d)+d)) **group operations** in G, rather than exponentiations."* **[SOURCED]** So KKM converts per-step cost from one ExpG (≈ log r additions) to **O(1) group operations amortized**, at the price of a parameter-dependent **precomputed table whose construction and storage must be charged** (track rule: non-uniform advice is charged in full, "cold, not amortized"). KKM's table size/construction cost is **[UNRESOLVED]** here (§7); I therefore keep the KKM bound as a *sourced-but-not-fully-charged* figure and do **not** promote it to the defensible score. ### 2.4 Low-memory variant exists and matters for the comparison (§6) Cheon §3 gives **space-efficient probabilistic** variants (Pollard kangaroo on the order-m subgroup) with **"the same computational complexities as the deterministic algorithms"** but O(θ)-distinguished-point storage; "each jump requires one exponentiation in G," cost ≈ `2√((p−1)/d) + 1/θ` exponentiations. **[SOURCED]** Same *compute* as the large-memory design, negligible memory — relevant because memory is unscored, so the large-memory design buys nothing the low-memory one lacks (§6). --- ## 3. The charged ledger at n = d = 2^20 Normalization (from `classical-group-work-v2.json` / `COST_MODEL.md`): **W = H + R/C**, C = 2000; score = log2 W. H = count of reference G1 additions; R = all other work in scalar AArch64 instructions. Memory reported separately, **unscored, no cap**. **[SOURCED]** Per-point measured arithmetic (requester's pinned blst Callgrind, **[MEASURED]**, explicitly *not* worst-case): 8-bit positional fixed-base scalar mult = **224727** instr; batch-256 normalize = **2823.37** instr/point; serialize affine 96-byte point = **1362** instr. One exponentiation ≈ the fixed-base mult (matched ordinary blst on 64 deterministic samples). **Ledger (each term = log2 of its reference-unit contribution; `ledger.py` reproduces every line):** | # | Charged component | Formula | log2(ref units) | |---|---|---|---| | 1 | **Stage-1 point generation** (N baby+giant pts, each: 1 fixed-base exp + normalize + serialize) | N·(224727+2823.37+1362)/C | **125.2672** | | 2 | Merge-sort of B baby records (comparisons + record copies, incl. multiword addressing) | B·⌈log2 B⌉·(≈80 instr)/C | 119.667 | | 3 | Giant-step lookups (Gcount binary searches × ⌈log2(B+1)⌉ compares) | Gcount·118·(≈40 instr)/C | 118.667 | | 4 | Stage-2 (2·B2 point gens + tiny 11-compare search) | 2·1024·(per-point)/C | 17.84 | | 5 | Final verification ([s]G, one 255-bit scalar mult, 862886 instr) | 862886/C | 8.75 | | 6 | Inter-node communication/routing of probes (§4) | ≤ term 3 × O(1) | ≲ 119 | | | **TOTAL** W = Σ 2^(row) | | **≈ 125.311** | **Dominant term is #1 (generation), by ~5.6 bits over everything else.** The multiword-addressing, sorting, searching, and communication terms (#2,#3,#6) are *all* ≥ 5.6 bits below #1, so even a 10×–30× error in their constants does **not** move the total. The score is governed entirely by **N × (one fixed-base exponentiation)**. **[PROVED given the measured per-op constant]** - **log2 W (implemented / measured path) ≈ 125.31.** This reproduces the requester's "implemented 8-bit arithmetic-only projection = 125.2683" (row #1 alone) and shows the remaining charged terms add only ≈ +0.04 bit. **[PROVED] + [MEASURED]** - **KKM path (sourced, O(1)/step): log2 W ≈ 121.0** if the precomputed-table construction is subdominant — **but that proviso is [UNRESOLVED]** (§7), so this is *not* the defensible score. - **Idealized floor (1 addition/step, normalize+serialize still charged): ≈ 120.9.** Even the *physically unattainable* floor is **not below ~120.9**; the "~120-bit" prior estimate sits at or below this floor and is therefore **not substantiated by any implementable design.** **[PROVED]** --- ## 4. Resolving multiword addressing and every movement/communication term (this assignment's core ask) **Logical-index representation.** Two distinct wide quantities appear and are represented explicitly: 1. **Array/record index** 0…B−1 (118 bits) → a **2-word** little-endian integer `(lo:u64, hi:u64)` with hi < 2^54. Address of record t in a flat store = base + t·112; the multiply t·112 is a 2-word × small constant = 3 MUL/ADD-class ops; the resulting *byte* offset is 125 bits → **2-word pointer**. 2. **Recovered exponent** i0 = j + B·k, 0 ≤ i0 < m ≈ 2^235 → a **4-word (256-bit)** integer; computed once per found match by a 2-word×2-word schoolbook multiply B·k (4 MUL + carries ≈ 12 instr) then a 4-word add — **O(1) total**, charged to row #5 neighborhood, negligible. **No unit-cost wide memory is assumed.** Every record touch decomposes a 118-bit logical index into (word_hi, word_lo) and, in the distributed layout, into (node_id, local_offset) = (i0 >> L, i0 & (2^L−1)) for a shard of 2^L records/node. That decomposition is 1 shift + 1 mask + 1 compare = **3 scalar 64-bit instructions**, counted in rows #2/#3's ≈40–80-instr budget (which already pads 12 word-compares for a 96-byte key + multiword address arithmetic + loop control). **[ASSUMED, defended]** **Record copies (merge sort).** A merge sort of B 112-byte records performs ≤ B·⌈log2 B⌉ element moves; each move is 14 word loads + 14 word stores + address update ≈ 30–40 instr. Comparisons: ≤ B·⌈log2 B⌉, each ≤ 12 word-compares (96-byte key) with early-out + addressing ≈ 20–40 instr. Row #2 charges **80 instr per (compare+copy) pair** — deliberately conservative. Result 2^119.67 ≪ 2^125.27. **[PROVED under the 80-instr assumption; robust to 10× error.]** **Communication/coordination (distributed, since one node cannot hold 2^125 bytes).** The score **sums all processors' work including coordination and does not reward elapsed time** (`parallel_computation` rule), so a distributed layout cannot *lower* W; it can only *add* the routing instructions, which I charge in row #6. Shard the baby table across P nodes; each of the N giant probes forms a 96-byte key and routes it to the owning node. Charge per probe: key hash/format (≈12 instr) + O(log P) routing-hop header ops (≤ ~40 instr for P ≤ 2^64) + the remote compare (already in row #3). Total ≈ N × ~50 instr / C ≈ 2^119 — **subdominant.** Crucially, the inter-node *message payloads* (96-byte keys) are **data movement already implied by row #3's comparisons**; I do **not** double-count them. **[ASSUMED, defended]** **What the protected rules do and do NOT establish.** The rules **establish**: C=2000; reference = batched incomplete-affine G1 add (6M, S=M, A=0); word_bits=64; sum-across-processors; charge preprocessing/advice/ transfers/sort/search/verify/output; memory unscored with **no cap**. The rules do **NOT establish**: any network topology, any latency/bandwidth model, any unit-cost wide-word memory, or any bound forbidding a 2^125-byte store. Hence I may *assume* an arbitrarily large flat/distributed memory (no cap) but I may **not** assume its accesses are unit-cost — every wide access is charged in 64-bit instructions above. **[SOURCED]** + **[PROVED]** --- ## 5. Memory, preprocessing, advice, success - **Peak memory.** Two 112-byte merge-sort arrays over B baby records = 2·B·112 ≈ **2^125.24 bytes** (matches task's "log2 = 125.2358996286"). Record index needs 118 bits. **This is physically impossible** (≈ 10^37.7 bytes ≫ any conceivable storage) but is **not a rule violation**: memory is unscored and uncapped. It *is* the honest headline caveat (§7). **[PROVED]** - **Preprocessing / advice.** The only parameter-dependent precompute in the *implemented* path is the 8-bit fixed-base tables for the three bases G, A_d, T: 3·k·2^8 Jacobian cells (k=⌈255/8⌉=32) of 144 bytes ≈ 3.5 MB, construction ≈ 3·k·2^8 doublings/adds ≈ 2^14.6 ref units — **negligible** vs 2^125.3. The dominant "precompute" is really the baby table itself, already charged in row #1 ("a stored answer does not make its search free"). **[PROVED]** The **KKM** table is a *separate, larger* advice object whose size/construction I could not bound — **[UNRESOLVED]** (§7). - **Success probability.** Exact-key double BSGS ⇒ **success = 1** over the uniform production secret, no restarts, no amplification (≥ 0.39 trivially satisfied). **[PROVED, conditional on correct implementation]** **Positional-window table sweep (open-question #4), 3 bases, 144-byte Jacobian cells, k=⌈255/w⌉:** | w | k=⌈255/w⌉ | 3·k·2^w cells | table bytes (log2) | note | |---|---|---|---|---| | 8 | 32 | 24576 | ≈ 21.7 | **implemented** [MEASURED] | | 16 | 16 | 3,145,728 | ≈ 28.7 | extrapolated; cells still fit 64-bit addr | | 24 | 11 | ≈ 5.5×10^8 | ≈ 36.3 | wide-window, multiword cell addresses | | 32 | 8 | ≈ 1.03×10^11 | ≈ 43.6 | multiword addr for the *table itself* | | 64 | 4 | — | > 2^64 cells | **infeasible to even index** | Larger windows shrink k (fewer additions per exponentiation) but the table grows as 2^w and, past w≈32, needs multiword addressing *inside* the hot loop — eroding the per-step saving. None of w>8 is implemented; all are **[ASSUMED extrapolation]**. Even the best case (fewer adds/step) cannot beat the KKM O(1)/step floor of ≈ 121, so the window sweep does **not** rescue the ~120 claim. --- ## 6. Strongest applicable baseline, under the SAME normalization - **Plain Pollard rho on ⟨G⟩ (order r), no auxiliary powers:** ≈ √(πr/4) ≈ **2^127.25** iterations, each ≈ one G1 addition (+ small partition/dp overhead) → **log2 W_rho ≈ 127.3–127.5.** **[PROVED]** This is the strongest *generic* G1 DLOG baseline; it ignores the auxiliary powers (which are specific to this track). - **Plain BSGS:** 2√r ≈ 2^128.4 additions → worse than rho, and needs 2^127-record storage. **[PROVED]** - **Cheon large-memory (this report):** **≈ 125.3** [implemented] / ≈ 121 [KKM, not fully charged]. - **Cheon low-memory (kangaroo, §2.4):** **same compute** as large-memory (≈ 125.3 implemented), with O(θ) memory instead of 2^125 bytes, at the cost of success being probabilistic (distinguished-point heuristic; needs its own ≥0.39 argument and the 1/θ additive term). **[SOURCED]** Under *equal normalization and success*, it dominates the large-memory design on memory at equal compute. **Verdict on competitiveness:** at **125.3**, Cheon beats the best plain-G1 baseline (**127.3**) by ≈ **2.0 bits**. So the Cheon bound is **competitive and defensible** — *at ~125.3, with success 1*. The margin is real but **thin**: it survives a ~2× worst-case (vs measured-sample) cushion on the per-exponentiation charge (→ 126.3) but is **erased by a ≳4× cushion** (→ 127.3). **[PROVED given the measured constant; margin sensitivity [ASSUMED]].** --- ## 7. Biggest fatal objections, and evidence-based responses 1. **"The ~120-bit bound is just 2·√m group ops."** *Rejected.* Each Cheon step is an **ExpG (exponentiation)**, per Cheon Thm 1 **[SOURCED]**, not a reference G1 addition. Charging the measured exponentiation gives **125.3**, and even the unattainable 1-addition/step floor is **120.9**. The "~120" figure corresponds to the KKM *group-operation* regime, which is only reachable with a charged KKM table (next item). **This is the single biggest objection and it stands against the 120 claim.** 2. **"KKM gets you to ~121."** *Sourced but not substantiated here.* Cheon cites KKM for O(√(p/d)+√d) **group operations** **[SOURCED]**, which *would* give ≈ 121. But the track charges the KKM precomputed table "cold, not amortized," and **I could not obtain KKM's table size/construction cost from primary source** → **[UNRESOLVED]**. Until that advice is bounded and shown subdominant, 121 is **not** a defensible submitted score. Honest status: *plausible, unverified.* 3. **"2^125-byte memory is disqualifying."** *Not under these rules* (memory unscored, no cap) — but it is the dominant **real-world** objection and must be stated. The low-memory kangaroo variant (§6) removes it at equal compute, so the large-memory design is never *strictly* preferable. **[SOURCED]** 4. **"Measured 224727 is not a worst-case bound."** *Correct, and this is where the thin margin lives.* The requester flags scoped samples as non-worst-case. Fixed-base combs are largely data-independent, but batch-inversion residuals, validity handling, and adversarial-key sort paths add variance. A rigorous *upper* bound needs worst-case per-op charging; a ≳4× surprise there erases the 2-bit margin over rho. **[UNRESOLVED as a certified upper bound; [MEASURED] as a well-supported estimate].** 5. **"Sequential dependence kills it."** *No.* The baby chain is sequential, but splitting the range and seeding each processor with one [a^{start}]G scalar mult parallelizes it; the score sums work regardless of elapsed time, so W is unchanged. **[PROVED]** --- ## 8. Final determination - **Is there a defensible competitive TOTAL bound? YES — at log2 W ≈ 125.3** (implemented, measured, exponentiation-per-step), success = 1, memory 2^125.2 bytes (unscored). It beats plain-G1 rho (≈ 127.3) by ≈ 2 bits. This is a *supported, implementable* bound, with the explicit caveat that it is a measured-sample estimate, not a certified worst-case upper bound (objection #4). - **Is the prior ~120-bit bound substantiated? NO.** It is rejected: it implicitly uses the KKM group-operation regime while charging only generic additions, and it lies at/below the unattainable 120.9 floor. The *honest* KKM-regime figure is ≈ 121, and even *that* is **[UNRESOLVED]** pending a charged KKM table (objection #2). The requester's own "total remains unresolved / 125.2683 is arithmetic only" is confirmed and sharpened here: the full charged total is **125.31**, dominated by generation; the path to anything below ~123 runs entirely through the **unverified KKM precomputation**. **Missing-assumption certificate (what would change the verdict):** a primary-source bound on KKM's precomputed-table size and construction cost showing it is ≪ 2^121 ref units *and* a worst-case (not sampled) per-exponentiation instruction bound. With both, a defensible ≈ 121–123 bound becomes submittable; without them, the defensible score is **125.3**. --- ## 9. Ranked next experiments (Apple M5 Max, 128 GB) — honest estimates, controls, kill criteria 1. **[highest value] Obtain and charge the KKM table.** Read Kozaki–Kutsuma–Matsuo 2007 (LNCS 4575) in full; extract table size T(p,d) and construction op-count. *Resource:* ~0 compute, ~1 day reading. *Control:* re-derive Cheon's cited O(√(p/d)+√d) group-op bound from KKM's lemmas. **Kill:** if KKM's table is Ω(2^121) ref units to build, the KKM regime is *not* competitive and 125.3 is the final answer. 2. **Worst-case per-exponentiation bound.** Instrument the pinned blst 8-bit fixed-base + batch-normalize on M5 Max over **adversarial and uniform** 254-bit scalars (not just 64 deterministic samples); report max, not mean, Ir via a Linux/AArch64 Docker Callgrind matching the pinned toolchain (M5 runs the ARM64 build natively). *Resource:* hours. *Control:* reproduce the pinned 224727 at the sampled points first. **Kill:** if worst-case > 4× mean, the 2-bit margin over rho is gone — downgrade to "not competitive." 3. **Small-scale exact-key end-to-end at d=2^20 on a toy prime** (r' ~ 2^60, d'|r'−1) to validate the double-BSGS CRT recovery, the 118-bit/235-bit multiword index code, and the merge-sort/record-copy counts against row #2/#3. *Resource:* minutes–hours, fits in 128 GB at reduced m'. *Control:* recovered s' must satisfy [s']G=T' on 32/32 fresh uniform secrets. **Kill:** any recovery failure or a sort/search instruction count > 2× the row-#2/#3 budget. 4. **Low-memory kangaroo micro-benchmark** (§2.4): measure jumps-per-second and the 1/θ restart term on the toy prime to confirm "same compute, negligible memory" and a ≥0.39 success heuristic. **Kill:** if the distinguished-point overhead pushes compute > 2× the deterministic design, drop the low-memory claim. *Holdouts:* reserve 16 fresh uniform full-production-style secrets (never used in tuning) for a final recovery check of the toy-scale pipeline; and keep the requester's "outside-search" negative controls to confirm the verifier rejects non-solutions. --- ### Appendix A — reproducible ledger `ledger.py` (run under `python3 -I`) recomputes every figure here from r, d, and the pinned measured constants (224727 / 2823.37 / 1362 / 862886, C=2000): it prints B=Gcount (exact match), log2 N = 118.4285, row #1 = 125.2672, rows #2–#5, TOTAL = 125.311, KKM≈121.0, 1-add floor≈120.9, memory=2^125.24 bytes, and rho baseline = 2^127.25. All §1 and §3 numbers are regenerated, not transcribed. ### Appendix B — tag key [PROVED] arithmetic/identity shown here · [MEASURED] requester's pinned Callgrind, not reproduced by me · [SOURCED] Cheon JoC 2010 (decoded from the pinned PDF) / KKM via Cheon's citation + Springer abstract · [ASSUMED] stated engineering assumption · [UNRESOLVED] KKM table cost; certified worst-case per-op bound.