The 20x Problem

The 20x Problem

A typical Bitcoin transaction with two inputs and two outputs (the shape most planning models use as the reference) is roughly 372 bytes. The same transaction signed with Dilithium2 is approximately 7,636 bytes, about 20 times larger. This single ratio drives nearly every protocol-level change required to build a quantum-resistant Bitcoin.

The size increase comes from the witness data. Each input carries its own Dilithium witness stack: a 2,421-byte signature (2,420 bytes plus one byte for the sighash type) and a 1,312-byte public key, roughly 3,733 bytes per input. Compare that to ECDSA’s ~72-byte signature and 33-byte compressed public key. The transaction header, input outpoints, and output scripts stay roughly the same size. The authentication data is what explodes.

This is not a flaw in Dilithium. It is the cost of quantum resistance. Every post-quantum signature scheme produces larger signatures than ECDSA: FALCON signatures are ~666 bytes, ML-DSA (Dilithium) signatures are ~2,420 bytes, and SPHINCS+ signatures range from 7,856 to 49,856 bytes.² No known post-quantum scheme matches ECDSA’s compactness. The question is not whether transactions get larger, but how to absorb the increase.

Block Capacity Impact

Bitcoin’s block weight limit is 4,000,000 weight units (4 MW), which translates to a maximum serialized block size of roughly 4 MB once you account for the SegWit witness discount. With 372-byte ECDSA transactions, that fits approximately 10,750 transactions per block.

With 7,636-byte Dilithium transactions, the same 4 MB block fits approximately 520 transactions, a 20x reduction in throughput at the same block size. To maintain even Bitcoin’s current transaction throughput (already considered low), you need larger blocks.

The BTQ project raised MAX_BLOCK_SERIALIZED_SIZE to 8 MB and MAX_BLOCK_WEIGHT to 8,000,000 weight units. The binding consensus limit is block weight, not serialized size,⁵ so a weight-full block of ordinary two-input Dilithium transactions holds roughly 800 of them. (Dividing the 8 MB size cap by transaction size suggests ~1,050, but a block of that many would exceed the 8 MW weight limit.) The sigops limit was doubled to 80,000 to cover the validation cost of the larger signatures.¹

Other protocol limits needed adjustment too: MAX_SCRIPT_ELEMENT_SIZE rose from 520 bytes to 15,000 (to fit Dilithium5 signatures plus keys on the stack), MAX_SCRIPT_SIZE rose to 100,000 bytes (for complex multi-sig scripts), and MAX_PROTOCOL_MESSAGE_LENGTH rose to 70 MB (to handle P2P block propagation).¹

The Witness Discount Question

Bitcoin’s SegWit upgrade introduced a witness discount: witness data (signatures and public keys) counts at 1/4 weight, while non-witness data (outputs, scripts) counts at full weight.³ The economic rationale is sound: witness data is only needed for validation and can be pruned by archival nodes, while output data (the UTXO set) must be kept permanently. The discount rewards transactions that use more prunable witness space relative to permanent UTXO space.

For quantum-resistant transactions, where the witness dominates transaction size, the discount matters even more. Without it, Dilithium’s 3,733-byte witness costs the same block weight as 3,733 bytes of UTXO data, erasing any economic signal about what is prunable.

The BTQ project initially disabled the witness discount (setting weight equal to serialized size) for simplicity, but community analysis quickly surfaced the consequence. With output bytes and witness bytes costing the same weight, nothing discourages bloating the permanent, unprunable UTXO set relative to prunable witness data, exactly the economic signal SegWit’s discount exists to send. Note: disabling the discount does not shrink chain growth, either; if anything, it lets blocks carry slightly more serialized data since the per-byte penalty on non-witness data is removed.

The fix was to restore and increase the witness scale factor to 16 (up from Bitcoin’s 4), so witness data counts at 1/16 weight.¹ That stronger discount reflects the reality that in a Dilithium world, an even larger share of each transaction is prunable witness data. The per-input witness overhead (3,733 bytes) at the 1/16 discount contributes ~233 virtual bytes to the block (weight ÷ 16), versus ~26 virtual bytes for ECDSA’s ~105-byte witness under Bitcoin’s 1/4 discount. In summary, the heavier discount narrows the gap from ~36x in raw witness bytes to ~9x in block-weight terms. This softens the cost, but does not erase it.

Chain Growth and Node Viability

Chain growth rate determines who can run a full node, the foundation of Bitcoin’s decentralization. The arithmetic is straightforward as outlined below:

The ceiling rows are the absolute serialized maximum, 8 MB per block × 1,440 blocks per day, a worst case scenario for an early network.⁵ In practice BTQ blocks are far from full during bootstrapping; the realistic rows assume blocks about half full, the standard planning baseline. A full block of ordinary two-input Dilithium payments is itself weight-limited to ~6.1 MB (~8.8 GB/day); the 11.5 GB/day ceiling is approached only by witness-dominated blocks. The limits still matter because they define the maximum stress the network can sustain, and an attacker with enough funds could fill blocks toward this level.

