Archive external benchmark outside active FOG

5 files changed, 49 insertions, 248 deletions

diff --git a/docs/FOG-CRYPTO-BENCHMARKS.md b/docs/FOG-CRYPTO-BENCHMARKS.md
deleted file mode 100644
index 9f6ea21..0000000
--- a/docs/FOG-CRYPTO-BENCHMARKS.md
+++ /dev/null
@@ -1,182 +0,0 @@
-# FOG Cryptographic Benchmark Baseline
-
-## 1. Status
-
-This document records the first reproducible implementation benchmark for the
-non-active candidates in `FOG-CRYPTO-SUITES.md`.
-
-It is an engineering baseline, not a profile selection or activation. It does
-not establish anonymity, post-quantum security, constant-time behavior,
-production capacity, or interoperability.
-
-The executable harness and complete three-sample data are in:
-
-- `../benchmarks/crypto/`
-- `../benchmarks/crypto/results/2026-08-08-x86-64-i5-6300u.md`
-
-## 2. Snapshot
-
-The first host is an Intel Core i5-6300U with two physical cores and four
-threads, running Linux amd64, Go 1.26.5, `GOAMD64=v1`, and the `powersave`
-governor. It is useful as an older low-power x86-64 baseline, but it is not a
-substitute for the required server, ARM64, and offline Composer classes.
-
-The Go module pins:
-
-- Katzenpost `v0.0.97`;
-- HPQC `v0.0.85-0.20260715190213-e598e7ee2843`;
-- the complete transitive graph in `go.mod` and `go.sum`.
-
-The harness is isolated from future daemons. It has no network listener,
-persistent state, runtime suite registry, packet autodetection, algorithm
-fallback, or profile activation path.
-
-## 3. Coverage
-
-The measured operations are:
-
-- SHA3-256 over 4 KiB, 128 KiB, 1 MiB, and 8 MiB objects;
-- ML-DSA-65 plus Ed25519 key generation, signing, valid verification, and
-  verification with either component invalid;
-- ML-KEM-768, X25519 hashed-ElGamal, the exact HPQC split-PRF KEM, and X-Wing
-  key generation, encapsulation, and decapsulation;
-- four-logical-CPU parallel decapsulation for the two hybrid candidates;
-- exact four-hop KEMSphinx forward construction, SURB construction, each hop
-  unwrap, all-hop unwrap, reply construction, and full request/reply crypto.
-
-The harness verifies both composite signature components over the same opaque
-input before combining their results. It performs no component fallback.
-
-## 4. First-Host Medians
-
-All sequential values below use one logical CPU and the median of three
-500 ms calibrated samples. The host was not frequency-locked or isolated, so
-the raw ranges remain authoritative.
-
-### 4.1 PKI
-
-| Operation | 4 KiB | 128 KiB | 1 MiB | 8 MiB |
-| --- | ---: | ---: | ---: | ---: |
-| SHA3-256 | 19.2 us | 0.567 ms | 4.71 ms | 37.7 ms |
-| composite sign | 1.16 ms | 2.33 ms | 11.0 ms | 78.5 ms |
-| composite verify | 0.254 ms | 1.15 ms | 12.0 ms | 57.9 ms |
-
-Composite key generation measured 0.460 ms. The benchmark framing uses a
-1,984-byte public key and 3,373-byte signature. These sizes do not define the
-pending canonical FOG PKI encoding.
-
-At 128 KiB, an invalid ML-DSA-65 component measured 1.13 ms while an invalid
-Ed25519 component measured 0.715 ms. Both components were evaluated, but the
-paths were not timing-uniform. Focused statistical and implementation review
-is required before accepting a remote failure surface.
-
-### 4.2 Hybrid KEMs
-
-| Construction | key generation | encapsulation | decapsulation |
-| --- | ---: | ---: | ---: |
-| HPQC ML-KEM-768 plus X25519 split-PRF | 0.348 ms | 0.515 ms | 0.460 ms |
-| X-Wing | 0.180 ms | 0.275 ms | 0.365 ms |
-
-Both constructions use a 1,216-byte public key and 1,120-byte ciphertext in
-this dependency snapshot. The split-PRF private serialization is 1,280 bytes;
-X-Wing is 1,248 bytes.
-
-X-Wing is faster in this local snapshot. That result supports continued
-FOG-WIRE evaluation only. It does not satisfy the distinct KEMSphinx combiner
-proof obligation and cannot silently replace the retained split-PRF candidate.
-
-### 4.3 Complete KEMSphinx Geometry
-
-| Operation | Median | B/op | allocs/op |
-| --- | ---: | ---: | ---: |
-| build forward packet | 2.43 ms | 177,492 | 391 |
-| create SURB | 2.33 ms | 123,668 | 348 |
-| unwrap one hop | 0.515 to 0.519 ms | about 32,560 | 80 to 81 |
-| unwrap all four hops | 2.04 ms | 130,192 | 323 |
-| build reply from existing SURB | 11.6 us | 28,368 | 14 |
-| full request/reply crypto | 8.89 ms | 653,450 | 1,452 |
-
-The complete operation covers two 16,150-byte packets, eight total unwraps,
-one 6,058-byte SURB, and one 320-byte private reply-key block. It excludes
-persistent replay insertion, wire I/O, queues, mixing delay, storage, and cover
-traffic.
-
-The timing is acceptable for continued simulation and implementation
-profiling on an old mobile CPU. The allocation volume is not yet acceptable as
-capacity evidence and must be included in bounded-load and denial-of-service
-work.
-
-## 5. Exact-Length Integration Finding
-
-The evaluated Katzenpost API is intentionally parameterized. Direct
-`Unwrap` use did not impose FOG's exact external packet length and accepted a
-packet shortened by one byte.
-
-FOG therefore needs an explicit protocol boundary before the cryptographic
-library. The benchmark module implements a narrow adapter that requires:
-
-- exactly four path hops;
-- exactly 10,156 forward or reply payload bytes;
-- exactly 16,150 packet bytes;
-- exactly 6,058 SURB bytes;
-- exactly 10,188 encrypted reply bytes, including the payload tag;
-- exactly 320 private reply-key bytes.
-
-Both shorter and longer inputs fail before cryptographic processing. The
-adapter does not add a primitive or alternate wire format. Equivalent strict
-checks are mandatory in any future FOG implementation and conformance corpus.
-
-## 6. Deliberate Exclusions
-
-No Noise benchmark is published because FOG has not selected exact reviewed
-entry and mutual post-quantum handshake patterns. A primitive X-Wing result is
-not a Noise handshake result.
-
-No PQXDH, Triple Ratchet, or ML-KEM Braid result is published because the
-complete FOG message integration and supported implementation path remain
-unselected. Rust was also absent on the first host.
-
-The first harness also does not supply:
-
-- peak live memory or stack-use evidence;
-- persistent replay-database cost;
-- p50, p95, or p99 latency under bounded adversarial load;
-- malformed-input timing distributions or dudect-style testing;
-- fuzzing, sanitizer, or cross-implementation vectors;
-- current server, ARM64, or offline Composer measurements;
-- queue, bandwidth, cover-traffic, or long-term disclosure results;
-- a complete vulnerability, license, AEZ, or side-channel review.
-
-Direct HPQC and Katzenpost dependencies are AGPL. Their use here is evaluation
-only and does not decide the future FOG distribution license.
-
-## 7. Selection Consequences
-
-This baseline makes the following limited decisions possible:
-
-1. Retain SHA3-256 and ML-DSA-65 plus Ed25519 for continued PKI encoding,
-   vector, separability, timing, and implementation work.
-2. Retain the exact HPQC ML-KEM-768 plus X25519 split-PRF construction for the
-   calculated KEMSphinx geometry.
-3. Retain X-Wing as the leading KEM to evaluate inside a future exact reviewed
-   FOG-WIRE Noise construction.
-4. Require an exact-length FOG boundary around the maintained KEMSphinx API.
-5. Move next to the privacy and capacity simulator while leaving every
-   cryptographic candidate non-active.
-
-No numeric suite or packet profile ID is assigned.
-
-## 8. Required Next Evidence
-
-Before activation, repeat and extend the matrix on:
-
-- a current x86-64 server;
-- a lowest-supported ARM64 node or Composer;
-- the intended offline Composer hardware;
-- a controlled host with fixed governor, CPU isolation, and recorded thermal
-  behavior.
-
-Then add exact Noise handshakes, complete messaging operations, persistent
-replay work, tail latency, memory profiles, fuzzing, deterministic positive and
-negative vectors, dependency and license review, side-channel review, and an
-independent implementation or integration.
diff --git a/docs/FOG-CRYPTO-SUITES.md b/docs/FOG-CRYPTO-SUITES.md
index 48402c1..e9aee7f 100644
--- a/docs/FOG-CRYPTO-SUITES.md
+++ b/docs/FOG-CRYPTO-SUITES.md
@@ -155,10 +155,10 @@ collapse honestly to one marketing figure.
 
 | Security role | Leading result | Status after this evaluation |
 | --- | --- | --- |
