Scalability & Performance
How BTQ handles larger post-quantum transactions at scale
Scalability & Performance
Post-quantum signatures are significantly larger than their classical counterparts. This page analyzes how BTQ's protocol parameters work together to maintain practical throughput, manage storage growth, and keep verification efficient despite the increased data sizes.
The Core Challenge
Replacing ECDSA with Dilithium increases the size of every transaction:
| Component | ECDSA (Bitcoin) | Dilithium (BTQ) | Increase |
|---|---|---|---|
| Signature | ~71 bytes | 2,420 bytes | 34x |
| Public key | 33 bytes | 1,312 bytes | 40x |
| Typical transaction | ~250 bytes | ~3,800 bytes | 15x |
A naive approach -- simply dropping Dilithium into Bitcoin's existing parameters -- would reduce throughput to a fraction of Bitcoin's already modest capacity. BTQ addresses this through a combination of larger blocks, faster block times, and an aggressive witness discount.
Block Capacity
Raw Capacity
BTQ's maximum block size is 8 MB (8,000,000 bytes serialized), compared to Bitcoin's 1 MB. This provides 8 times the raw byte capacity per block.
Effective Transaction Count
The actual number of transactions per block is limited by block weight, not raw byte size. With BTQ's witness scale factor of 16, a typical Dilithium transaction has a weight of approximately 5,550 weight units (113 bytes of non-witness data at 16 WU each, plus ~3,742 bytes of witness data at 1 WU each).
| Metric | Bitcoin (1 MB, ECDSA) | BTQ (8 MB, Dilithium) |
|---|---|---|
| Typical tx size | ~250 bytes | ~3,800 bytes |
| Typical tx weight | ~560 WU | ~5,550 WU |
| Transactions per block | ~4,000 | ~1,400 |
| Block time | 10 minutes | 1 minute |
| Transactions per hour | ~24,000 | ~84,000 |
Despite each transaction being 15x larger, the combination of 8 MB blocks and 1-minute block times means BTQ processes roughly 3.5x more transactions per hour than Bitcoin.
The per-block transaction count is lower than Bitcoin's, but the per-hour throughput is significantly higher due to 1-minute blocks. For user experience, what matters is how quickly transactions confirm, not how many fit in a single block.
Throughput Analysis
Transactions Per Second
| Network | Tx per block | Block time | Tx per second |
|---|---|---|---|
| Bitcoin | ~4,000 | 600 sec | ~6.7 |
| BTQ (Dilithium) | ~1,400 | 60 sec | ~24 |
| BTQ (ECDSA, if used) | ~14,000 | 60 sec | ~233 |
BTQ's theoretical Dilithium throughput of ~24 transactions per second is roughly 3.5x Bitcoin's throughput. The actual throughput depends on the mix of transaction types and sizes.
Confirmation Latency
For end users, the most important metric is how long they wait for a transaction to be confirmed:
| Confirmation Level | Bitcoin | BTQ | Speedup |
|---|---|---|---|
| First confirmation | ~10 min | ~1 min | 10x |
| 3 confirmations | ~30 min | ~3 min | 10x |
| 6 confirmations | ~60 min | ~6 min | 10x |
This 10x improvement in confirmation latency makes BTQ significantly more practical for everyday transactions.
The Witness Discount
How It Works
BTQ uses a witness scale factor of 16. When calculating a transaction's weight (which determines its share of block capacity and its fee), witness data is counted at 1/16th of its actual byte size.
For a typical Dilithium transaction:
| Data Category | Raw Size | Weight Contribution |
|---|---|---|
| Non-witness data (inputs, outputs, metadata) | ~100 bytes | 100 weight units |
| Witness data (signature + public key) | ~3,700 bytes | ~231 weight units |
| Total | ~3,800 bytes | ~331 weight units |
Without the discount, the same transaction would weigh ~3,800 weight units, consuming over 10x more block capacity.
Why It Matters
The witness discount creates two critical incentives:
1. UTXO set health: The UTXO set is the collection of all unspent transaction outputs that nodes must keep in memory for fast validation. Witness data is NOT part of the UTXO set -- it is prunable after validation. By making witness data cheap, the protocol encourages transaction formats that keep large Dilithium keys and signatures out of the permanent UTXO set.
2. Practical fees: Without the discount, fees for Dilithium transactions would be proportional to their full ~3,800-byte size. The discount brings fees down to a level comparable to what users expect, making the network economically viable.
Comparison of Witness Scale Factors
The witness discount determines how much cheaper witness-format transactions are compared to legacy (non-witness) transactions. Higher scale factors create stronger incentives to use witness formats, which keeps large Dilithium data in the prunable witness section:
| Factor | Legacy Dilithium tx/block | Witness Dilithium tx/block | Incentive ratio |
|---|---|---|---|
| 1 (no discount) | ~2,075 | ~2,075 | 1x (no incentive) |
| 4 (Bitcoin's factor) | ~519 | ~1,907 | 3.7x cheaper to use witness |
| 16 (BTQ's factor) | ~130 | ~1,441 | 11x cheaper to use witness |
BTQ's 16x factor is larger than Bitcoin's 4x factor because Dilithium signatures are proportionally much larger than ECDSA signatures relative to the non-witness data. The stronger discount is necessary to make witness-format Dilithium transactions economically viable.
Verification Performance
One of Dilithium's advantages over ECDSA is faster verification:
| Operation | ECDSA | Dilithium | Comparison |
|---|---|---|---|
| Key generation | ~0.1 ms | ~2 ms | Dilithium slower (done once) |
| Signing | ~0.5 ms | ~3 ms | Dilithium slower (done once per tx) |
| Verification | ~2 ms | ~1.5 ms | Dilithium faster |
Verification is the operation that matters most for network scalability because every node must verify every transaction in every block. A block with 2,100 Dilithium transactions requires roughly 3.15 seconds of verification time, compared to 8 seconds for 4,000 ECDSA transactions in a Bitcoin block. Verification is not the bottleneck.
Dilithium's faster verification partially compensates for its larger data size. The network spends less CPU time per transaction on signature verification than Bitcoin does, even though each transaction carries more data.
Bandwidth Considerations
Per-Block Bandwidth
| Network | Max block size | Block interval | Peak bandwidth |
|---|---|---|---|
| Bitcoin | 1 MB | 10 min | ~1.7 KB/sec |
| BTQ | 8 MB | 1 min | ~133 KB/sec |
BTQ requires roughly 80x more bandwidth than Bitcoin at peak capacity. This is within the capabilities of modern internet connections but is a meaningful increase. Node operators should have at least a few megabits per second of bandwidth available.
Compact Block Relay
Like Bitcoin, BTQ uses compact block relay to reduce bandwidth during normal operation. Instead of transmitting full blocks, nodes exchange block headers and short transaction identifiers, reconstructing the block from transactions already in the mempool. This dramatically reduces actual bandwidth usage below the theoretical maximum.
Storage Requirements
Blockchain Growth
| Network | Block size | Block interval | Daily growth | Annual growth |
|---|---|---|---|---|
| Bitcoin | ~1 MB avg | 10 min | ~144 MB | ~52 GB |
| BTQ (full blocks) | ~8 MB max | 1 min | ~11.5 GB | ~4.2 TB |
At full capacity, BTQ's blockchain grows significantly faster than Bitcoin's. However:
- Pruned nodes can discard old block data, keeping only the UTXO set and recent blocks
- Witness data (the largest component) is prunable, with the witness discount encouraging its use
- Average block utilization is typically well below the maximum, especially in early network life
UTXO Set Size
The UTXO set grows based on the number of unspent outputs, not on transaction or block size. Because Dilithium public keys are stored as 20-byte hashes in the UTXO set (not as full 1,312-byte keys), UTXO set growth is comparable to Bitcoin's despite larger transactions.
This is a direct result of the witness-based transaction format: the large data lives in the witness (prunable) while the UTXO set stores only compact hashes.
Future Optimizations
ML-DSA Tapscript (BIP360)
The v2 roadmap includes migrating Dilithium verification into Tapscript leaves, following the BIP360 proposal. This would further reduce the on-chain footprint by leveraging Taproot's key-path/script-path structure and placing all post-quantum data in witness space by default.
UTXO Consolidation
Mining pools that accumulate many small UTXOs can consolidate them during periods of low network activity. With 1-minute blocks, there are more opportunities for low-priority consolidation transactions to be included in blocks.
Signature Aggregation
Research into aggregating multiple Dilithium signatures into a single proof is ongoing in the cryptographic community. If practical aggregation schemes emerge, they could significantly reduce the per-transaction overhead for multi-input transactions.
Summary
| Challenge | BTQ's Solution |
|---|---|
| 15x larger transactions | 8 MB blocks + 1-minute block times |
| UTXO set growth | 16x witness discount, hash-based UTXO entries |
| Verification overhead | Dilithium verifies faster than ECDSA |
| Bandwidth requirements | Compact block relay, pruning support |
| Storage growth | Pruned nodes, witness data is discardable |
| Fee pressure | Witness discount keeps fees practical |
Learn More
- Design Rationale - Why these capacity parameters were chosen
- BTQ vs Bitcoin - Side-by-side parameter comparison
- Network Economics - Fee market and mining economics
- Transaction Lifecycle - How transactions flow through the network