The growth rate is manageable with modern hardware. Provisioning roughly 1.5 TB covers an archival node’s first year (about 8 TB over five years) against a realistic ~1 TB of annual growth; a pruned node, which validates every block but retains only recent blocks plus the UTXO set, needs about 50 GB. That is a meaningful increase over Bitcoin’s ~90–100 GB per year, but it stays within reach of today’s commodity hardware. This is an inherent cost of quantum resistance: larger signatures mean more data, however you structure the blocks. The design goal is to keep that cost manageable, not to eliminate it.

Emission Schedule and Block Timing

Block timing interacts with the emission schedule in ways that are easily misunderstood. BTQ adopted 1-minute blocks (10x faster than Bitcoin) to compensate for the reduced per-block transaction capacity. Faster blocks mean more total block space per hour, partially offsetting the 20x transaction size increase.¹

But Bitcoin’s halving schedule is defined in block count, not clock time. With Bitcoin’s 210,000-block interval and 10-minute blocks, halvings land every ~4 years. With 1-minute blocks and all else constant, halvings would land every ~5 months, burning through the entire 21 million coin supply in under 3 years.

The fix is to scale the interval proportionally: 2,100,000 blocks (10x the Bitcoin interval) at 1-minute spacing reproduces the same ~4-year halving cadence. The block reward was set to 5 BTQ (against Bitcoin’s initial 50 BTC), with the same 21 million total supply cap. The difficulty retarget window was set to 20,160 blocks (2 weeks at 1-minute spacing, matching Bitcoin’s 2-week retarget).¹

Getting these parameters right is critical. Errors in the emission schedule affect miner incentives, supply dynamics, and network security. During development, community review caught a mismatch where block timing was set to 10 minutes while the halving interval assumed 1-minute blocks, which would have produced ~40-year halvings. It was corrected during testnet deployment, a reminder of why live testing and public code review matters for consensus-critical parameters.

No Free Lunch

The block size analysis points to one constraint: quantum resistance has a storage cost, and no amount of engineering eliminates it. You can redistribute the cost through witness discounts, offset reduced throughput with faster blocks, and manage chain growth through pruning and archival strategies, but the data itself has to exist somewhere.

Every proposed answer to Bitcoin’s quantum vulnerability faces the same constraint. BIP-360’s P2MR addresses (originally drafted as P2QRH) carry the same signature size overhead.⁴ Any post-quantum scheme adopted by Bitcoin Core will require consensus changes to block weight calculations, script limits, and possibly block timing. The question is not whether to pay this cost, but when and how.

Projects such as Bitcoin Quantum provide practical datasets for evaluating these tradeoffs. Theoretical chain-growth calculations are easy to dismiss. Metrics gathered from a live hardened network processing real transactions are harder to ignore, and easier to use as the basis for informed protocol design.

References

1. BTQ-Core consensus parameters (v0.3.0-testnet): block size, weight, sigops, and witness scale in consensus.h, script limits in script.h, and the halving interval, block spacing, and 5 BTQ subsidy in chainparams.cpp.
2. Open Quantum Safe. Post-quantum signature sizes (ML-DSA 2,420 bytes; FALCON ~666; SPHINCS+ 7,856 to 49,856). openquantumsafe.org
3. Lombrozo, Lau & Wuille. BIP 141: Segregated Witness (the weight formula and witness discount). bitcoin/bips/bip-0141
4. Beast, Heilman & Foster. BIP-360: Pay-to-Merkle-Root (P2MR), originally drafted as P2QRH. bip360.org
5. Note — weight vs. serialized size. BTQ’s only consensus limit on block size is weight: CheckBlock enforces GetBlockWeight() ≤ MAX_BLOCK_WEIGHT (8,000,000), while MAX_BLOCK_SERIALIZED_SIZE (8 MB) bounds only P2P messages and the block-assembly target, not block validity (validation.h, consensus.h). Because weight = 15 × (non-witness size) + (total size), weight reaches its cap before serialized size does for any transaction that carries non-witness data, so weight — not the 8 MB figure — is the binding constraint. A weight-full block of ordinary two-input Dilithium payments holds ~800 transactions and is ~6.1 MB on disk (~8.8 GB/day); the 8 MB block and ~11.5 GB/day figures are the asymptotic ceiling, approached only by witness-dominated blocks where non-witness data is negligible. The Bitcoin and BTQ columns above are stated as this serialized ceiling and computed the same way, so the comparison is like-for-like. The per-block transaction counts elsewhere in this guide are likewise size-based; the weight-bound counts are somewhat lower.