-| PKI object hash | SHA3-256 | first-host benchmark complete, still non-active |
-| PKI signatures | ML-DSA-65 plus Ed25519, both mandatory over one FOG-bound input | first-host benchmark complete, still non-active |
-| KEMSphinx KEM | HPQC ML-KEM-768 plus X25519 split-PRF construction in the already calculated order | first-host complete-packet benchmark complete, still non-active |
-| KEMSphinx remaining primitives | evaluated Katzenpost KDF, MAC, stream, AEZ SPRP, and payload-tag integration | hold pending side-channel, AEZ, multi-host, and complete implementation review |
+| PKI object hash | SHA3-256 | candidate only, no active FOG benchmark |
+| PKI signatures | ML-DSA-65 plus Ed25519, both mandatory over one FOG-bound input | candidate only, no active FOG benchmark |
+| KEMSphinx KEM | ML-KEM-768 plus X25519 split-PRF construction in the already calculated order | geometry candidate only, implementation and benchmark pending |
+| KEMSphinx remaining primitives | exact KDF, MAC, stream, SPRP, and payload-tag integration | no FOG implementation selected |
 | Noise KEM | X-Wing is the leading construction to evaluate | component candidate only |
 | Noise profile | exact PQ entry and mutual-authentication profiles | hold, no FOG profile selected |
 | End-to-end handshake and ratchet | PQXDH revision 3 plus Triple Ratchet revision 4 plus ML-KEM Braid revision 1 | retained and advanced to integration and geometry review |
