Bitcoin’s post-quantum signature bloat revives bigger-blocks vs STARK aggregation debate
Modeling of NIST’s ML-DSA-44 implies blocks could fit roughly 500–700 transactions without mitigation.
Bitcoin’s long-horizon move toward post-quantum signatures is resurfacing an old scaling fault line: absorb larger signatures with bigger blocks, or compress them with ZK-STARK aggregation. A modeled NIST scheme puts the potential throughput hit in stark terms, with block capacity estimated to fall to roughly 500–700 transactions from about 2,500–3,000 today if nothing else changes.
Key Takeaways
- NIST-approved post-quantum signature schemes are described as 10 to 100 times larger than Bitcoin’s current ECDSA and Schnorr signatures.
- Modeling of ML-DSA-44 at 2,420 bytes per signature implies Bitcoin block capacity could drop to roughly 500–700 transactions from about 2,500–3,000 today.
- The mitigation debate is being framed around two levers: raising Bitcoin’s block size or aggregating signatures into a small ZK-STARK proof.
- Bitcoin Script cannot verify a STARK today, and Marin Ivezic characterized base-layer STARK verification as “realistically a 2030s conversation.”
Post-Quantum Signatures Put Bitcoin Throughput in the Spotlight Again
The near-term market impact is not about quantum computers showing up tomorrow. It is about what happens to Bitcoin’s throughput and fee dynamics if the network ever migrates from ECDSA and Schnorr to post-quantum (PQ) signature schemes that are materially larger.
NIST-approved PQ signature schemes are described as roughly 10 to 100 times larger than Bitcoin’s existing signatures. That size increase is not cosmetic. Signatures are a core part of transaction weight, so signature bloat translates directly into fewer transactions per block unless the protocol changes elsewhere.
Marin Ivezic, author of PostQuantum.com and founder of Applied Quantum, modeled NIST’s ML-DSA-44 at 2,420 bytes per signature and estimated block capacity would fall to roughly 500–700 transactions per block, down from about 2,500–3,000 today. SegWit is described as reducing the impact of large signatures by up to 75%, but the ML-DSA-44 estimate still implies a step-down large enough to pull scaling and fee-market narratives back into the center of the Bitcoin roadmap.
Two Competing Fixes: Bigger Blocks vs ZK-STARK Signature Aggregation
The debate is being presented as a choice between a politically hard lever and a technically hard lever.
One path is straightforward engineering: increase Bitcoin’s block size to absorb larger PQ signatures. The tradeoff is node cost. Larger blocks mean more bandwidth, storage, and verification work for every full node, which critics argue pushes the network toward centralization. The block-size fight is not theoretical either. Bitcoin split over a proposal to double the block size in 2017, and that history still shapes governance reflexes.
The other path is compression: aggregate signatures into a ZK-STARK proof so blocks do not have to carry every individual signature. StarkWare co-founder Eli Ben-Sasson argued a single proof could compress “all of the large transaction signatures for a block” into a “tiny” proof, and claimed the proof could be smaller than including even today’s signatures, potentially making the chain run faster. He warned that adopting PQ signatures without aggregation would fail the usability test: “If they don't allow for ZK STARK aggregation, then definitely it will be a very unfortunate move because it won't really solve the problem ... where the problem is ‘can everyone actually use Bitcoin?’”
Why STARKs Aren’t Plug-and-Play on Bitcoin Today
The constraint is not whether STARKs work in the abstract. It is whether Bitcoin can verify them under consensus rules without expanding the attack surface.
Ivezic argued that “Eli's cryptography is rock solid: pure hash assumptions, no trusted setup, thousands of signatures compressed into one small proof. The problem is everything around the cryptography,” adding: “Bitcoin Script cannot verify a STARK today, and a production verifier is a massive consensus surface compared with a narrow hash-signature opcode. Given that a tiny opcode like OP_CAT has spent years in debate, a base-layer STARK verifier is realistically a 2030s conversation.”
The most “politically pragmatic” on-ramp discussed is re-enabling OP_CAT, described as nine lines of code written by Satoshi. Ben-Sasson argued OP_CAT could enable STARK proofs and aggregation, but interest that surged 12–24 months ago is described as having lost momentum more recently. More speculative ideas mentioned include OP_STARK_VERIFY and BitZip, and Ethan Heilman framed the design space as either adding general-purpose opcodes to build something like a ZKRollup on Bitcoin or supporting STARKs at the consensus layer, with weaker aggregation options like CISA also on the table.
Signals Traders Should Track in the Bitcoin PQ Roadmap
The first signal is concrete BIP movement or renewed maintainer and developer signaling around OP_CAT re-enablement, since it is framed as the most pragmatic bridge to STARK-related constructions.
The second is whether any proposal to enable STARK verification on Bitcoin progresses beyond discussion. Script cannot verify a STARK today, so the market-relevant question is whether the conversation shifts toward opcode-based approaches or consensus-layer support, and whether either gains credible momentum.
Third, watch for follow-on modeling and benchmarks that refine the ML-DSA-44 estimate of 2,420 bytes per signature and the implied ~500–700 transactions per block. If alternative PQ schemes materially change the signature-size profile, the urgency of the scaling tradeoff changes with it.
Finally, cross-chain milestones can create narrative pressure. Starknet announced a three-phase project to become quantum secure, and the article describes Ethereum as targeting 2029 for a post-quantum transition while Solana experiments with PQ signatures. Those timelines do not force Bitcoin’s hand, but they can shift expectations about what “reasonable” progress looks like.
Governance, Not Cryptography, Looks Like the Real Bottleneck
I treat the ML-DSA-44 modeling as the key forcing function. If Bitcoin ever goes NIST-style PQ without mitigation, the throughput math is ugly enough to drag scaling and fees back into the macro narrative, even if the quantum threat itself remains long-dated.
The threshold that matters is whether Bitcoin governance can converge on any credible mitigation path before PQ becomes more than a research topic. Bigger blocks are the simpler engineering lever but historically the hardest to socialize, while STARK aggregation reads cleaner on throughput but runs straight into Script limits and consensus-surface risk. If OP_CAT or any STARK-verification path moves from “interesting” to “actionable,” the setup starts to look structural rather than narrative-driven, because it would define how Bitcoin absorbs a security upgrade without reopening the block-size war.
