Design Rationale

BTQ is not simply "Bitcoin with bigger signatures." Every change from the original Bitcoin protocol was driven by a specific engineering constraint or security requirement. This page explains the why behind BTQ's design.

Why BTQ Exists

The cryptographic community has known for decades that quantum computers will eventually break elliptic curve cryptography. NIST began its Post-Quantum Cryptography standardization process in 2016, and in 2024 published final standards including FIPS 204 (Dilithium/ML-DSA) for digital signatures.

Despite this, no major proof-of-work blockchain has shipped a production-ready post-quantum signature system. The gap between knowing the threat exists and having a working, deployed solution is where BTQ operates. BTQ demonstrates that quantum-resistant cryptography can be integrated into a Bitcoin-class blockchain today, not at some unspecified future date.

Novel Problems BTQ Solves

Replacing ECDSA with Dilithium is not a drop-in substitution. Dilithium signatures are 34 times larger than ECDSA signatures, and public keys are 40 times larger. This creates a cascade of engineering challenges that BTQ addresses:

Fitting Post-Quantum Signatures into a Blockchain

A single Dilithium transaction consumes roughly 3,800 bytes compared to about 250 bytes for an ECDSA transaction. If the block size remained at Bitcoin's 1 MB, the network could process only a fraction of the transactions it handles today. BTQ increases the maximum block size to 8 MB to maintain reasonable throughput despite larger transaction sizes.

Keeping the UTXO Set Manageable

In Bitcoin's design, the UTXO (Unspent Transaction Output) set must be kept in memory for fast validation. If large Dilithium public keys and signatures were stored directly in UTXO-creating script outputs, the UTXO set would grow unsustainably fast. BTQ solves this by placing signatures and public keys in witness data, which is prunable and does not permanently reside in the UTXO set. The witness discount incentivizes this behavior economically.

Maintaining Verification Performance

Despite larger data sizes, Dilithium2 signature verification is actually faster than ECDSA verification (~1.5 ms vs ~2 ms on modern hardware). This means that while transactions are larger in bytes, they do not create a verification bottleneck. The network can validate blocks at least as quickly as Bitcoin.

Backward Compatibility

BTQ supports both ECDSA and Dilithium signatures simultaneously. The script interpreter uses auto-detection based on public key size to determine which verification algorithm to use. This allows a smooth migration path: users can move funds from ECDSA addresses to Dilithium addresses at their own pace rather than being forced into an immediate, disruptive transition.

Why Fork Bitcoin?

BTQ is built on Bitcoin Core rather than written from scratch. This decision was deliberate:

Building from scratch would mean re-implementing (and re-auditing) years of security-critical infrastructure. By forking Bitcoin Core, BTQ inherits all of that work and focuses engineering effort on the cryptographic upgrade itself.

Why Dilithium2?

NIST's post-quantum standardization process evaluated dozens of candidate algorithms over seven years. Three signature schemes were selected for standardization:

BTQ chose Dilithium2 (NIST Security Level 2, 128-bit quantum security) because:

• NIST's primary recommendation for general-purpose digital signatures
• Implementation simplicity reduces the attack surface in security-critical code
• Strong side-channel resistance is important for software running on diverse hardware
• Reasonable signature size balances security with practical blockchain constraints
• Fast verification keeps block validation efficient

Level 2 provides 128 bits of quantum security, which is considered sufficient for the foreseeable future and matches the effective post-quantum security of SHA-256.

Why Keep SHA-256 Proof of Work?

Quantum computers threaten SHA-256 mining through Grover's algorithm, which provides a quadratic speedup for brute-force search. However, this is far less severe than Shor's attack on signatures:

• SHA-256 has 256 bits of classical security
• Grover's algorithm reduces this to 128 bits of quantum security
• 128-bit security remains far beyond any practical attack

Additionally:

• No quantum mining hardware exists or is on any near-term roadmap
• SHA-256 ASICs represent billions of dollars of deployed infrastructure that can secure the BTQ network
• The hash function can be upgraded later if quantum mining ever becomes a real concern, without the urgency that signatures demand

The signature vulnerability is existential (your funds can be stolen). The mining vulnerability is economic (a quantum miner has an advantage). Solving the existential threat first is the correct priority.

Why 1-Minute Blocks?

BTQ targets 1-minute block times instead of Bitcoin's 10 minutes. This provides:

• 10x faster initial confirmations for a better user experience
• More granular difficulty adjustment with retargeting every 20,160 blocks (~2 weeks)
• Better UTXO consolidation for mining operations dealing with larger Dilithium transactions

The economic model compensates for faster blocks: the block reward is 5 BTQ (one-tenth of Bitcoin's initial 50 BTC), and the halving interval is 2,100,000 blocks (ten times Bitcoin's 210,000). This produces an identical emission curve to Bitcoin, with the same 21 million total supply and the same approximately 4-year halving cadence.

Why 8 MB Blocks?

With Dilithium transactions approximately 15 times larger than ECDSA transactions, the block size must increase to maintain reasonable throughput:

The 8 MB limit, combined with a 16x witness scale factor, keeps throughput in a usable range while giving nodes adequate time to validate and propagate blocks.

Why the Witness Discount?

BTQ uses a witness scale factor of 16, meaning witness data (where Dilithium signatures and public keys reside) is counted at 1/16th of its actual size for block weight calculations. This creates two important incentives:

1. UTXO set health: Users are economically motivated to use witness-based transaction formats, keeping large cryptographic data out of the permanent UTXO set
2. Pruning efficiency: Witness data can be discarded by pruned nodes, reducing long-term storage requirements

Without the witness discount, Dilithium transactions would be prohibitively expensive relative to their on-chain footprint, and the UTXO set would grow at an unsustainable rate.

The Auto-Detection Approach

Rather than requiring all transactions to use Dilithium immediately, BTQ's script interpreter detects the signature type automatically based on public key size. Keys larger than 100 bytes are treated as Dilithium; smaller keys use ECDSA.

This design choice enables:

• Gradual migration from ECDSA to Dilithium addresses
• Backward compatibility with existing Bitcoin transaction patterns
• Testing flexibility during the transition period

Future Direction: ML-DSA Tapscript

The current Dilithium integration uses custom opcodes in the script system. The v2 design roadmap envisions a cleaner approach using ML-DSA verification within Tapscript (following the BIP360 proposal). This would:

• Remove custom opcodes in favor of Bitcoin's existing Taproot upgrade mechanism
• Place all post-quantum signature data exclusively in witness space
• Minimize divergence from Bitcoin Core, making future rebases easier
• Enable more advanced scripting capabilities with post-quantum security

This evolution represents BTQ's commitment to staying aligned with the broader Bitcoin development ecosystem while maintaining quantum resistance.

Learn More

• BTQ vs Bitcoin - Comprehensive parameter comparison
• Network Economics - Emission schedule and fee market
• Security Model - Threat analysis and defense layers
• Scalability & Performance - Throughput and capacity analysis