<div style="font-family: Arial, sans-serif; font-size: 14px;"><div><span><span>Fellow cypherpunks,</span></span><div><br></div><div><span>A brief update to this thread. The system I described in December</span></div><div><span>and January is no longer theoretical. Q-NarwhalKnight mainnet</span></div><div><span>launched on February 22, 2026 at 12:00 UTC. As of this writing:</span></div><div><br></div><div><span> - 3,673,000+ blocks produced</span></div><div><span> - 73 connected peers via libp2p gossipsub</span></div><div><span> - 182 unique miners</span></div><div><span> - ~1 GH/s aggregate network hashrate</span></div><div><span> - Every block signed with Dilithium5 since genesis</span></div><div><br></div><div><span>The Dilithium5/Kyber1024/SHA3-256/BLAKE3 stack described in my</span></div><div><span>earlier post has been running in continuous production for four</span></div><div><span>days. No signature verification failures. No key exchange</span></div><div><span>renegotiation bugs. No hash collisions (one would hope). The</span></div><div><span>genus-2 VDF anchor election has survived 3.6 million rounds</span></div><div><span>without a single equivocation event.</span></div><div><br></div><div><span>I promised this list I'd report back with field data rather than</span></div><div><span>benchmarks. Here it is — along with some candid observations</span></div><div><span>about what actually goes wrong when you ship a post-quantum</span></div><div><span>consensus system to production.</span></div><div><br></div><div><br></div><div><span>FIELD DATA: WHAT 3.6 MILLION BLOCKS TAUGHT US</span></div><div><br></div><div><span>1. Post-quantum signatures in the wild</span></div><div><br></div><div><span>Dilithium5's 4,595-byte signatures are not a theoretical burden —</span></div><div><span>they're a practical one. At ~1 block/second with 73 peers, the</span></div><div><span>gossipsub layer is moving roughly 335 KB/s of signature data</span></div><div><span>alone. On a 1 Gbit link, this is rounding error. On a 100 Mbit</span></div><div><span>link (more on that shortly), it becomes 2.7% of total capacity</span></div><div><span>just for signatures.</span></div><div><br></div><div><span>For comparison, Ed25519 at 64 bytes would consume ~4.7 KB/s.</span></div><div><span>The 72x overhead is real but manageable — Dilithium5 signatures</span></div><div><span>compress well under LZ4 (typically 38-42% reduction), and our</span></div><div><span>gossipsub batching amortizes the per-message overhead across</span></div><div><span>8-16 blocks per transmission.</span></div><div><br></div><div><span>Verification performance: ~2,400 Dilithium5 verifications/second</span></div><div><span>on a single core (AMD EPYC). Not a bottleneck at 1 bps, but it</span></div><div><span>will matter at 100 bps if we ever get there. We've pre-allocated</span></div><div><span>a dedicated verification thread pool for this reason.</span></div><div><br></div><div><span>2. VDF timing under adversarial network conditions</span></div><div><br></div><div><span>The genus-2 VDF proved more robust than expected to network jitter.</span></div><div><span>Our Kalman-filtered latency estimator (Project APOLLO — see [1])</span></div><div><span>predicts VDF evaluation windows with sufficient margin that even</span></div><div><span>200ms network spikes don't cause missed slots. We observed exactly</span></div><div><span>zero VDF timing failures across 3.6M blocks.</span></div><div><br></div><div><span>However, we did observe an interesting effect: when the network</span></div><div><span>hashrate spiked from 200 MH/s to 1 GH/s over 48 hours, the</span></div><div><span>adaptive difficulty adjustment oscillated for approximately 1,200</span></div><div><span>blocks (~20 minutes) before stabilizing. The PID rate controller</span></div><div><span>damped the oscillation, but the initial Kp gain was too aggressive</span></div><div><span>for a 5x hashrate jump. We've since added anti-windup clamping.</span></div><div><br></div><div><span>3. SHA3-256 vs BLAKE3: the dual-hash tradeoff</span></div><div><br></div><div><span>We use SHA3-256 for consensus-critical hashes (block hashing,</span></div><div><span>Merkle roots, address derivation) and BLAKE3 for mining</span></div><div><span>proof-of-work. This was initially a purity-vs-performance</span></div><div><span>compromise, but in production it's proven to be a useful</span></div><div><span>separation of concerns: SHA3-256's sponge construction gives</span></div><div><span>us domain separation for free (different capacity/rate ratios</span></div><div><span>per use case), while BLAKE3's SIMD acceleration lets miners</span></div><div><span>extract 35-85% more hash throughput on modern CPUs.</span></div><div><br></div><div><span>The miners are pushing BLAKE3 hard enough that we've added</span></div><div><span>NUMA-aware thread pinning and zero-allocation hot loops. One</span></div><div><span>contributor built an "extreme" binary with AVX-512 intrinsics</span></div><div><span>that achieves approximately 2.1x throughput over the portable</span></div><div><span>build — then discovered the hard way that deploying an AVX-512</span></div><div><span>binary to an AVX2-only machine produces a SIGILL, not a friendly</span></div><div><span>error message. (Compiler flags: the original "works on my</span></div><div><span>machine" problem.)</span></div><div><br></div><div><br></div><div><span>THE ENGINEERING COMEDY OF ERRORS</span></div><div><br></div><div><span>In the spirit of full transparency — and because this list has</span></div><div><span>always valued honest post-mortems over press releases — here is</span></div><div><span>a partial accounting of what went wrong between "testnet works"</span></div><div><span>and "mainnet works":</span></div><div><br></div><div><span>28 critical bugs discovered across 24 network phase transitions.</span></div><div><br></div><div><span>The greatest hits:</span></div><div><br></div><div><span>(a) THE FOUR-BUG CASCADE (Phase 8)</span></div><div><br></div><div><span>Four bugs, each hidden behind the previous fix. The environment</span></div><div><span>variable parser couldn't read the new network ID. But fixing that</span></div><div><span>revealed the CLI arguments took priority over env vars, nullifying</span></div><div><span>the fix. But fixing THAT revealed the NetworkConfig constructor</span></div><div><span>had a hardcoded phase. But fixing THAT revealed the block producer</span></div><div><span>embedded the wrong network ID in every block header.</span></div><div><br></div><div><span>Net effect: the node subscribed to the correct gossipsub topic,</span></div><div><span>then published to a different one. Complete silence. No error.</span></div><div><span>No warning. Just a node that looked healthy in every metric</span></div><div><span>except the one that mattered: it was talking to itself.</span></div><div><br></div><div><span>(If Dolev and Yao had written a Byzantine fault scenario about</span></div><div><span>misconfigured gossipsub topics, it would read exactly like our</span></div><div><span>production logs.)</span></div><div><br></div><div><span>(b) THE COMPRESSION ASYMMETRY (Rehearsal 1)</span></div><div><br></div><div><span>LZ4 compression on Server Beta, LZ4 decompression on Server</span></div><div><span>Gamma, configured with incompatible frame parameters. Blocks</span></div><div><span>serialized on one node couldn't deserialize on another. The</span></div><div><span>sync pipeline silently dropped every block. No error. No crash.</span></div><div><span>The blocks just... ceased to exist mid-transit.</span></div><div><br></div><div><span>Claude Shannon would have appreciated the irony: a communication</span></div><div><span>channel with nonzero capacity and zero mutual information.</span></div><div><br></div><div><span>(c) THE GENESIS FORK (Rehearsal 3)</span></div><div><br></div><div><span>Staggered server starts during the mainnet rehearsal. Beta starts</span></div><div><span>at T-10 minutes. Gamma starts at T-5 minutes. In those five</span></div><div><span>minutes, Gamma can't reach Beta, so it helpfully creates its own</span></div><div><span>genesis block. Result: two independent blockchains in the first</span></div><div><span>300 seconds of a network designed to be Byzantine fault tolerant.</span></div><div><br></div><div><span>The fix is embarrassingly obvious in hindsight: stop ALL nodes</span></div><div><span>before starting ANY of them. Coordinate genesis, don't race it.</span></div><div><br></div><div><span>(Lamport would note that this is precisely the problem his</span></div><div><span>logical clocks were designed to prevent. We had physical clocks.</span></div><div><span>They weren't enough.)</span></div><div><br></div><div><span>(d) THE BANDWIDTH DEGRADATION (Launch Week)</span></div><div><br></div><div><span>Four days before mainnet genesis, our hosting provider</span></div><div><span>(Contabo — may their SLA rest in peace) degraded the primary</span></div><div><span>bootstrap node from 1 Gbit/s to 100 Mbit/s. No notification.</span></div><div><span>No explanation. No ticket. Just a 90% bandwidth reduction on</span></div><div><span>the server that every miner in the world would connect to in</span></div><div><span>96 hours.</span></div><div><br></div><div><span>TCP window tuning. Kernel Receive Packet Steering. Nginx buffer</span></div><div><span>optimization. Gossipsub message batching. We squeezed every</span></div><div><span>useful bit through that pipe.</span></div><div><br></div><div><span>The system survived. The Kalman network predictor in our sync</span></div><div><span>engine (which estimates bandwidth, latency, and optimal chunk</span></div><div><span>sizes in real time) turned out to be worth every line of its</span></div><div><span>implementation. It adapted to the constrained link within</span></div><div><span>approximately 30 seconds of the degradation.</span></div><div><br></div><div><span>(e) THE ROGUE PROCESS MASSACRE (Post-Launch)</span></div><div><br></div><div><span>Server Delta — our third bootstrap node — crashed 20 times in</span></div><div><span>one week. Root cause: four processes nobody invited. A Zcash</span></div><div><span>node (3.5 GB). A Bitcoin node (2.3 GB). Two Iron Fish instances</span></div><div><span>(1.4 GB each). Total: 7.2 GB of RAM consumed by blockchain</span></div><div><span>software that wasn't ours, on an 8 GB server, with 8 GB swap</span></div><div><span>fully exhausted. The kernel's OOM killer executed our consensus</span></div><div><span>node with SIGKILL and absolutely no remorse.</span></div><div><br></div><div><span>The fix involved `kill -9`, `systemctl mask`, and a stern</span></div><div><span>conversation with whoever provisioned that VPS.</span></div><div><br></div><div><br></div><div><span>TOKENOMICS (For the Economists on the List)</span></div><div><br></div><div><span>21,000,000 QUG maximum supply. 24 decimal places. 4-year</span></div><div><span>halving across 64 eras (256 years to full emission). Era 0</span></div><div><span>emits 2,625,000 QUG/year. Adaptive block rewards adjust to</span></div><div><span>actual block rate via a PID controller with anti-windup.</span></div><div><span>No pre-mine. No ICO. No allocation. Everyone started at</span></div><div><span>genesis block zero.</span></div><div><br></div><div><span>The emission schedule is a geometric series:</span></div><div><br></div><div><span> E(k) = E_0 / 2^k, k = 0, 1, ..., 63</span></div><div><br></div><div><span> where E_0 = 10,500,000 QUG (Era 0 total, over 4 years)</span></div><div><br></div><div><span> Sum(k=0..63) E(k) = 2*E_0 * (1 - 2^(-64)) ~ 21,000,000</span></div><div><br></div><div><span>Bitcoin's schedule, essentially, but with ~1 second blocks</span></div><div><span>instead of ~600, adaptive difficulty, and DAG-based consensus</span></div><div><span>instead of longest-chain.</span></div><div><br></div><div><br></div><div><span>HASHRATE NOTE</span></div><div><br></div><div><span>The network crossed 1 GH/s this week. For context: there are</span></div><div><span>approximately 7.5 x 10^18 grains of sand on Earth. At 1 GH/s,</span></div><div><span>the network computes one SHA3-256 + BLAKE3 VDF proof for every</span></div><div><span>7.5 billion grains of sand, every second. To hash every grain</span></div><div><span>individually would take approximately 237 years at current rate.</span></div><div><br></div><div><span>This is, of course, entirely useless information from a</span></div><div><span>cryptographic perspective. But it makes for a good pub</span></div><div><span>conversation, and I suspect some of you frequent pubs.</span></div><div><br></div><div><br></div><div><span>WHAT'S NEXT</span></div><div><br></div><div><span>- Exchange listings: Community-funded campaigns for BitMart,</span></div><div><span> LBank, and MEXC are active. ($12,252 raised so far — crypto</span></div><div><span> is apparently easier to build than to list.)</span></div><div><span>- Cross-chain bridge: HTLC atomic swaps with 7-of-11 multi-sig</span></div><div><span> committee for wBTC, wETH, wZEC, wIRON. Whitepaper published [2].</span></div><div><span>- QUG-V1: A 16-core heterogeneous RISC-V cluster chip (TSMC 5nm)</span></div><div><span> optimized for BLAKE3 + VDF mining. The whitepaper [3] describes</span></div><div><span> the architecture. Whether we'll actually tape out is a question</span></div><div><span> of funding, physics, and how many more 3 AM debugging sessions</span></div><div><span> my circadian rhythm can absorb.</span></div><div><br></div><div><span>The full technical whitepaper (v2.0, Mainnet Edition) is at [4].</span></div><div><span>33 research papers published to date, covering everything from</span></div><div><span>consensus security analysis to K-parameter trust frameworks to</span></div><div><span>a RISC-V chip that may or may not exist someday.</span></div><div><br></div><div><br></div><div><span>OPEN QUESTIONS FOR THIS LIST</span></div><div><br></div><div><span>1. Our genus-2 VDF has survived 3.6M evaluations without issue,</span></div><div><span> but the security reduction assumes hardness of the discrete</span></div><div><span> log problem on genus-2 Jacobians. Has anyone on this list</span></div><div><span> seen recent work on index calculus improvements for genus-2</span></div><div><span> beyond Gaudry's 2009 bounds? We're currently parameterized</span></div><div><span> for ~128-bit classical / ~85-bit quantum security, and I'd</span></div><div><span> like to sanity-check that margin.</span></div><div><br></div><div><span>2. The hybrid signature scheme (Ed25519 AND Dilithium5, both</span></div><div><span> must verify) adds approximately 4.7 KB per block header. At</span></div><div><span> scale (>100 bps), this becomes non-trivial for light clients.</span></div><div><span> Has anyone explored efficient hybrid signature aggregation</span></div><div><span> schemes that preserve the "either-or" security guarantee while</span></div><div><span> reducing wire format? BLS aggregation doesn't extend cleanly</span></div><div><span> to lattices.</span></div><div><br></div><div><span>3. Our AEGIS-256 block encryption relies on AES-NI hardware</span></div><div><span> support. On ARM (Raspberry Pi miners — yes, we have those),</span></div><div><span> we fall back to software AES, which is roughly 8x slower.</span></div><div><span> Is there a compelling post-quantum AEAD construction that</span></div><div><span> performs well on both x86 (with AES-NI) and ARM (without)?</span></div><div><span> Ascon is interesting but we haven't benchmarked it in our</span></div><div><span> pipeline yet.</span></div><div><br></div><div><span>I continue to find this list's signal-to-noise ratio refreshing</span></div><div><span>in a field where most "announcements" are tokenomics decks with</span></div><div><span>gradient backgrounds. Thank you for the rigorous feedback on</span></div><div><span>the K-parameter framework — the Monte Carlo validation has</span></div><div><span>held up well under the parameter perturbations several of you</span></div><div><span>suggested.</span></div><div><br></div><div><span>The source is at <a target="_blank" rel="noreferrer nofollow noopener" href="https://quillon.xyz">https://quillon.xyz</a>. The node binary is a</span></div><div><span>single wget away:</span></div><div><br></div><div><span> wget <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>The chain verifies itself. Don't trust — hash.</span></div><div><br></div><div><br></div><div><span>— Viktor S. Kristensen (DK)</span></div><div><span> Q-NarwhalKnight / Quillon</span></div><div><span> <a target="_blank" rel="noreferrer nofollow noopener" href="https://quillon.xyz">https://quillon.xyz</a></span></div><div><br></div><div><br></div><div><span>References:</span></div><div><br></div><div><span>[1] "Project APOLLO: Adaptive Pipeline-Parallel Optimized Locking</span></div><div><span> & Orchestration for Blockchain Synchronization," v2.1.0,</span></div><div><span> February 2026.</span></div><div><span> <a target="_blank" rel="noreferrer nofollow noopener" href="https://quillon.xyz/downloads/apollo-sync-optimization-whitepaper.pdf">https://quillon.xyz/downloads/apollo-sync-optimization-whitepaper.pdf</a></span></div><div><br></div><div><span>[2] "Cross-Chain Bridge Protocol: Trustless Atomic Swaps with</span></div><div><span> Multi-Sig Committee Validation," v2.0, February 2026.</span></div><div><span> <a target="_blank" rel="noreferrer nofollow noopener" href="https://quillon.xyz/downloads/cross-chain-bridge-whitepaper.pdf">https://quillon.xyz/downloads/cross-chain-bridge-whitepaper.pdf</a></span></div><div><br></div><div><span>[3] "The QUG-V1: A Pocket Supercomputer for Decentralized Mining</span></div><div><span> and Node Operation," v1.0.0, February 2026.</span></div><div><span> <a target="_blank" rel="noreferrer nofollow noopener" href="https://quillon.xyz/downloads/qug-v1-pocket-supercomputer.pdf">https://quillon.xyz/downloads/qug-v1-pocket-supercomputer.pdf</a></span></div><div><br></div><div><span>[4] "Q-NarwhalKnight: A Quantum-Resistant Peer-to-Peer Network</span></div><div><span> Architecture," Technical Whitepaper v2.0, Mainnet Edition.</span></div><div><span> <a target="_blank" rel="noreferrer nofollow noopener" href="https://quillon.xyz/downloads/quillon-libp2p-network-whitepaper.pdf">https://quillon.xyz/downloads/quillon-libp2p-network-whitepaper.pdf</a></span></div><div><br></div><div><span>[5] NIST FIPS 204 - ML-DSA (Dilithium) Digital Signature Standard</span></div><div><span>[6] NIST FIPS 203 - ML-KEM (Kyber) Key Encapsulation Mechanism</span></div><div><span>[7] Gaudry, "Index calculus for abelian varieties of small</span></div><div><span> dimension and the elliptic curve discrete logarithm problem,"</span></div><span> J. Symb. Comp., 2009.</span></div><div></div><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div>
<div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block">
<div class="protonmail_signature_block-user">
<div>Really important if something matters<br></div>
</div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div>
<div class="protonmail_signature_block-proton">
Afsendt med <a href="https://proton.me/mail/home" target="_blank">Proton Mail</a> sikker e-mail.
</div>
</div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><div class="protonmail_quote"><div class="protonmail_quote"><br></div><blockquote class="protonmail_quote" type="cite"><div class="protonmail_quote">
</div>
</blockquote><br>
</div></div>