<div style="font-family: Arial, sans-serif; font-size: 14px;"><span></span><div><span></span></div><div>List,</div><div><br></div><div><span>This is a follow-up to the Quillon Graph thread from January.</span></div><div><span>The network launched on February 22, 2026 and has been running</span></div><div><span>continuously for 33 days. I owe this list an honest status</span></div><div><span>report, corrections to claims I made in January, and responses</span></div><div><span>to the criticisms raised -- particularly by Bear, Peter Gutmann,</span></div><div><span>John Gilmore, and Peter Fairbrother.</span></div><div><br></div><div><br></div><div><span>1. CORRECTIONS TO JANUARY CLAIMS</span></div><div><br></div><div><span>Several things I stated or implied in January were wrong or</span></div><div><span>misleading. I want to correct them before anything else.</span></div><div><br></div><div><span>(a) The mining algorithm is BLAKE3 + VDF, not SHA-3.</span></div><div><br></div><div><span>The January posts referenced SHA-3 in several places. The actual</span></div><div><span>proof-of-work implementation uses iterative BLAKE3 hashing:</span></div><div><br></div><div><span>  h = BLAKE3(header || nonce)</span></div><div><span>  for i in 0..T:  h = BLAKE3(h)</span></div><div><span>  check: h < target</span></div><div><br></div><div><span>SHA-3-256 appears in the protocol layer as an algorithm identifier,</span></div><div><span>in challenge-response hashing, and in a cfg-gated CPU fallback path</span></div><div><span>within the hybrid mining library (compiled when gpu-mining feature</span></div><div><span>is disabled). However, the primary PoW implementation that all</span></div><div><span>miners and nodes actually execute -- DagKnightVDF in q-miner and</span></div><div><span>q-api-server -- uses BLAKE3. I should have been precise about this</span></div><div><span>in January.</span></div><div><br></div><div><span>(b) The 50ms finality figure needs clarification.</span></div><div><br></div><div><span>Peter Fairbrother questioned this. There are two metrics:</span></div><div><br></div><div><span>  - User-visible confirmation: <50ms. The SSE streaming system</span></div><div><span>    pushes transaction events to connected wallets within 50ms of</span></div><div><span>    node acceptance. Users see their balance update almost</span></div><div><span>    instantly. This is the number users experience.</span></div><div><br></div><div><span>  - DAG-Knight consensus finality: 1.4 seconds. This is when the</span></div><div><span>    transaction is ordered in the DAG with sufficient probability</span></div><div><span>    of irreversibility (delta=1 confirmation depth).</span></div><div><br></div><div><span>In January I conflated these. The 50ms figure is real and</span></div><div><span>measurable -- but it is node-level acceptance and event delivery,</span></div><div><span>not consensus finality. For a merchant accepting payment, 1.4</span></div><div><span>seconds is the honest finality number. For a user watching their</span></div><div><span>wallet, sub-50ms is the honest UX number. Both are legitimate</span></div><div><span>metrics; I should have distinguished them.</span></div><div><br></div><div><span>(c) The TPS figures need context.</span></div><div><br></div><div><span>The January thread referenced 48,000 TPS. Independent benchmarking</span></div><div><span>confirms the throughput is real -- the HTTP binary batch protocol</span></div><div><span>peaks at 12,414 TPS (1000-tx batches, P99 latency 125ms, 100%</span></div><div><span>success rate) and sustains 8,600-9,700 TPS across batch sizes from</span></div><div><span>100 to 10,000. Single-transaction PaaS API calls measure 1,273 TPS</span></div><div><span>at 73ms P99.</span></div><div><br></div><div><span>However, throughput without finality context is misleading. The</span></div><div><span>full picture across layers:</span></div><div><br></div><div><span>  Layer                          TPS         Latency</span></div><div><span>  ─────────────────────────────────────────────────────</span></div><div><span>  HTTP binary batch (peak)       12,414      125ms P99</span></div><div><span>  Optimistic finality (SSE)      —           <100ms</span></div><div><span>  AEGIS-256 affirmation          —           53-160ms</span></div><div><span>  DAG-Knight 1-conf finality     —           ~1.4s avg</span></div><div><span>  Deep confirmation (3-block)    —           ~4.3s avg</span></div><div><br></div><div><span>The <100ms optimistic finality is real and measurable: when a</span></div><div><span>sender signs a transaction, the receiver's wallet balance updates</span></div><div><span>within 100ms via SSE push, backed by an AEGIS-256 authenticated</span></div><div><span>affirmation certificate. This is not a UI trick -- the balance</span></div><div><span>update is cryptographically attested -- but it precedes full DAG</span></div><div><span>consensus ordering by ~1.3 seconds.</span></div><div><br></div><div> I should have presented all layers in January rather than citing only the</div><div><span>peak throughput. </span></div><span></span><div><span><br></span></div><div><span>(d) The codebase size requires clarification.</span></div><div><br></div><div><span>I cited 680,000+ lines in January, measured across an 83-crate</span></div><div><span>workspace. The current figure for non-test, non-backup Rust</span></div><div><span>application code is approximately 767,000 lines (555,000</span></div><div><span>excluding blanks and comments). Including the TypeScript</span></div><div><span>frontend and test suites, the full project is approximately</span></div><div><span>944,000 lines. The January number was roughly accurate for</span></div><div><span>its time; the codebase has grown since then.</span></div><div><br></div><span></span><div></div><span></span><div><span></span></div><div><br></div><div><span>(e) SQIsign: real isogeny arithmetic now available via FFI.</span></div><div><br></div><div><span>Since the January thread, we completed the FFI integration path</span></div><div><span>recommended in our own technical review. The official NIST Round 2</span></div><div><span>SQIsign C reference implementation (SQISign/the-sqisign, Apache-2.0)</span></div><div><span>is now vendored in the codebase and callable from Rust via two new</span></div><div><span>crates:</span></div><div><br></div><div><span>  q-sqisign-sys  Raw FFI bindings to the C reference (75,545 lines</span></div><div><span>                 of production C, 203 files). Compiles via CMake,</span></div><div><span>                 links GMP. Exposes keygen, sign, verify, open.</span></div><div><br></div><div><span>  q-sqisign      Safe Rust wrapper with KeyPair::generate(), sign(),</span></div><div><span>                 verify(). Secret keys zeroized on drop. 11 tests</span></div><div><span>                 including roundtrip, tampering, wrong-key rejection.</span></div><div><br></div><div><span>  What is now real (Level I, via C FFI):</span></div><div><span>  - Key generation produces actual isogeny-derived keypairs</span></div><div><span>    (pk=65 bytes j-invariant, sk=353 bytes isogeny coefficients)</span></div><div><span>  - sign() computes the real dimension-4 isogeny push-through</span></div><div><span>    via KLPT + Deuring correspondence (~30ms on modern Intel)</span></div><div><span>  - verify() checks that the isogeny diagram commutes (~1.5ms)</span></div><div><span>  - All Fp2 arithmetic, Velu formulas, quaternion algebra, and</span></div><div><span>    KLPT lattice reduction are implemented in the vendored C</span></div><div><span>  - NIST KAT vectors included (900 test cases per security level)</span></div><div><span>  - Detached signature size: 148 bytes (smaller than the 204-byte</span></div><div><span>    scaffold estimate)</span></div><div><br></div><div><span>  What still uses the hash-based scaffold:</span></div><div><span>  - Levels III and V (only Level I C reference is vendored)</span></div><div><span>  - Builds without the sqisign-ffi feature flag (fallback path)</span></div><div><br></div><div><span>The integration is feature-gated: cargo build --features sqisign-ffi</span></div><div><span>enables the real C implementation for Level I. Without the flag, the</span></div><div><span>hash-based scaffold remains as a structural fallback. The height-gated</span></div><div><span>activation point (PHASE2_SQISIGN_MANDATORY, block 2,000,000) has</span></div><div><span>already been passed -- the chain is currently above 11 million blocks.</span></div><div><br></div><div><span>Mainnet blocks are signed with SQIsign (Phase 2) by default.</span></div><div><span>The chain transitioned through Ed25519 (Phase 0) → Dilithium5</span></div><div><span>(Phase 1, now deprecated) → SQIsign (Phase 2, 204-byte compact</span></div><div><span>signatures, 95.6% smaller than Dilithium5's 4,627 bytes).</span></div><div><br></div><div><br></div><div><span>2. ADDRESSING THE CRITICISMS</span></div><div><br></div><div><span>Bear's premature standardization argument (Jan 12):</span></div><div><br></div><div><span>"Any standard for quantum-resistant cryptography is a ludicrously</span></div><div><span>premature standard made without any input from real-world systems</span></div><div><span>or threats."</span></div><div><br></div><div><span>Bear, you were right about the prescription problem. In January I</span></div><div><span>argued that hybrid classical+PQ was the answer. Having now run the</span></div><div><span>system on mainnet for a month, I can report what hybrid actually</span></div><div><span>costs in practice:</span></div><div><br></div><div><span>  - Dilithium5 signatures are 4,627 bytes vs Ed25519's 64 bytes.</span></div><div><span>    On a DAG with thousands of blocks per minute, this is</span></div><div><span>    significant storage overhead.</span></div><div><span>  - Kyber1024 KEM adds ~3,200 bytes to each P2P handshake.</span></div><div><span>    With 80+ connected peers, this is measurable.</span></div><div><span>  - The real cost is not space -- it is attention. Engineering</span></div><div><span>    time spent on PQ integration is time not spent on consensus</span></div><div><span>    correctness, storage reliability, and operational safety.</span></div><div><br></div><div><span>In our first month of mainnet, we had:</span></div><div><span>  - A height regression bug that lost 3,000 blocks on restart</span></div><div><span>  - A RocksDB memory leak that OOM-killed the bootstrap node</span></div><div><span>  - A gossipsub flood that crashed the 10Gbit supernode 6x/hour</span></div><div><span>  - An ephemeral port collision that caused bind() failures</span></div><div><br></div><div><span>None of these were cryptographic failures. All of them were</span></div><div><span>engineering failures that threatened the network more immediately</span></div><div><span>than any quantum computer. This is exactly Gutmann's Scenario D</span></div><div><span>point: "while the world is fixated on dealing with a threat that</span></div><div><span>no-one has been able to prove exists, we're not addressing actual</span></div><div><span>vulnerabilities."</span></div><div><br></div><div><span>I still believe hybrid is correct for an immutable ledger. But</span></div><div><span>Bear's point about premature standards diverting engineering</span></div><div><span>resources from real threats is empirically validated by our first</span></div><div><span>month of operation.</span></div><div><br></div><div><span>Your suggestion to maintain "a few hundred different attempted</span></div><div><span>solutions" before standardizing has merit. The crypto-agility</span></div><div><span>architecture (height-gated validation rules, algorithm field in</span></div><div><span>block headers) was designed for exactly this: the PQ layer can be</span></div><div><span>replaced without a chain reset if lattice assumptions fall or</span></div><div><span>better constructions emerge.</span></div><div><br></div><div><br></div><div><span>Peter Gutmann's Scenario D -- Desinformatsiya (Jan 11):</span></div><div><br></div><div><span>"While the world is fixated on dealing with a threat that no-one</span></div><div><span>has been able to prove exists, we're not addressing actual</span></div><div><span>vulnerabilities."</span></div><div><br></div><div><span>Peter, this hit hard. Our operational experience confirms it.</span></div><div><br></div><div><span>The three most dangerous bugs we encountered in mainnet's first</span></div><div><span>month were:</span></div><div><br></div><div><span>  1. Sync-down: a peer announcing a lower height could cause the</span></div><div><span>     node to delete blocks down to the peer's height, destroying</span></div><div><span>     the chain. This is a trivial implementation bug with</span></div><div><span>     catastrophic consequences -- orders of magnitude more</span></div><div><span>     dangerous than any quantum attack.</span></div><div><br></div><div><span>  2. Unbounded block-pack allocation: syncing peers requesting</span></div><div><span>     500+ blocks spawned unbounded tokio tasks, each allocating</span></div><div><span>     50-150MB. Four concurrent sync requests = 10GB allocation =</span></div><div><span>     OOM. We gated this with a semaphore (max 4 concurrent, max</span></div><div><span>     200 blocks per response, ~200MB worst case).</span></div><div><br></div><div><span>  3. RocksDB auto-configuring block cache to 1/3 of RAM (16GB on</span></div><div><span>     our main node), leaving insufficient memory for the</span></div><div><span>     application. Fixed by explicit cap: ROCKSDB_BLOCK_CACHE_MB=4096.</span></div><div><br></div><div><span>These are pedestrian engineering problems. They are also the ones</span></div><div><span>that actually threatened user funds. Your "bollocks" framing has</span></div><div><span>a real engineering corollary: the threat model that dominates in</span></div><div><span>practice is implementation bugs, not algorithmic breaks.</span></div><div><br></div><div><span>That said, I maintain the immutable ledger asymmetry argument.</span></div><div><span>These engineering bugs are fixable (and were fixed, within hours).</span></div><div><span>A classical cryptographic break of the signature scheme, if it</span></div><div><span>occurs after keys are exposed on-chain, is not fixable -- those</span></div><div><span>funds are permanently stealable. The distinction between</span></div><div><span>"recoverable engineering failure" and "irrecoverable</span></div><div><span>cryptographic failure" still favors defense-in-depth.</span></div><div><br></div><div><br></div><div><span>John Gilmore's trust deficit (Jan 10):</span></div><div><br></div><div><span>"Why is NSA pushing belt-without-suspenders quantum-resistant</span></div><div><span>crypto? [...] You could bet that they've changed their spots,</span></div><div><span>but it's a sucker bet."</span></div><div><br></div><div><span>John, I cannot distinguish your Scenarios A/B/C from the outside.</span></div><div><span>The implementation responds as follows:</span></div><div><br></div><div><span>  - No NIST-blessed RNG. We use getrandom (OS entropy) and</span></div><div><span>    optionally hardware TRNG, not NIST SP 800-90A.</span></div><div><span>  - Parameter transparency. Dilithium5 and Kyber1024 use the</span></div><div><span>    published NIST parameters, but the protocol is designed for</span></div><div><span>    algorithm replacement. If someone produces a convincing</span></div><div><span>    cryptanalytic result against ML-DSA/ML-KEM, we can activate</span></div><div><span>    a replacement at a future block height without chain reset.</span></div><div><span>  - Belt AND suspenders. Ed25519 remains as the Phase 0 layer.</span></div><div><span>    Dilithium5 is Phase 1. Both signatures must verify for blocks</span></div><div><span>    in the hybrid phase. Breaking one is insufficient.</span></div><div><br></div><div><span>Whether NSA has broken lattice assumptions is unknowable. Whether</span></div><div><span>hybrid classical+lattice is strictly harder to break than either</span></div><div><span>alone is a theorem, not a bet.</span></div><div><br></div><div><br></div><div><span>Peter Fairbrother's privacy question (Jan 7):</span></div><div><br></div><div><span>"DAG-based BFTs like Bullshark or Mysticeti produce a consensus</span></div><div><span>blockchain quickly, but the blockchain isn't particularly private."</span></div><div><br></div><div><span>This was the most technically important critique. The privacy does</span></div><div><span>not come from the DAG consensus layer -- it comes from the</span></div><div><span>transaction layer above it:</span></div><div><br></div><div><span>  - LSAG ring signatures [1] over Ristretto points hide the</span></div><div><span>    sender within a ring of decoy inputs. Key images prevent</span></div><div><span>    double-spends without de-anonymization.</span></div><div><span>  - Stealth addresses ensure each payment goes to a unique</span></div><div><span>    one-time address, preventing address clustering.</span></div><div><span>  - Bulletproofs++ [2] range proofs hide transaction amounts.</span></div><div><span>  - Dandelion++ [3] with embedded Tor (4 circuits per validator,</span></div><div><span>    independently rotated) prevents IP-to-transaction correlation.</span></div><div><br></div><div><span>The DAG-BFT layer orders opaque transactions. Validators verify</span></div><div><span>validity proofs without learning transaction contents.</span></div><div><br></div><div><span>Since v3.4.16-beta, privacy proofs are mandatory -- not opt-in.</span></div><div><span>Every transaction submitted through the node automatically receives</span></div><div><span>maximum privacy (Bulletproofs + STARK + LatticeGuard) before</span></div><div><span>broadcast. Users do not choose a privacy level; the highest</span></div><div><span>available level is applied by default. If proof generation fails</span></div><div><span>for any reason, the transaction still proceeds but with reduced</span></div><div><span>privacy -- this is logged as a warning.</span></div><div><br></div><div><span>The anonymity set is therefore the entire transaction set, not a</span></div><div><span>subset of privacy-conscious users. This addresses the fundamental</span></div><div><span>weakness of opt-in privacy systems (Zcash's shielded pool problem)</span></div><div><span>where the anonymity set is limited to the small fraction of users</span></div><div><span>who choose to use privacy features.</span></div><div><br></div><div><br></div><div><span>3. WHAT ACTUALLY HAPPENED ON MAINNET</span></div><div><br></div><div><span>The network launched February 22, 2026 at 12:00 UTC. Empirical</span></div><div><span>observations from 31 days of operation:</span></div><div><br></div><div><span>  Aggregate hashrate:     ~7 GH/s (BLAKE3+VDF, CPU-only miners)</span></div><div><span>  Block production:       Continuous since genesis, no halts</span></div><div><span>  Bootstrap nodes:        4 (geographically distributed)</span></div><div><span>  Connected miners:       316+ (322 at last measurement)</span></div><div><span>  Chain height:           ~11.4M blocks</span></div><div><span>  Finality:               ~1.4s (1-confirmation)</span></div><div><span>  Reorgs:                 0 (DAG structure absorbs concurrent blocks)</span></div><div><span>  Consensus failures:     0</span></div><div><span>  Unplanned outages:      3 (all engineering bugs, all recovered)</span></div><div><br></div><div><span>The 7 GH/s figure is notable only because it represents organic</span></div><div><span>adoption from 316+ CPU miners without exchange listings, mining</span></div><div><span>pools, or marketing. For context, established CPU-mineable</span></div><div><span>currencies took years to reach comparable hashrates (Monero</span></div><div><span>launched April 2014, reached ~7 GH/s around 2019-2020 with</span></div><div><span>RandomX).</span></div><div><br></div><div><span>The comparison is imperfect -- 2026 has mature mining</span></div><div><span>infrastructure that 2014 did not. But the speed of adoption</span></div><div><span>suggests the BLAKE3+VDF algorithm and economic parameters</span></div><div><span>(2,625,000 QUG/year, 21M max supply, 4-year halving) are</span></div><div><span>attractive to existing CPU miners.</span></div><div><br></div><div><br></div><div><span>4. BLAKE3+VDF MINING DETAILS</span></div><div><br></div><div><span>Since this was mis-stated in January, the precise algorithm:</span></div><div><br></div><div><span>  Input = prev_block_hash || miner_pubkey || nonce || timestamp</span></div><div><span>  h = BLAKE3(Input)</span></div><div><span>  for i in 0..T:</span></div><div><span>      h = BLAKE3(h)          // Sequential -- cannot parallelize</span></div><div><span>  valid = (h < difficulty_target)</span></div><div><br></div><div><span>BLAKE3 was chosen over SHA-3 for:</span></div><div><span>  - 3-5x faster on x86-64 with AVX2/AVX-512 SIMD</span></div><div><span>  - Excellent ARM NEON performance (future target)</span></div><div><span>  - Cache-friendly: the iterated VDF loop fits in L1</span></div><div><br></div><div><span>The VDF loop (T sequential iterations) provides ASIC resistance.</span></div><div><span>Custom hardware can optimize the BLAKE3 compression function by</span></div><div><span>perhaps 2-3x over a modern CPU, but cannot skip iterations. This</span></div><div><span>bounds the ASIC advantage to a small constant factor, unlike</span></div><div><span>SHA-256d where ASICs achieve >10,000x over CPUs.</span></div><div><br></div><div><span>GPU mining is supported (OpenCL kernel for BLAKE3), but the</span></div><div><span>sequential VDF loop limits effective GPU parallelism. Each GPU</span></div><div><span>thread runs an independent VDF chain -- more threads help, but</span></div><div><span>cannot accelerate any single chain.</span></div><div><br></div><div><br></div><div><span>5. ARCHITECTURAL OVERVIEW</span></div><div><br></div><div><span>The system is a Rust workspace of ~80 crates. The consensus-critical</span></div><div><span>components (listing only the relevant subset):</span></div><div><br></div><div><span>  q-dag-knight      DAG-BFT ordering (Sompolinsky et al. [4])</span></div><div><span>  q-vdf             Wesolowski [5] + Pietrzak [6] VDFs</span></div><div><span>  q-types           Block/tx types, signature verification</span></div><div><span>  q-storage         RocksDB blockchain storage</span></div><div><span>  q-network         libp2p gossipsub + Kademlia DHT</span></div><div><br></div><div><span>Post-quantum and privacy:</span></div><div><br></div><div><span>  q-quantum-crypto  Dilithium5 (pqcrypto-dilithium) + Kyber1024</span></div><div><span>  q-quantum-mixing  LSAG ring sigs, stealth addrs, Bulletproofs++</span></div><div><span>  q-zk-snark        Groth16/PLONK/Marlin (arkworks [7])</span></div><div><span>  q-zk-stark        Custom AIR/FRI STARK prover</span></div><div><span>  q-dandelion       Dandelion++ relay with Tor bridge</span></div><div><span>  q-tor-client      Embedded arti Tor client</span></div><div><span>  q-tor-circuit     4 dedicated circuits per validator</span></div><div><br></div><div><span>The signature scheme progression:</span></div><div><br></div><div><span>  Phase 0:  Ed25519 only (64-byte sigs) — genesis through early chain</span></div><div><span>  Phase 1:  Dilithium5 (4,627-byte sigs) — first PQC phase, now deprecated</span></div><div><span>  Phase 2:  SQIsign (204-byte sigs) — current default, via FFI to NIST</span></div><div><span>            Round 2 C reference (real isogeny arithmetic for Level I)</span></div><div><br></div><div><span>The chain is currently in Phase 2 (above 11 million blocks). Phase</span></div><div><span>transitions are height-gated: blocks below the activation height</span></div><div><span>validate under old rules; blocks above under new rules. Old blocks</span></div><div><span>never need re-validation. This is how we maintain crypto-agility</span></div><div><span>without chain resets -- the answer to Bear's "what happens when the</span></div><div><span>standard is wrong."</span></div><div><br></div><div><br></div><div><span>6. KNOWN LIMITATIONS AND OPEN PROBLEMS</span></div><div><br></div><div><span>Honest assessment of where the system falls short:</span></div><div><br></div><div><span>  (a) The privacy layer uses curve25519-based ring signatures,</span></div><div><span>      which are quantum-vulnerable. Migrating ring signatures to</span></div><div><span>      lattice-based constructions is an open research problem.</span></div><div><span>      Current candidates (e.g., Esgin et al. [8]) produce</span></div><div><span>      signatures that are orders of magnitude larger, which may</span></div><div><span>      be impractical for a ring signature scheme. This is the</span></div><div><span>      single largest technical debt in the system.</span></div><div><br></div><div><span>  (b) No independent audit of any cryptographic implementation.</span></div><div><span>      The Dilithium5 integration uses the pqcrypto-dilithium</span></div><div><span>      library (which has had some review), but our ring signature,</span></div><div><span>      Bulletproofs++, and STARK implementations are custom and</span></div><div><span>      unaudited. This is a serious limitation.</span></div><div><br></div><div><span>  (c) The compact signature scheme (Phase 2) now wraps the</span></div><div><span>      official NIST Round 2 SQIsign C reference via FFI for</span></div><div><span>      Level I (real isogeny keygen, sign, verify). Levels III</span></div><div><span>      and V still use a hash-based scaffold. The C reference</span></div><div><span>      is vendored and compiled into the binary -- no pure-Rust</span></div><div><span>      SQIsign library exists as of March 2026. Side-channel</span></div><div><span>      hardening of the C signing path (KLPT, quaternion lattice</span></div><div><span>      reduction) remains an open problem tracked upstream.</span></div><div><br></div><div><span>  (d) VDF security parameters have not been formally analyzed.</span></div><div><span>      The RSA group size and iteration count were empirically</span></div><div><span>      tuned. A formal analysis relating these to concrete security</span></div><div><span>      levels is needed.</span></div><div><br></div><div><span>  (e) The DAG-Knight consensus has not been formally verified.</span></div><div><span>      We test extensively (4,000+ tests including adversarial</span></div><div><span>      scenarios), but testing is not proof.</span></div><div><br></div><div><span>  (f) The Tor integration has not been evaluated against a</span></div><div><span>      global passive adversary. The 4-circuit architecture</span></div><div><span>      provides defense-in-depth but has not been analyzed for</span></div><div><span>      traffic correlation resistance under realistic threat</span></div><div><span>      models.</span></div><div><br></div><div><br></div><div><span>7. WHAT WE LEARNED FROM THIS LIST</span></div><div><br></div><div><span>The January thread was the most useful technical review the</span></div><div><span>project has received. Specific changes made in response:</span></div><div><br></div><div><span>  - Clarified finality claims (50ms UX vs 1.4s consensus)</span></div><div><span>  - Separated HNDL and HNFL threat models in documentation</span></div><div><span>  - Completed SQIsign FFI integration (NIST Round 2 C reference,</span></div><div><span>    Level I real isogeny arithmetic, 148-byte signatures)</span></div><div><span>  - Prioritized engineering reliability over feature additions</span></div><div><span>    (Gutmann's Scenario D was persuasive)</span></div><div><span>  - Documented the hybrid architecture as "belt AND suspenders"</span></div><div><span>    not "belt instead of suspenders" (Gilmore's framing)</span></div><div><span>  - Added algorithm replacement infrastructure (Bear's diversity</span></div><div><span>    argument) via height-gated crypto-agility</span></div><div><br></div><div><span>The network is stronger for this discussion. I welcome continued</span></div><div><span>criticism.</span></div><div><br></div><div><br></div><div><span>REFERENCES</span></div><div><br></div><div><span>[1] J. Liu, V. Wei, D. Wong, "Linkable Spontaneous Anonymous</span></div><div><span>    Group Signature for Ad Hoc Groups," ACISP 2004, LNCS 3108.</span></div><div><br></div><div><span>[2] L. Eagen, D. Fiore, A. Gabizon, "Bulletproofs++: Next</span></div><div><span>    Generation Confidential Transactions via Reciprocal Set</span></div><div><span>    Membership Arguments," ePrint 2022/510.</span></div><div><br></div><div><span>[3] G. Fanti et al., "Dandelion++: Lightweight Cryptocurrency</span></div><div><span>    Networking with Formal Anonymity Guarantees," ACM SIGMETRICS</span></div><div><span>    2018.</span></div><div><br></div><div><span>[4] Y. Sompolinsky, S. Wyborski, A. Zohar, "DAG-Knight: An</span></div><div><span>    Asynchronous Byzantine Fault Tolerant Consensus Protocol,"</span></div><div><span>    ePrint 2022/1494.</span></div><div><br></div><div><span>[5] B. Wesolowski, "Efficient Verifiable Delay Functions,"</span></div><div><span>    EUROCRYPT 2019, LNCS 11478.</span></div><div><br></div><div><span>[6] K. Pietrzak, "Simple Verifiable Delay Functions," ITCS 2019,</span></div><div><span>    LIPIcs 124.</span></div><div><br></div><div><span>[7] arkworks contributors, "arkworks: An Ecosystem for zkSNARKs,"</span></div><div><span>    <a target="_blank" rel="noreferrer nofollow noopener" href="https://arkworks.rs">https://arkworks.rs</a></span></div><div><br></div><div><span>[8] M.F. Esgin, R. Steinfeld, D. Sakzad, J.K. Liu, D. Liu,</span></div><div><span>    "Short Lattice-based One-out-of-Many Proofs and Applications</span></div><div><span>    to Ring Signatures," ACNS 2019, LNCS 11464.</span></div><div><br></div><div><br></div><div><span>Source: <a target="_blank" rel="noreferrer nofollow noopener" href="https://quillon.xyz">https://quillon.xyz</a></span></div><div><span>Binary: <a target="_blank" rel="noreferrer nofollow noopener" href="https://quillon.xyz/downloads/q-api-server-linux-x86_64">https://quillon.xyz/downloads/q-api-server-linux-x86_64</a></span></div><div><br></div><div><span>-Viktor</span></div><span></span><span></span><br></div>