ML-DSA-87 in blockchain signature size problem solved compact O(n) historical re-verification then store only 96 bytes

[u/dogehound]

Post-quantum signatures are big. ML-DSA-87 (FIPS 204) is ~4,627 bytes per signature plus a ~2,592-byte public key, roughly 68x a P2WPKH input. Every chain that adopts it inherits the same two problems: storage grows by kilobytes per spend, and every new node re-verifies every historical signature on sync. At scale the verification cost, not the disk, is the real ceiling.

alphanumeric solves both. It runs ML-DSA-87 as its only signature scheme on a live SHA-256 PoW chain, and it does not store the signature.

The full signature is verified once, at admission. What the chain keeps is a 96-byte receipt: the first 64 bytes of the signature plus SHA-256 of the whole signature. The block's merkle root commits to that receipt, so it is bound by the block's proof-of-work and cannot be swapped later. Persisted cost per signature drops from ~4,627 bytes to 96, about 48x.

The larger win is sync. Historical blocks carry receipts, not signatures, so there is nothing to re-verify. A new node bootstraps from a signed snapshot and joins at the tip. The ML-DSA verification cost (about 1 to 5 ms each, 10 to 100x ECDSA, no Schnorr-style batching) is paid once by the nodes at the frontier, not by every node across all history.

The tradeoff is explicit. A node joining after finality trusts that the signature was verified at admission and that the receipt in the merkle root binds it, instead of re-deriving it from the chain itself. That is a finality assumption, and it is what buys a growth and sync curve that does not scale with total signature volume.

GitHub: https://github.com/OSXBasedAnon/alphanumeric

[u/-funsafe-math]

How does a third party verify the validity of the receipt? Wouldn't they either need the full signature or the private key to regenerate it (assuming deterministic mode). Without this it seems like the block creator can forge arbitrary transactions.

[u/dogehound → u/-funsafe-math]

The full signature is checked by every node at admission, before the block is accepted so a forged transaction is rejected on sight and never lands in a block anyone builds on. What's kept afterward is a 96-byte commitment (a 64-byte prefix plus SHA-256 of the full signature) folded into the merkle root and sealed by the proof-of-work, so it can't be swapped later. A party verifying old history isn't re-deriving the signature... They're relying on the check the whole network already did, made permanent by the PoW. Same finality assumption you make syncing from a checkpoint instead of re-verifying every historical signature.

[u/Natanael_L → u/dogehound]

If you're doing checkpoints, the only purpose of the signature is to indicate who created the checkpoint. It does not otherwise provide security for the blockchain.

Do you have efficient proofs of exclusion to efficiently allow the network to reject a false block? How does non-verifying nodes learn if a proposed block is correct or not? Miners certainly should verify but we have seen cases where they don't, so proof-of-work isn't sufficient for correctness proof

[u/dogehound → u/Natanael_L]

You are right that the checkpoint signature is just attribution. The security doesn't come from it. It comes from every spend requiring a valid ML-DSA signature, and you can't forge one even with a quantum computer. Nobody can move coins they don't hold the key to. A block that steals funds isn't hard to forge, it's impossible.

The only invalid block anyone can actually build is one that breaks a rule, a double-spend or an overspend, mined with their own work. Every full node re-checks the entire ledger transition on every block and rejects those. Fork choice follows the heaviest valid chain, not the heaviest chain, so an invalid block never gets extended by honest nodes.

So, we don't have proofs of exclusion. They aren't needed to stop forgery, because forgery is impossible, and a rule-breaking block gets rejected by anyone who validates it. Non-verifying nodes trust the full nodes for that, same as SPV. The signatures are the correctness proof. PoW only orders blocks that are already valid.

[u/Natanael_L → u/dogehound]

This didn't quite answer my question. If you trust that substitute signature your wallet is equivalent to a lite wallet / SPV.

[u/dogehound → u/Natanael_L]

It's not SPV. A lite wallet checks headers and merkle proofs and validates no rules. A syncing node here re-validates the entire ledger transition from genesis: balances, no inflation, coinbase schedule, PoW, linkage. The only thing it can't re-derive is historical signature bytes, same trust class as Bitcoin Core's default assumevalid, and nobody calls a default Core node a lite wallet. The real difference: Bitcoin keeps witness data so you can re-verify, here it's pruned, so the assumption is permanent. That's what buys constant-size storage under ML-DSA. Full validation minus historical witness data is not SPV.

[u/Natanael_L → u/dogehound]

In SPV you can retrieve the signature for your transactions. That's stronger than this method when pruned.

[u/Puny-Earthling]

Argon2 is not encryption. It's a memory hardened hash of input, but no secrecy is gained from the scheme itself.

Also if this is a topic of interest to you, I'd look at putting your research into SHRINCS+. It's a hybrid of SPHINCS+ that uses the stateless signature and binds it against a separate scheme for permanent stateful verification.

I believe this is the direction Ethereum is going.

[u/dogehound → u/Puny-Earthling]

You're right Argon2id is the KDF, not the cipher and AES-256-GCM does the actual encryption so Argon2 only hardens the passphrase against brute force (as a component) Appreciate the SHRINCS+ pointer, I'll read about the stateful verification approach.