Bitcoin Forum
August 09, 2026, 02:55:11 AM *
News: COLDCARD users only: critical vulnerability risks funds stored on COLDCARD devices; immediate action required
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [POST-MORTEM] Lattica — a post-quantum chain with zero elliptic-curve code  (Read 31 times)
kpilatovich (OP)
Newbie
*
Offline

Activity: 1
Merit: 0


View Profile
August 08, 2026, 11:27:04 AM
 #1

Discontinued. Mainnet ran three weeks. This is what it cost, and why I now think
the premise was wrong — the numbers are all here, because a project that ends
quietly teaches nobody anything, and because the thing I got wrong is more
useful than the thing I got right.

Source, restored: https://github.com/kpilatovich/lattica

---

## What it was

A peer-to-peer currency on the Bitcoin Core architecture — UTXO ledger, Script,
full-node validation, HD wallet — with the cryptography **replaced rather than
supplemented**:

| | |
| --- | --- |
| Signatures | ML-DSA-44 (FIPS 204), lattice-based, from the genesis block |
| Network encryption | ML-KEM-768 (FIPS 203) key agreement, on by default |
| Hashing and proof of work | SHA3-256 and SHA3-256d (FIPS 202) |
| Elliptic-curve code | **none — zero files in the repository** |

The whole claim was in that last row, and it was designed to be checked rather
than believed:

```
git ls-files | grep -c secp256k1        # → 0
```

The reasoning was the harvest-now-decrypt-later one. When a coin is spent its
public key is published permanently and can never be withdrawn, so an adversary
does not need a quantum computer now — only a copy of the chain now and a
machine later. Every public ledger is already a stored, dated list of targets.
Bitcoin cannot fix this except additively, because millions of coins sit behind
published curve keys that no authority can move. A new chain can make the
substitution at the start, while it is still cheap. So I did.

---

## It actually ran

Not a testnet, not a demo.

- **Mainnet since 11 July 2026** — genesis mined, block 1 at 22:26 UTC that day
- **12,581 blocks and 124 GH/s of network hash rate on 31 July 2026**, on a
  public explorer — so other people were mining it, which is the part I am
  gladdest about and handled worst
- Releases through **v0.2.0**, CI on every commit
- Complete node: full validation, HD wallet, P2P, RPC, GUI, and a standalone
  **OpenCL GPU miner**, so any commodity card could mine
- Fixed supply 21 million, 10-minute blocks, halving every 210,000

---

## What it cost, stated plainly

Post-quantum signatures are large. A signature goes from 71 bytes to 2,420 and a
public key from 33 to 1,313 — **3,733 bytes of key and signature per input
against about 104**, a factor of roughly 35.

A chain that swapped its signatures and left its block size alone would have
quietly cut its own capacity by a factor of eight. I sized the block against the
new cryptography instead: **32 MB, about 8,300 ordinary payments per block
against Bitcoin's ~7,100**. So users paid in bandwidth and disk rather than in
throughput — roughly **4.6 GB per day at full blocks**.

That trade is defensible on paper. What it means in practice is that the block
size stopped being a decision about what the network should cost to run and
became a consequence of the signature scheme. The tail was wagging the dog, and
every later argument about capacity, pruning or light clients started from a
number I had not chosen.

---

## What stopped it

**1. No audit, and no way to get one.** The ML-DSA-44 and ML-KEM-768
implementations come from PQClean, which is reviewed upstream, but *their
integration into consensus and wallet code was never audited by anyone else*. I
listed this in my own docs as the single highest-value outstanding item, and it
stayed outstanding. Consensus code that has been read by exactly one person is
not a security posture, it is a hope.

**2. The ecosystem problem is worse for a post-quantum chain than for any other
new chain, and it is structural.** No exchange, no hardware wallet, no light
client — and each of those is harder than usual *precisely because* the
signatures are bigger than existing protocols and devices assume. There was
deliberately no migration path for existing coins: a new ledger, not a bridge.
Which is honest, and also means the only way in was to mine it.