@@ -651,9 +651,9 @@ fixed response. A second algorithm is never tried after failure.
 ## 16. Benchmark Contract
 
 The benchmark phase measures complete protocol operations, not primitive
-microbenchmarks alone. `FOG-CRYPTO-BENCHMARKS.md` records the first-host
-implementation baseline. That partial completion does not relax the remaining
-hardware, operation, review, or activation requirements below.
+microbenchmarks alone. FOG currently has no active cryptographic implementation
+benchmark. No archived external experiment satisfies or relaxes the hardware,
+operation, review, or activation requirements below.
 
 ### 16.1 Required hardware classes
 
@@ -701,23 +701,13 @@ The benchmark harness also runs or records:
 
 Passing statistical tests is evidence, not proof of constant-time behavior.
 
-### 16.4 First-host baseline
+### 16.4 Active evidence status
 
-The pinned Go harness in `../benchmarks/crypto/` completed the first older
-x86-64 baseline for SHA3-256, composite PKI operations, candidate KEMs, and the
-exact four-hop 16,150-byte KEMSphinx request/reply path.
-
-The full request/reply cryptographic operation measured about 8.89 ms at the
-median, with about 638 KiB and 1,452 allocations per operation. Direct use of
-the parameterized maintained `Unwrap` API did not enforce FOG's exact external
-packet length, so the harness adds a typed FOG boundary that rejects all
-non-exact paths, packets, payloads, SURBs, encrypted replies, and reply-key
-blocks before cryptographic processing.
-
-The result retains the evaluated candidates without activating them. Raw
-three-sample data, environment details, exact sizes, exclusions, and observed
-timing variability are in
-`../benchmarks/crypto/results/2026-08-08-x86-64-i5-6300u.md`.
+No first-host or multi-host cryptographic benchmark is active. A historical
+external-library experiment is archived outside the FOG project and is not an
+implementation baseline, conformance result, dependency selection, or
+performance claim. Benchmark work restarts only after FOG selects a reviewed
+implementation boundary and records its exact dependency and license set.
 
 ## 17. Activation and Retirement
 
@@ -767,9 +757,9 @@ The following items remain before any cryptographic profile can become active:
 - publish the exact FOG PKI composite-key and signature-component encoding;
 - produce SHA3-256 domain vectors and the full PKI signature artifact analysis;
 - decide the implementation and license path for ML-DSA-65;
-- audit the pinned HPQC, Katzenpost, and AEZ dependency set;
-- repeat complete 16,150-byte KEMSphinx packet, SURB, and persistent replay
-  benchmarks on current server, ARM64, and offline Composer hardware;
+- select and audit the complete implementation, dependency, and license set;
+- execute complete 16,150-byte KEMSphinx packet, SURB, and persistent replay
+  benchmarks on x86-64, current server, ARM64, and offline Composer hardware;
 - select or produce a reviewed exact FOG entry and mutual PQNoise profile;
 - complete the PQXDH, Triple Ratchet, ML-KEM Braid, FOG envelope, and storage
   serialization and state integration;
