4 MB blocks + 4 min block time + 3.3 KB signatures
That means like:
727 tx per block
3 TPS
526 GB chain growth per year, around 1.5 GB per day
You built a slow, bloated, storage-eating brick with a NIST buzzword taped to it.
P.s. Why did your AI tool remove merkle duplicate-tx check from code? That opens a double-spend attack vector
Re: Chain growth and merkle duplicate-tx check
Appreciate the scrutiny — this is exactly the kind of analysis that makes projects better. Let me address both points with the actual numbers from the code.
Chain growth:
Your math assumes 4 MB blocks, but the consensus-enforced limit is 1 MB (MAX_BLOCK_SIZE = 1,000,000 in src/consensus/params.h). The 4 MB value in chainparams is a network relay parameter, not the consensus block size limit. So the corrected math:
Typical transaction (1-in, 1-out with Dilithium sig): ~3,400 bytes
Max transactions per 1 MB block: ~294
At 360 blocks/day: ~106K tx/day capacity, ~1.2 TPS theoretical max
Max chain growth at 100% full blocks: ~128 GB/year
But that's the theoretical ceiling. In practice, current blocks are nearly empty — mostly just the coinbase transaction. Actual chain growth right now is a fraction of that. For context, Bitcoin's chain is ~600 GB after 15 years.
Is 1.2 TPS a lot? No — and it's not trying to be. DIL is the store-of-value chain. DilV (45-second blocks, higher throughput) handles everyday transactions. The dual-chain design is specifically so DIL doesn't need to compromise security for speed.
The larger signature size is a real trade-off of post-quantum cryptography — Dilithium3 signatures are 3,309 bytes vs ~72 bytes for ECDSA. That's the cost of quantum resistance. Every PQC project will face this. We chose to accept it rather than pretend quantum computers aren't coming.
Merkle duplicate-tx check (CVE-2012-2459):
Dilithion is protected against this. The duplicate transaction check is implemented in CheckBlock() (src/consensus/validation.cpp, lines 577-586) — every transaction hash is checked against a set, and any block containing duplicate transactions is rejected before merkle root verification even runs.
You may be referring to commit b550dd3 where we removed a redundant check inside the merkle tree builder that was incorrectly rejecting valid orphan blocks (BUG #49). The protection wasn't removed — it was moved to the correct layer. Block validation rejects duplicates; the merkle function just builds the tree. This is the same separation of concerns Bitcoin Core uses.
Happy to discuss further — the code is all open source if you want to verify.
