The 15x Problem

A typical Bitcoin transaction with one input and two outputs (a payment and change) is roughly 250 bytes. The same transaction signed with Dilithium2 is approximately 3,824 bytes — about 15 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. A Dilithium witness stack contains a 2,421-byte signature (2,420 bytes plus one byte for the sighash type) and a 1,312-byte public key. Compare this to ECDSA’s ~72-byte signature and 33-byte compressed public key. The transaction header, input outpoints, and output scripts remain largely the same size — it is purely the authentication data that 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. There is no known post-quantum scheme that matches ECDSA’s compactness. The question is not whether transactions get larger, but how to absorb that 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 when accounting for the SegWit witness discount. With 250-byte ECDSA transactions, this fits approximately 16,000 transactions per block.

With 3,824-byte Dilithium transactions, the same 4 MB block fits approximately 1,050 transactions — a 15x reduction in throughput at the same block size. To maintain even Bitcoin’s current transaction throughput (which is already considered low), you need larger blocks.

The BTQ project increased MAX_BLOCK_SERIALIZED_SIZE to 8 MB and MAX_BLOCK_WEIGHT to 8,000,000 weight units. Even with this increase, a full block holds only about 2,100 Dilithium transactions — roughly 13% of what Bitcoin processes per block. The sigops limit was doubled to 80,000 to accommodate the validation cost of the larger signatures.

Additional protocol limits also needed adjustment: the MAX_SCRIPT_ELEMENT_SIZE was raised from 520 bytes to 15,000 bytes (to fit Dilithium5 signatures plus keys on the stack), the MAX_SCRIPT_SIZE was raised to 100,000 bytes (for complex multi-sig scripts), and the MAX_PROTOCOL_MESSAGE_LENGTH was increased 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 incentivizes transactions that use more prunable witness space relative to permanent UTXO space.

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

The BTQ project initially disabled the witness discount (setting weight equal to serialized size) for simplicity, but community analysis quickly identified the consequences. Without the discount, full blocks would generate ~75 GB per day of permanent UTXO set growth at the increased block size — a rate that would make running a full node impractical within weeks.

The solution adopted was to restore and increase the witness scale factor to 16 (from Bitcoin’s 4), meaning witness data counts at 1/16 weight. This stronger discount reflects the reality that in a Dilithium world, an even larger proportion of each transaction is prunable witness data. The per-input witness overhead (3,733 bytes) at 1/16 weight costs only ~233 weight units — comparable to the ~26 weight units for ECDSA’s ~105-byte witness at Bitcoin’s 1/4 discount.

Chain Growth and Node Viability

Chain growth rate determines who can run a full node — the foundation of Bitcoin’s decentralization. The calculations are straightforward:

These numbers assume full blocks, which is a worst-case scenario for a young network. In practice, BTQ blocks are far from full during the bootstrapping phase. But the limits matter because they define the maximum stress the network can sustain — and an attacker with sufficient funds could fill blocks to this level.

The chain growth rate is manageable with modern hardware (a 4 TB SSD can store roughly a year of full-block data), but it represents a meaningful increase over Bitcoin’s current ~600 MB/day. This is an inherent cost of quantum resistance: larger signatures mean more data, regardless of how you structure the blocks. The design goal is to keep this cost within the range of commodity hardware, not to eliminate it.

Emission Schedule and Block Timing

Block timing interacts with the emission schedule in ways that are easy to get wrong. The BTQ project 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 15x transaction size increase.

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

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

Getting these parameters right is critical. Errors in the emission schedule affect miner incentives, supply dynamics, and network security. During BTQ’s development, community review identified a mismatch where block timing was set to 10 minutes but the halving interval assumed 1-minute blocks — which would have produced ~40-year halvings. This was caught and corrected before mainnet deployment, illustrating why public code review matters for consensus-critical parameters.

No Free Lunch

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

Every proposed solution to Bitcoin’s quantum vulnerability faces this same constraint. BIP-360’s P2QRH addresses will 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.

What projects like BTQ provide is a live dataset for evaluating these tradeoffs. When chain growth calculations are theoretical, they can be dismissed. When they come from a running chain processing real transactions, they become harder to ignore — and easier to use as the basis for informed protocol design decisions.