@@ -826,8 +816,6 @@ The following items remain before any cryptographic profile can become active:
 - FOG wire protocol: `FOG-WIRE.md`
 - FOG KEMSphinx profiles: `FOG-SPHINX-PROFILES.md`
 - FOG messaging: `FOG-MESSAGING.md`
-- FOG cryptographic benchmark baseline: `FOG-CRYPTO-BENCHMARKS.md`
-
 These sources support the shortlist and its constraints. The exact FOG
 composition still requires its own vectors, tests, benchmarks, operational
 analysis, and independent review.
diff --git a/docs/FOG-PKI.md b/docs/FOG-PKI.md
index 4bc0ebd..5394f06 100644
--- a/docs/FOG-PKI.md
+++ b/docs/FOG-PKI.md
@@ -1784,7 +1784,6 @@ vectors. Implementations MUST NOT invent local defaults.
 - FOG storage protocol: `FOG-STORAGE.md`
 - FOG Composer protocol: `FOG-COMPOSER.md`
 - FOG cryptographic suite evaluation: `FOG-CRYPTO-SUITES.md`
-- FOG cryptographic benchmark baseline: `FOG-CRYPTO-BENCHMARKS.md`
 - FOG local Podman PoC: `FOG-LOCAL-POC.md`
 - NIST FIPS 204, Module-Lattice-Based Digital Signature Standard:
   <https://csrc.nist.gov/pubs/fips/204/final>
diff --git a/docs/FOG-SPHINX-PROFILES.md b/docs/FOG-SPHINX-PROFILES.md
index f1d32de..2c4aac8 100644
--- a/docs/FOG-SPHINX-PROFILES.md
+++ b/docs/FOG-SPHINX-PROFILES.md
@@ -764,12 +764,11 @@ complete-packet benchmarking but does not activate it. The unresolved
 non-KEM primitives and implementation evidence keep the complete profile
 non-active.
 
-`FOG-CRYPTO-BENCHMARKS.md` records a first-host benchmark of this exact
-geometry. Future implementations MUST preserve its strict integration
-finding: the parameterized maintained API is wrapped by a FOG boundary that
-rejects every path, packet, payload, SURB, encrypted reply, or reply-key length
-that differs from this profile before cryptographic processing. The first-host
-result does not change `geometry-only` status or assign a profile ID.
+No active FOG implementation benchmark exists for this geometry. Every future
+implementation MUST enforce the exact path, packet, payload, SURB, encrypted
+reply, and reply-key lengths at the FOG boundary before cryptographic
+processing. This requirement follows from the profile contract itself, not
+from an archived external implementation experiment.
 
 ### 18.2 Candidate primitive inputs
 
@@ -1158,7 +1157,6 @@ These risks must appear in deployment documentation and public claims.
   <https://www.rfc-editor.org/rfc/rfc7748>
 - FOG Composer protocol: `FOG-COMPOSER.md`
 - FOG cryptographic suite evaluation: `FOG-CRYPTO-SUITES.md`
-- FOG cryptographic benchmark baseline: `FOG-CRYPTO-BENCHMARKS.md`
 - FOG traffic and topology simulation: `FOG-SIMULATION.md`
 
 ## 31. Completion Checklist
