BTQ vs Bitcoin
BTQ compared to Bitcoin: Dilithium signatures, 1-minute blocks, 8MB block weight, and a 5 BTQ reward, with the same 21 million supply cap.
BTQ vs Bitcoin
This page provides a single, authoritative reference for every meaningful difference between BTQ and Bitcoin. If you understand Bitcoin, this page tells you exactly what BTQ changes and what it keeps the same.
At a Glance
BTQ is a fork of Bitcoin Core that replaces ECDSA signatures with quantum-resistant Dilithium signatures. Most of Bitcoin's architecture is preserved unchanged. The modifications fall into three categories: cryptographic upgrades, capacity adjustments to accommodate larger signatures, and timing/economic rebalancing.
Cryptography
| Property | Bitcoin | BTQ | Notes |
|---|---|---|---|
| Signature algorithm | ECDSA (secp256k1) | Dilithium2 (ML-DSA-44) | BTQ also supports ECDSA for backward compatibility |
| Signature size | ~71 bytes | 2,420 bytes | 34x larger |
| Public key size | 33 bytes (compressed) | 1,312 bytes | 40x larger |
| Private key size | 32 bytes | 2,560 bytes | 80x larger |
| Quantum resistant (signatures) | No | Yes | Dilithium is resistant to Shor's algorithm |
| Security basis | Elliptic Curve Discrete Log | Module Learning with Errors (MLWE) | Fundamentally different mathematical problems |
| NIST standard | FIPS 186-4 | FIPS 204 | Both are NIST standardized |
| Verification speed | ~2 ms | ~1.5 ms | Dilithium is faster to verify |
| Signing speed | ~0.5 ms | ~3 ms | Dilithium is slower to sign |
| Key generation speed | ~0.1 ms | ~2 ms | Dilithium is slower to generate |
| Hash function (PoW) | SHA-256 | SHA-256 | Unchanged |
| Address hashing | SHA-256 + RIPEMD-160 | SHA-256 + RIPEMD-160 | Unchanged |
Block Parameters
| Property | Bitcoin | BTQ | Notes |
|---|---|---|---|
| Block time target | 10 minutes | 1 minute | 10x faster confirmations |
| Max block size (serialized) | 1,000,000 bytes | 8,000,000 bytes | 8x larger to accommodate Dilithium transactions |
| Max block weight | 4,000,000 WU | 8,000,000 WU | Increased proportionally |
| Witness scale factor | 4 | 16 | Stronger discount for witness data |
| Max sigops per block | 20,000 | 80,000 | Increased for Dilithium verification |
| Difficulty retarget interval | 2,016 blocks (~2 weeks) | 20,160 blocks (~2 weeks) | Same wall-clock period, 10x more blocks |
| Coinbase maturity | 100 blocks (~16.7 hours) | 100 blocks (~1.67 hours) | Same block count, shorter wall-clock time |
Economic Model
| Property | Bitcoin | BTQ | Notes |
|---|---|---|---|
| Total supply | 21,000,000 BTC | 21,000,000 BTQ | Identical cap |
| Initial block reward | 50 BTC | 5 BTQ | 1/10th reward, 10x more blocks |
| Halving interval | 210,000 blocks (~4 years) | 2,100,000 blocks (~4 years) | Same wall-clock cadence |
| Emission curve shape | Geometric decay | Geometric decay | Mathematically identical |
| Inflation rate at any time | X% | X% | Same rate at equivalent points in the emission schedule |
| Fee pricing | By weight | By weight | Same mechanism |
The economic equivalence is exact: 10 times more blocks at 1/10th the reward produces the same total supply, the same halving timeline, and the same inflation rate at every point in time.
Transaction Sizes
| Transaction Type | Bitcoin (ECDSA) | BTQ (Dilithium) | Ratio |
|---|---|---|---|
| Signature | ~71 bytes | 2,421 bytes (including sighash byte) | ~34x |
| Public key | 33 bytes | 1,312 bytes | ~40x |
| Typical 1-input, 2-output tx | ~250 bytes | ~3,800 bytes | ~15x |
| Transactions per block (approx.) | ~4,000 | ~1,400 | ~0.35x per block |
| Transactions per second | ~6.7 | ~24 | ~3.6x (due to 1-min blocks) |
Despite larger individual transactions, the combination of 8 MB blocks and 1-minute block times gives BTQ roughly 3.6x higher overall throughput than Bitcoin. The per-block count is limited by block weight (not raw byte size) because of the witness discount.
Address Formats
Mainnet forms shown.
| Type | Bitcoin | BTQ |
|---|---|---|
| Legacy (ECDSA) | 1... (P2PKH) | X... (Base58 v75) |
| Script (ECDSA) | 3... (P2SH) | w... (Base58 v135) |
| SegWit (Bech32) | bc1q... | qbtc1q... |
| Taproot (Bech32m) | bc1p... | qbtc1p... |
| Dilithium (P2MR) | N/A | qbtc1z... (witness v2) |
| Legacy Dilithium | N/A | X... (Base58 v76) — historical |
Dilithium lives in exactly one current address type: P2MR. The witness-version character does the
distinguishing — 1z for Dilithium versus 1q/1p for ECDSA.
BTQ's Base58 prefixes do not cleanly separate ECDSA from Dilithium: mainnet version bytes 75
and 76 both render as X…. Use the isdilithium field from validateaddress to determine the
type — see Dilithium Addresses.
Network Identity
| Property | Bitcoin | BTQ |
|---|---|---|
| Network magic bytes | 0xF9BEB4D9 | 0xF1B2A3D4 |
| Default P2P port | 8333 | 9333 |
| Testnet P2P port | 18333 | 19333 |
| Regtest P2P port | 18444 | 19444 |
| Bech32 HRP (mainnet) | bc | qbtc |
| Bech32 HRP (testnet) | tb | tbtq |
| Client identifier | "Satoshi" | "BTQ" |
| Genesis block hash | 0x000000000019d6... | 0x0000ca45ea0843... |
| Genesis timestamp | Jan 3, 2009 | Feb 23, 2026 |
| Genesis coinbase message | "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" | "BTQ genesis remine: quantum-safe launch baseline, 26/Feb/2026" |
The block header timestamp (
nTime = 1771804800, Feb 23) and the date embedded in the coinbase message (26/Feb/2026) are separate fields. The header timestamp is the consensus timestamp used by the protocol; the coinbase message is a human-readable string stored in the generation transaction and has no protocol significance.
Distinct magic bytes and ports ensure that BTQ and Bitcoin nodes never accidentally connect to each other.
Script System
| Property | Bitcoin | BTQ |
|---|---|---|
| Standard opcodes | All Bitcoin opcodes | All Bitcoin opcodes (inherited) |
| Dilithium verification | N/A | OP_CHECKSIGDILITHIUM |
| Dilithium verify-and-continue | N/A | OP_CHECKSIGDILITHIUMVERIFY |
| Dilithium pubkey marker | N/A | OP_DILITHIUM_PUBKEY |
| Max script element size | 520 bytes | 15,000 bytes |
| Max script size | 10,000 bytes | 100,000 bytes |
| Auto-detection | N/A | Public key size > 100 bytes triggers Dilithium verification |
The increased script size limits are necessary because Dilithium public keys (1,312 bytes) and signatures (2,420 bytes) exceed Bitcoin's original limits.
What Stayed the Same
The following components are identical to Bitcoin and were intentionally left unchanged:
| Component | Why It Was Kept |
|---|---|
| SHA-256 double-hash PoW | Proven, 128-bit post-quantum security, existing ASIC ecosystem |
| UTXO transaction model | Simpler to audit than account-based models, well-understood |
| P2P gossip protocol | Robust, decentralized message propagation |
| Block header structure | 80-byte headers, Merkle tree, standard Bitcoin format |
| RPC interface | Familiar tooling for developers and operators |
| Wallet encryption | AES-256-CBC, same as Bitcoin |
| BIP-143 sighash | SegWit transaction signing format |
What Changed and Why
| Change | Reason | Design Doc |
|---|---|---|
| Dilithium signatures | Quantum resistance (Shor's algorithm defense) | Design Rationale |
| 8 MB blocks | Accommodate 15x larger transactions | Scalability |
| 1-minute blocks | Faster confirmations, better UX | Design Rationale |
| 5 BTQ block reward | Maintain 21M supply with 10x more blocks | Network Economics |
| 2,100,000-block halving | Same ~4-year cadence with 1-minute blocks | Network Economics |
| 16x witness discount | Incentivize witness-based Dilithium transactions | Scalability |
| New address prefixes | Distinguish BTQ addresses from Bitcoin | Dilithium Addresses |
| New opcodes | Verify Dilithium signatures in scripts | Dilithium Signatures |
| Larger script limits | Dilithium keys/sigs exceed original limits | Dilithium Signatures |
Migration from Bitcoin
For users familiar with Bitcoin, moving to BTQ involves:
- Building or obtaining BTQ Core -- same build process as Bitcoin Core
- Creating a wallet -- same RPC commands and workflow
- Generating a Dilithium address -- one additional RPC command
- Sending and receiving -- same transaction flow, larger transactions are handled transparently
- Mining -- same SHA-256 hardware, different port and network
The learning curve is minimal because BTQ deliberately preserves Bitcoin's operational model. The primary difference is using Dilithium-specific RPC commands for quantum-resistant address generation and transaction signing.
Learn More
- What is BTQ? - Introduction to the project
- Design Rationale - Why each change was made
- Network Economics - Economic model details
- Security Model - Threat analysis