**3. Unauthenticated transport.** The encrypted handshake protected against a
passive observer, not an active man-in-the-middle. Same posture as Bitcoin's own
v2 transport, and the same room for improvement — but I never closed it.

**4. Almost no history.** Weeks old against QRL's eight years and Bitcoin's
seventeen. Design arguments do not substitute for having survived attack, and
only time supplies that.

**5. At the very end I lost the plot.** In the last days of July I tried to
replace proof of work with proof of *training* — a miner trains a model, every
node checks with one forward pass that the loss went down. I removed it a day
later (`consensus: remove proof of training`, 30 July) and then, in August,
started it again as a separate project and abandoned that too. Some of those
measurements are genuinely interesting and I have put them at the bottom of this
post rather than pretending they were part of Lattica, because they were not.
Chasing a second idea before finishing the first is how the first one dies.

---

## What stopped it that was not technical

There was hash rate on that chain. 124 GH/s is not one person's GPU. Somebody
was mining, somebody was running the explorer queries, and I could not tell you
who any of them were, because I never built a place for them to talk to me and I
did not go looking.

What I experienced was silence — I was writing releases and design documents
into what felt like an empty room, and after a while I stopped being able to
tell the difference between "this is hard" and "this is pointless." What was
actually happening is that I had built a network and no way to hear it.

**To anyone who was mining, running a node, or who sent something I never
answered: I am sorry.** I think I did not see you rather than ignored you, which
is an explanation and not an excuse. If you supported this and got silence back,
that was on me, and the whole reason for this thread is that I would rather be
told I am wrong than repeat it.

---

## The part I now think was wrong: "no elliptic curve anywhere"

This was the project's entire identity. It survives a grep, it is checkable in
one command, and it is the wrong question — and I would like to save someone
else the detour.

**Ownership failure is repairable; confidentiality failure is not.** If a
signature scheme breaks, a chain hard-forks to new keys and past coins stay
owned. If a *confidentiality* construction breaks, every byte already recorded is
public and permanent, and it is deanonymised retroactively and forever. Those
are different severities, and "is there a curve in the source" does not
distinguish them.

I then made the *opposite* mistake and nearly spent years on it. The next idea
was: build the privacy chain whose privacy survives a quantum computer, using
hash-based proofs (STARKs) because Monero's rings, Zcash's Groth16/Halo2 and
everything else deployed rest on curves. That looks forced. It is a
non-sequitur.

Groth16, Halo2/IPA and Bulletproofs are **perfect or statistical zero-knowledge**.
Pedersen and Sinsemilla commitments are **perfectly hiding**. An unbounded
adversary learns nothing from a proof string or a value commitment. What a
quantum adversary breaks there is **soundness and binding** — counterfeiting —
which is exactly the fork-repairable half. Paying 200–1000x in proof bytes for a
hash-based system buys post-quantum *soundness*, not post-quantum *privacy*.

The genuinely retroactive channels are elsewhere, and they are cheap to fix:

- **in-band note encryption over ECDH** — the real hole;
- stealth-address key agreement;
- **EC-derived linkability tags** — Monero's `I = x·H_p(P)` is the worst case,
  since a discrete-log oracle recomputes every key image and unravels the
  historical spend graph without knowing a single address;
- the P2P transport (BIP324 is ElligatorSwift X25519; Tor v3 is x25519/ed25519);
- **account-scoped viewing keys**, which are the same retroactive break with a
  subpoena as the trigger instead of a quantum computer.

Closing all of them costs about **1.1 KB per shielded output** (an ML-KEM-768
ciphertext at 1,088 B replacing a 32-byte ephemeral key), zero bytes for a
hash-PRF nullifier, and ~2,272 B once per connection on the wire — with **zero
cost inside the circuit**, because the KEM is never verified in-circuit.