diff --git a/merkle-tree.txt b/merkle-tree.txt
index fd588d9..43f6b83 100644
--- a/merkle-tree.txt
+++ b/merkle-tree.txt
@@ -5,45 +5,43 @@ leaf: SHA256(0x00 || uint64be(path_length) || path || uint64be(content_length) |
 node: SHA256(0x01 || left_hash || right_hash)
 shape: RFC 6962 recursive split at the largest power of two smaller than the leaf count
 scope: every repository file whose name ends in .md; merkle-tree.txt is intentionally excluded
-leaf-count: 18
+leaf-count: 17
 
 leaves:
 L00 9b9241e53e75e86897d8c0e67f4fd960041c7d8b0df0b7be70a109f08e8fd2ca 9576 README.md
 L01 415213d7b09f51e5c08f04d992dfe2f4635632924e4a4951723a7d66b793d985 8799 docs/FOG-ALPHA.md
 L02 50eeae3e905a5342bb9f8f45a004949c5c8d10968ce2fd994c817cbee645565a 55832 docs/FOG-ARCHITECTURE.md
 L03 adb3fcd7ff4946398c4868c0f062cbcffaa8a11797aba2375c6c3bdff1a61c41 78489 docs/FOG-COMPOSER.md
-L04 a1572dc0e269e2d8b6213344a37b4e96b2bb134c0b7f436b0dbe9ac79f96040a 7565 docs/FOG-CRYPTO-BENCHMARKS.md
-L05 5d3dede7d4cf14e18666758eee7c4fb2b19232e2102c586fe2e732f7fa74af84 37535 docs/FOG-CRYPTO-SUITES.md
-L06 012d873502c9bb3dae72ab98b5b72bab37cffe54b7d3213ac93099e0aded3102 16204 docs/FOG-LOCAL-POC.md
-L07 a1cb8c3915ce87a95215a22c4d77055ab9aeb055458d239f1910499c09218ad4 46508 docs/FOG-MESSAGING.md
-L08 682b534264fecb4ed31210529d9aeb85f9bbea88d29cd36c081662171d21f4a8 31602 docs/FOG-OBSERVABILITY.md
-L09 449455df488c4cf4bc0121e8d174e1164e7a1f0f404f36ed4716a5377b024ce1 67912 docs/FOG-PKI.md
-L10 ffcdc77522d694bcbc11be0ce28ab58f9928d097f56e20a46ff08950566ef211 6950 docs/FOG-POC-PRESERVATION.md
-L11 e36d9acf73343eb088a5ccac6c5528ab7334a40f5d88cae973674532279b0c22 6716 docs/FOG-SECURITY-TEST-PLAN.md
-L12 94050ece3310571d3758f80eb2b1867c1bb2ae7e2fe933814732fcf3ff1b32db 13908 docs/FOG-SIMULATION.md
-L13 6b6b795434bb471f0bac368bd0a18cc824fa956712f0c96f6b17a5b873ce3891 46401 docs/FOG-SPHINX-PROFILES.md
-L14 9c9017d04486a377ffd1d189a99c5cda1efe33040e9a22f28633d214d1aa6e97 67516 docs/FOG-STORAGE.md
-L15 9ec2dbb5b0d0c439aa3424e9da64fb26b4798e7fea7acaa3eb2c2290f98d6a36 43156 docs/FOG-SX.md
-L16 0595a5fe5da9fb8dbee2fac17b059f78028bc75d5ebc8863f1ac9a913c23bdde 43740 docs/FOG-THREAT-MODEL.md
-L17 370bba48b1424040bd9d74eace070b87afac1cc912f175d371f5838c2235c052 54012 docs/FOG-WIRE.md
+L04 8c9d2f59b2a205815daff3d04c7fdba6ab3169fee1bd1bc75dde95a13d4a4684 36901 docs/FOG-CRYPTO-SUITES.md
+L05 012d873502c9bb3dae72ab98b5b72bab37cffe54b7d3213ac93099e0aded3102 16204 docs/FOG-LOCAL-POC.md
+L06 a1cb8c3915ce87a95215a22c4d77055ab9aeb055458d239f1910499c09218ad4 46508 docs/FOG-MESSAGING.md
+L07 682b534264fecb4ed31210529d9aeb85f9bbea88d29cd36c081662171d21f4a8 31602 docs/FOG-OBSERVABILITY.md
+L08 99c0c0d1c130741a2fbf330aadf7bf1c6a4677028d5b413a656dc90ce53e1396 67845 docs/FOG-PKI.md
+L09 ffcdc77522d694bcbc11be0ce28ab58f9928d097f56e20a46ff08950566ef211 6950 docs/FOG-POC-PRESERVATION.md
+L10 e36d9acf73343eb088a5ccac6c5528ab7334a40f5d88cae973674532279b0c22 6716 docs/FOG-SECURITY-TEST-PLAN.md
+L11 94050ece3310571d3758f80eb2b1867c1bb2ae7e2fe933814732fcf3ff1b32db 13908 docs/FOG-SIMULATION.md
+L12 a7ffb9df81a23ab6763f9a3bcf9d1ba72836ac3b364fb3ee33fd70d53c2a4588 46240 docs/FOG-SPHINX-PROFILES.md
+L13 9c9017d04486a377ffd1d189a99c5cda1efe33040e9a22f28633d214d1aa6e97 67516 docs/FOG-STORAGE.md
+L14 9ec2dbb5b0d0c439aa3424e9da64fb26b4798e7fea7acaa3eb2c2290f98d6a36 43156 docs/FOG-SX.md
+L15 0595a5fe5da9fb8dbee2fac17b059f78028bc75d5ebc8863f1ac9a913c23bdde 43740 docs/FOG-THREAT-MODEL.md
+L16 370bba48b1424040bd9d74eace070b87afac1cc912f175d371f5838c2235c052 54012 docs/FOG-WIRE.md
 
 internal-nodes-postorder:
 N[0,2) 8a571e447f8f9cba4269060096b71395868b2a972a1935d03f8c3eca98d3e336
 N[2,4) f0fd551eef1f4107631e87226a77a98656c15a7c688f703b36937345fbe6e700
 N[0,4) f3bcc0d59b2815a588836a334143fa01327292cb70de56e0a3165568c270713e
-N[4,6) f939f6550e1b5171e0b1e8cb89475b6a82a17139976b4fc69b8ac1f4b7d2365a
-N[6,8) 11fd5d6e48fe3294ba015335adaa0d32ee30da80ee8dc50623d3d97108073db8
-N[4,8) 0fcc1239c92a4cf9ad0a545ccddb208ba995571377cf6bfcc1fc4b0e98b95191
-N[0,8) 33caade8ce2b90a8ef5aea5c59862dfc5a4d7567f7b5f7ddaa4d28eb52480ed3
-N[8,10) db00e1154a62aa86b01480ec5d299f1063b3c159ece49a55686860f1873d9257
-N[10,12) 50d1363126cb6fe2d5fcfc1902cd7a401cbbbc1e4fa054e6bfd31a72dcfe9ffb
-N[8,12) 8e5e56fe18531f87d7fae335f636b4eef591456e0700baeb7b35087f2ed3b1c4
-N[12,14) ae242a00d262e7eb56e40777acd68d093ac544703f019ccf0a2cee1b25c91933
-N[14,16) 2051bc8fd348330c541879147cee36984648eb77e810101872607d9fb929b7d2
-N[12,16) ef892a49dbd5ea2a3da3c3b64a590fd1b0ffe7c3f6e980178d0722357032588f
-N[8,16) d7e5c0b333d8b4d2f909465c9393e91ae9f505a4352704248ff5468d5000b02f
-N[0,16) b4caa77b1d05d979bfb02effafbdc63411d0e6bb55227822f002b39a1627fb97
-N[16,18) 36a18347a69583877658b211e3a6ad55c4d8f538b8abcbd16cfb783cf7272d14
-N[0,18) c5dbc6087b5f4a5ed77cb6811880962df1182ca9c4c7f218524d83985d3e9407
+N[4,6) 2deb2c23bdb11f5c642ba5812e82dd7b8307fd842ff6e8df768db3f22214f59b
+N[6,8) badd548f1b0da6aa06eaa5be765c8394230cbf0f3028ceffa733daa2e9fe753c
+N[4,8) dc7cb991ad74c5a4775a5f65b341877397b630e5db55a8a9a29bf567ea7c47cf
+N[0,8) d0f33db9b08b78bbc2c33caceed81d5630f11d13c6c3fde14956afb6e2572cfc
+N[8,10) a019593b281a85787356d3c7fbd899bcf29724cd843a11b5fc93c1d9714f4790
+N[10,12) c33c9dffccfba83167c8e046a6c3c313bb8ff39e9a699c05962c283ba60c1a35
+N[8,12) c3fc98cff67a8245b3158445c4438eb64e02c53774beb254503156c734e608da
+N[12,14) e1d5e0de754df89817e33947cc61d93133a011b0d8dc309edddeee15b716bbd1
+N[14,16) 1ab120c7f05d69f5cfae8fffa1fc0fa45bad369044ee2cd26dcf463c123b000a
+N[12,16) 8625ea3334beedc303647f16b06ebb36337d222c86de6e03b583205c27eb98ba
+N[8,16) bd2df2b0aef3b227ca04acad973e97fc2c41ec46331ec99437614c09aa150531
+N[0,16) 0bd10a4e115114203dc59b2f092aab86869afa3940bc71f99ec469cc3ce11024
+N[0,17) 2bbef83e797891c5937e394ef13e197522194c324ec0dc9e5ac2993ca844a4e9
 
-root: c5dbc6087b5f4a5ed77cb6811880962df1182ca9c4c7f218524d83985d3e9407
+root: 2bbef83e797891c5937e394ef13e197522194c324ec0dc9e5ac2993ca844a4e9