[Cryptography] Quillon Graph: A private, post-quantum electronic cash system

Thu Mar 5 02:22:29 EST 2026

Howard Chu via cryptography wrote:
  > The vast majority of ARM SOCs in the field now have AES instruction
  > support. The anemic Broadcom SOCs that Raspberry used are unique in
  > omitting them. I would ignore them, let them continue to use software
  > AES if anyone is inclined to run on them.

  Howard,

  You're right, and our deployment data confirms it. Of the 182 unique
  miners on the network, exactly 7 are running on ARM — 4 on Cortex-A76
  (Raspberry Pi 5), 2 on Apple M-series, 1 on Ampere Altra. The M-series
  and Altra both have AES instructions. The Pi 5's Cortex-A76 cores
  actually do support ARMv8 Crypto Extensions (AES, SHA-1, SHA-256),
  though Broadcom's BCM2712 implementation is not as aggressively
  pipelined as Arm's reference design — we see roughly 2.8 GB/s AES-256
  throughput versus 6+ GB/s on the Ampere. Still hardware-accelerated,
  just slower.

  The older Pi 4 (Cortex-A72) also has the crypto extensions. You'd have
  to go back to the Pi 3 (Cortex-A53, which does support them) or the
  Pi Zero/Zero 2W to find Broadcom parts where it becomes genuinely
  painful. Nobody is mining a DAG-BFT chain on a Pi Zero, and if they
  are, AEGIS-256 performance is the least of their problems.

  So the practical answer is: we already fall back to software AES on
  detection of missing AES-NI/ARMv8-CE, and the performance hit on
  hardware that actually lacks it is irrelevant because that hardware
  can't keep up with block validation anyway. We'll keep the fallback
  path for correctness but won't optimize for it.

  Ascon remains interesting as a long-term option — its performance on
  platforms without AES hardware is genuinely good (~3 cpb on scalar
  ARM vs ~25 cpb for software AES-256-GCM), and NIST's lightweight
  cryptography standardization gives it institutional credibility. But
  as you note, the installed base that would benefit is vanishingly
  small. We'll revisit if we ever target embedded IoT validators, which
  is not on the near-term roadmap.

  Thank you for the characteristically direct engineering advice. The
  OpenLDAP project's approach to portability — support what matters,
  document what doesn't, don't contort the architecture for edge cases
  — is one we try to follow.

  — Viktor

  ---
  Reply to Bear:

  Bear via cryptography wrote:

  > My condolences. Try to remain optimistic through the hardships you
  > must endure, value your relationships with family and those close
  > to you, and have courage. No matter how hard it may seem at times,
  > try to believe that you can still pull through this crisis and find
  > happiness.

  Bear,

  I laughed, and then I checked our incident log from the past ten days
  and stopped laughing.

  You are, of course, entirely correct. Launching a production consensus
  system is a form of structured suffering that no amount of testnet
  rehearsal prepares you for. The gap between "all tests pass" and
  "real miners with real money on real hardware behind real ISPs with
  real opinions" is approximately the same gap between reading about
  parenthood and having a newborn.

  Since you've clearly been through this, a candid accounting of what
  the first ten days actually cost:

    - 28 critical bugs discovered across 24 network phase transitions.
    - A three-order-of-magnitude emission constant error (three extra
      zeros in a u128 integer — the kind of bug that makes you question
      whether you should be allowed near monetary systems).
    - A deterministic balance migration that had to replay 7.4 million
      blocks from genesis to correct the accumulated state divergence.
      We published the formal methodology: "First-Principles Chain
      Replay with Proportional Normalization" [1] — because when your
      emission controller has been overproducing by 34x for a week,
      you need a mathematically rigorous proof that the correction
      doesn't create or destroy value. The core equation turned out
      to be satisfyingly simple:

        b_corrected = b_raw * C*(t) / T_chain

      One multiplicative operator. Preserves proportional invariance.
      Idempotent. Deterministic across nodes. 235 lines of Rust.
      Executes in under 3 seconds over 7.4M blocks.

    - A TCP self-connection bug where Linux's ephemeral port range
      (unwisely tuned to 1024-65535) caused the kernel to pick port
      8080 as both source and destination when our reverse proxy
      connected to localhost — creating a socket in TIME_WAIT that
      prevented the server from binding. The kind of bug that makes
      you mass `sysctl.conf` for the first time in years.

    - An OOM cascade on our third bootstrap node caused by four
      uninvited cryptocurrency daemons (Zcash, Bitcoin, two Iron Fish
      instances) consuming 7.2 GB on an 8 GB server. The Linux OOM
      killer, with its characteristic lack of sentiment, terminated
      our consensus node and left the Zcash node running.

    - 75,000 stale TCP connections between nginx and our application
      server, caused by HTTP/1.1 keepalive with no idle timeout.
      Load average 52 on 48 cores. 20 GB RSS. Fix: one line of nginx
      config (`proxy_set_header Connection "close"`).

    - Our hosting provider silently downgraded our primary bootstrap
      node from 1 Gbit to 100 Mbit four days before genesis. No
      notification. The Kalman-filtered bandwidth estimator in our
      sync engine [2] detected and adapted within 30 seconds. The
      humans took considerably longer to adapt emotionally.

  The family relationships remain intact, though my circadian rhythm
  filed for divorce somewhere around rehearsal 3. The optimism persists
  primarily because the system — despite its maintainers' best efforts
  to break it — has produced 7.4 million Dilithium5-signed blocks
  without a single signature verification failure or VDF equivocation.

  The chain replays its own history deterministically. The balance
  state on every node converges to the same values from the same blocks
  without coordination. The P2P protocol rejects incompatible peers
  before data exchange. The gossipsub deduplication has five layers
  (in-memory VecDeque, LRU cache, RocksDB watermark, genesis timestamp
  filter, fork detection) because, as we learned, if you can be
  wrong about something exactly once, you will be wrong about it
  exactly once [3].

  Your condolences are accepted in the spirit offered. If you have
  specific technical concerns about the architecture, I'd welcome them
  — this list's skepticism has historically been more useful than its
  encouragement, and I say that as a compliment.

  — Viktor

  [1] "Deterministic Balance Migration via First-Principles Chain
      Replay," Q-NarwhalKnight Protocol Team, v8.8.6, March 2026.
      https://quillon.xyz/downloads/deterministic-balance-migration-v886.pdf

  [2] "Project APOLLO: Adaptive Pipeline-Parallel Optimized Locking
      & Orchestration for Blockchain Synchronization," v2.1.0,
      February 2026.
      https://quillon.xyz/downloads/apollo-sync-optimization-whitepaper.pdf

  [3] "P2P Balance Propagation Design Document," Q-NarwhalKnight
      Protocol Team, v1.0, March 2026. Internal design doc describing
      the five-layer deduplication architecture and balance divergence
      vectors.

Really important if something matters

Afsendt med Proton Mail sikker e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260305/73152d50/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - overdrevetfedmetodologi at pm.me - 0x5F4716BA.asc
Type: application/pgp-keys
Size: 1722 bytes
Desc: not available
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260305/73152d50/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260305/73152d50/attachment.sig>