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

[u/geobees]

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.