In the quiet hours of a Berlin evening, I read a fragment of a technical analysis that distilled Bitcoin's post-quantum future into two paths: enlarge the block or compress signatures with STARK proofs. The analysis was dry, academic, yet it cut to the bone of what keeps me awake at night. Trust no one. Verify everything. But what happens when the very verification mechanism—digital signatures—becomes a liability? This is not a question for the distant future. It is a dilemma already casting its shadow over the greatest store of value ever created.
Let me give you the context. Bitcoin's current security relies on the ECDSA signature algorithm, which is vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer. The industry standard for post-quantum security is the Lamport signature or the SPHINCS+ scheme, both of which produce signatures that are orders of magnitude larger—kilobytes instead of a few dozen bytes. A single post-quantum signature could fill an entire block today. Multiply that by thousands of transactions per block, and you have a network that simply cannot function. This is the core problem.
Two solutions emerged from the analysis I read. Option A: increase the block size. Simple, linear scaling. Double the block size, double the throughput. Option B: aggregate all signatures in a block into a single STARK proof, reducing the signature data to a small constant size. The analysis correctly called this a dilemma. But it missed what I see as the real story: both solutions are Trojan horses, each carrying a hidden cost that threatens Bitcoin's most sacred value—decentralization.
I have been here before. In 2017, during the ICO frenzy, I audited whitepapers for fifteen Ethereum-based protocols. One of them, a prediction market platform, claimed to be trustless yet relied on a centralized oracle to settle bets. I published a 5,000-word critique titled 'Math Over Hype.' The community debated it fiercely. But the pattern repeated: elegant technical solutions that ignored the governance reality. The same pattern haunts this quantum dilemma.
Option A: The Big Block Mirage
Increasing the block size is the simplest path, but it is a regression. Bitcoin Cash and Bitcoin SV tried this. They failed to gain adoption. Why? Because bigger blocks mean higher hardware requirements. A 10 MB block requires less bandwidth than a 100 MB block. The current Bitcoin block size limit of 1 MB is a compromise. Increasing it to, say, 10 MB to accommodate post-quantum signatures would raise the bar for running a full node. Today, you can run a node on a Raspberry Pi with a consumer internet connection. Under the big block regime, you would need a data center. That reduces the number of nodes, centralizes validation power, and makes the network vulnerable to censorship and regulatory capture. The analysis I read called this 'linear scaling.' I call it a slow death of the very property that makes Bitcoin valuable.
Option B: The STARK Trap
The second option is technically beautiful. STARK proofs, used by Ethereum's ZK-rollup projects like StarkNet, can compress an arbitrary number of signatures into a single, tiny proof. The verification is fast, post-quantum secure, and does not require increasing block size. But this is not a silver bullet. STARKs rely on hash functions and the security of the proof system itself. They replace the trust in many validators with trust in a cryptographic construction. That is a different kind of centralization. Moreover, integrating STARKs into Bitcoin's protocol would require a soft fork, a monumental governance challenge. The Bitcoin community has not agreed on a significant protocol upgrade since SegWit in 2017. And even SegWit took years and nearly caused a civil war. Based on my experience in community building—especially the Soulbound Berlin project where I saw idealism shatter against greed—I know that consensus is fragile. The STARK path may be clean in theory, but in practice it is a minefield.
Deeper analysis: The real bottleneck is not the block, but the oracle
The analysis I read framed this purely as a scalability problem: post-quantum signatures are too large, so we must either make blocks bigger or compress the data. But it missed a crucial angle: the oracle problem. Validating a Bitcoin transaction requires knowing the current state—utxos, scripts, signatures. Under option B, you need to verify the STARK proof, which requires access to the entire block's worth of data. That means you still need to download the full block content to verify the proof of inclusion. Unless you use recursive proofs, which add even more complexity. In DeFi, we have seen how oracle feed latency is the Achilles' heel. Chainlink 'solves' decentralization with a network of centralized nodes, a joke I have often made in my workshops. Here, the same joke applies: STARKs 'solve' signature bloat but introduce a new latency in proof generation and verification. Is that any better?
The Layer2 fragmentation angle
I have written before about the proliferation of dozens of Layer2s that slice already-scarce liquidity. Here, the quantum dilemma risks creating an illusion of scalability while actually reducing network resilience. If we adopt one of these options, we might end up with a chain that is harder to scale downstream. Lightning Network, for example, relies on low-cost on-chain transactions for channels. Bigger blocks would reduce fees but centralize the base layer. STARKs would keep fees low but add a dependency on advanced cryptography that might not be easily auditable by ordinary users. The analysis did not connect this to the broader ecosystem. I will.
Contrarian view: The dilemma is a red herring
The analysis presented these two options as exhaustive. But there is a third path: do nothing. Quantum computers are still theoretical. Most estimates say we have at least a decade before a fault-tolerant quantum machine can break ECDSA. In that time, signature schemes may improve. Or we can adopt a hybrid approach, using current signatures alongside a quantum-safe backup. This is what many security researchers recommend. The urgency is manufactured by those who want to push a specific upgrade for their own interests. Miners want bigger blocks to collect more fees. Core developers want a technological showcase. Let us not forget that the Bitcoin network has survived for 15 years without this change. It is not broken. The analysis I read is a classic case of 'solutionism'—seeing a problem and rushing to solve it before understanding the consequences.
My personal experience with such decision-making
During DeFi Summer of 2020, I worked with MakerDAO developers to build a governance simulation model. We designed a system that looked perfect on paper. But when whales captured the voting power, all our simulations failed. The gap between theoretical elegance and practical governance is vast. I isolated myself in my Berlin apartment for two weeks after that project. I learned that technical solutions cannot fix social failures. The quantum dilemma will be resolved not by cryptography alone, but by the messy, human process of consensus. And as the 2022 bear market taught me—when I withdrew from public discourse to read political philosophy—the market forces that drive these decisions are often irrational. We are not rational actors. We are fearful, hopeful, and easily swayed by narratives.
The data that matters
Let me give you some numbers. The current average Bitcoin block size is about 1.5 MB. A realistic post-quantum signature from SPHINCS+ is 41 KB. A typical transaction has one input and two outputs, requiring three signatures. That is 123 KB per transaction. A block can hold about 4,000 such transactions now. Under post-quantum signatures, a block would hold only about 12 transactions. That is a 99.7% drop in capacity. To restore capacity, you would need to increase block size by 330 times, to about 500 MB per block. That is impossible for a decentralized network. STARK compression can reduce the 123 KB per transaction to about 10 KB overhead for the proof plus 100 bytes per transaction for the transaction data itself. So a block of 4,000 transactions would be about 0.5 MB, even smaller than today. The numbers speak: STARKs are the only viable technical path. But the governance numbers are worse. Any soft fork requires overwhelming miner support—at least 95% hashrate activation. In 2017, SegWit took two years and a user-activated soft fork (UASF) to get there. The community was deeply divided. Can we do it again?
The real risk: fragmentation
The analysis I read mentioned that these options are not mutually exclusive. You could combine bigger blocks with STARKs. But that would be the worst of both worlds: complex and centralizing. The real risk is that the debate itself fragments the community. We have seen this before. The Block Size War of 2017-2018 split the community, created a competing coin (Bitcoin Cash), and caused years of brand confusion. The same could happen again, only this time the stakes are higher because Bitcoin is now an institutional asset with ETFs and trillion-dollar market cap. A hard fork would be a disaster for the ETFs, which hold 'Bitcoin' as a single asset. The custodians would need to decide which chain to support. The legal uncertainty could trigger a selloff. The analysis did not explore this market impact at all.
As an evangelist, I must ask: what is the purpose of this upgrade?
Bitcoin's value proposition is not high throughput. It is a settlement layer, not a payment rail for coffee. Lightning Network exists for that. So why are we even concerned about post-quantum signature size? Because in 10 years, quantum computers may break ECDSA. But in 10 years, any solution we deploy today would be obsolete due to new cryptographic advances. The best upgrade might be a simple parameter change: allow segwit version 2 with a new script that supports quantum-safe signatures alongside the old ones. That would be a minimal soft fork, not requiring STARK complexity. That is the pragmatic path. But it is not dramatic enough to excite the community. The analysis I read missed this middle ground.
Conclusion: The dilemma is ours, not the technology's
The quantum dilemma is a mirror. It forces us to decide what Bitcoin is: a digital commodity meant to last centuries, or a technology that must adapt to survive. The answer is both, but adaptation must preserve the core. Trust no one. Verify everything. But if the verification becomes so complex that only experts can run nodes, we have already lost. I see a third path: incremental soft forks that introduce quantum-safe signatures as options, not replacements, with a long transition period. That maintains decentralization and upgrades gradually. It is boring, it is slow, but it is safe. Gold is heavy. Code is light. But code that centralizes is just heavy gold in disguise. Summer fades. Builders remain. And the builders of Bitcoin's future must choose not the flashiest upgrade, but the one that keeps the network open, accessible, and trustless.
Let me end with a question for those who read this: when you hold a Bitcoin today, are you trusting the cryptography, or the community that maintains it? The quantum dilemma will answer that for all of us.