And that is why it is not a project: anything an incumbent can add in one
network upgrade is a feature, not a moat. Worse, the retroactive loss has
already happened twice and the market priced it at zero both times — Secret
Network's consensus-seed extraction in October 2022 retroactively decrypted every
private transaction since genesis and the chain lived four more years; Monero's
entire pre-RingCT history is retroactively readable (~62% of mixin-bearing
inputs deducible, Möser et al., PETS 2018) and XMR went on regardless. The one
event that moved a privacy coin's price hard was a **counterfeiting** bug.

Short version: post-quantum privacy is a real property, a buildable property,
and a cheap property. It is not a business. And "zero curve files" is an
aesthetic, not a threat model.

---

## Numbers I measured that someone may want

Free to a good home, all from my own hardware.

**ML-DSA-44** (FIPS 204): pk 1,312 B, sig 2,420 B. Verification roughly 3x
slower than secp256k1 Schnorr. Seven ML-DSA public keys fit in a 10,000-byte
script (9,205 B with push overhead); eight do not.

**ed25519 vs secp256k1**, same process, same timer, libsodium ref10 against
libsecp256k1: ed25519 signs faster and **verifies slower**. Verification is what
every node does on every input of every block; signing happens once in a wallet.
The commonly repeated "50–70x faster" is not a thing I could reproduce in any
direction.

**SQIsign lvl1** (broadwell backend), the most interesting post-quantum
candidate because it is isogeny-based with tiny keys: pk 65 B, sig 148 B —
smaller than ML-DSA by a factor of 20. Measured against secp256k1 Schnorr in the
same process: signing roughly **three orders of magnitude** slower, verification
**one to two orders** slower, the exact ratio depending on machine load. It is
also not standardised and its signing is not constant-time. Small signatures,
and you pay for every one of them.

**Proof of training**, from the experiment I should not have started: a training
step is **bit-reproducible across different GPUs** — two RTX 5090 ran 200
consecutive steps from one seed with 0 divergences — and determinism costs
**0.4%** (2038.5 ms/step against 2030.Cool. A forged step localises to a single
flipped bf16 bit in **7 rounds of 32-byte messages**. Verification by forward
pass is ~4.4x cheaper than production on CPU and ~2500x on a GPU. The reason it
still does not work: the held-out batch is public before the work starts, so a
miner can simply train on it, and the fix — deriving the batch from the *next*
block — costs a block of latency and a rule for what happens when the next block
never comes. I wrote neither.

---

## What I am asking for

Not "ideas for a new coin." Specific questions get answers worth having; open
ones get a hundred posts about tokenomics.

1. **Is there a payment property an ordinary person can feel that Bitcoin,
   Monero and Zcash all fail at?** Not a primitive — something a user notices. I
   no longer believe "quantum-safe" or "more private" is one of those, and I
   would like to be shown otherwise with evidence.

2. **If you mined Lattica: why?** Genuinely. That is 124 GH/s of decisions I
   never understood, and it is the most valuable data I have.

3. **Has anyone published prove time and peak RSS for a payment-shaped halo2
   circuit on a mid-range phone?** I cannot find it, and it decides whether
   client-side proving is a product or a demo.

4. **Post-quantum note delivery bandwidth.** An ML-KEM ciphertext is
   indivisible, so a light client pulls 1,088 B per output where Zcash's compact
   output is 116 B — 9.4x, permanently. Public buckets leak a plaintext
   recipient label forever; OMR and PIR are called impractical by the people who
   tried them; tag streams need prior contact and are ECDH-derived. If there is
   a real answer I want to read it.

5. **What would make you run a node on a new chain in 2026?** I suspect the
   honest answer for most people is "nothing." I would like to hear the
   exceptions.

Discord: https://discord.gg/r9g2Dp4DT

Come and argue. Wrong answers with reasons beat agreement, and if the conclusion
is "do not build another chain," that is a legitimate outcome — I would rather
reach it in a thread than in year three.

---

*Every number above is from my own tree or my own hardware. Anything I could not
measure is labelled. If one of them is wrong, say which and I will correct it in
this post rather than in a reply.*
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!