Posts  / #POST-231834
REDDIT

Empirical ML-DSA-87 (NIST FIPS 204) signature sizing and block architecture data from a live SHA-256 PoW deployment

G
Jul 11, 2026 · 20:17

Sharing production measurements from a live mainnet deployment of ML-DSA-87 as the sole signing algorithm for a proof-of-work chain. Most PQC discussion at the implementation level is still theoretical — these are on-chain figures.

**Signature sizing (per input, live mainnet):**

* ML-DSA-87 signature: \~4,627 bytes
* Public key: \~2,592 bytes
* Total per input: \~7,260 bytes
* Comparative overhead: \~68× a P2WPKH input

**Block stress test:**

* 715,001 ML-DSA-87 signed outputs in a single transaction
* Block size: \~31MB
* Signing time: \~1.15 hours to construct and sign
* Fee rebump + full resign: \~10 additional minutes

**Chain growth implications:**

* At 100 ML-DSA-87 transactions per block (60s intervals), storage grows \~864 MB/day
* Year-one projection: \~415 GB including storage engine overhead
* This is purely a function of signature size — the cryptographic tradeoff is explicit and expected

**First non-coinbase ML-DSA-87 spend on a live PoW chain (verifiable):**

* Block #283, June 2, 2026
* TXID: `62572d2127da3d42afb0b20757edb844b0820851f4d8340cbc7e26954ae6272c`

Full empirical writeup with methodology posted to Delving Bitcoin:
search 'Empirical ML-DSA-87 data from a live SHA-256 PoW chain'."

ML-DSA-87 verification runs \~1–5ms per transaction on current hardware — roughly 10–100× heavier than ECDSA. Batch verification optimizations available in Schnorr don't directly apply here. What the community would know better than us: are there any known UTXO-model implementations that have meaningfully closed that gap?


Disclosure: Drafted with AI assistance (Claude, Anthropic). All data figures are independently verifiable on-chain.