Update — New Telegram ChannelsWe've migrated our Telegram presence to new channels for better organization and security.
Community: t.me/dilithion_orgNews & Announcements: t.me/dilithion_newsThe previous Telegram group is no longer active. Please update your bookmarks and only use the links above.
Discord remains unchanged:
Discord
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.
Block time ~4 minutes , 360 blocks per day
The first block has been found Jan 28, 2026
Today is March 23 and 34,516 blocks
34516 blocks for 55 days that's 560 blocks a day
If there is no EDA in the code, you will get into a loop.
Great job my friends.
Re: Block timing — 560 vs 360 blocks/day
Good catch on the numbers. The explanation is the difficulty adjustment algorithm used during that period.
For blocks 0–23,039, Dilithion used periodic retargeting (adjusting every 2,016 blocks, similar to Bitcoin's original approach). During that phase, if hashrate was growing — which it was, since the network was attracting new miners — blocks would arrive faster than the 4-minute target until the next retarget window.
At block 23,040, we activated ASERT (Absolutely Scheduled Exponential Rising Targets) — a per-block difficulty adjustment algorithm based on Bitcoin Cash's aserti3-2d. With ASERT, difficulty adjusts every single block using an exponential formula with a 34,560-second halflife (~9.6 hours). This means the chain self-corrects much faster and converges tightly toward the 4-minute target regardless of hashrate fluctuations.
Since ASERT activation, block times have been tracking the target closely. The early over-production is a one-time artifact of the pre-ASERT phase — it doesn't compound going forward.
From a technical standpoint, Dilithion is notable not merely for integrating a post-quantum signature scheme, but for adopting a **native post-quantum cryptographic stack**, where Dilithium (ML-DSA) is used as the primary signing primitive at the protocol level.
Unlike many “quantum-resistant” projects that retrofit existing UTXO or account models with an alternative signature algorithm while retaining legacy assumptions, Dilithion’s design reflects a more holistic approach:
* **Signature layer:** ML-DSA (Dilithium) as the default authentication mechanism
* **System design:** Built with post-quantum threat models in mind rather than retrofitting classical ECDSA-based architectures
* **Security posture:** Focus on resisting quantum adversaries at the cryptographic primitive level, rather than relying on incremental hardening of existing schemes
In contrast, a number of other implementations labeled as “quantum-resistant” typically:
* Preserve legacy consensus and transaction models with minimal modification
* Introduce post-quantum signatures in isolation, without re-evaluating broader protocol assumptions
* Remain dependent on classical cryptographic components that are not quantum-secure by design
As a result, these approaches can be better characterized as **hybrid or transitional architectures**, rather than fully post-quantum-native systems.
Dilithion’s approach represents a stricter interpretation of post-quantum design principles, though it also implies increased experimental complexity and a smaller security assurance base compared to long-established classical systems.
hi tom
thats interesting that dillithion uses the legacy, simplified and predictable model of utxo for quantum resistance (:
Re: UTXO model
"Legacy" is one way to frame it — "battle-tested for 17 years across $2T in value" is another.
The UTXO model was a deliberate choice for post-quantum security, not a shortcut. Here's why:
In UTXO, each output is spent exactly once, and the public key only needs to be revealed at spending time. Once spent, that key is never reused. This is ideal for post-quantum cryptography because even if a quantum computer could eventually break a revealed public key, the window of exposure is minimal.
Account-based models (Ethereum-style) keep a persistent public key on-chain tied to your account for every transaction. That's a larger and longer-lived attack surface for quantum adversaries.
UTXO is simpler, yes — and that's a feature when you're building a foundation that needs to survive decades of cryptographic evolution. Complexity is where vulnerabilities hide.
Hi. Your target is almost there. I think when wallets are hacked en masse, then everyone will understand the value of your project)) It's time to make a miner and launch a pool. Good luck.
Thanks for the support. You make a fair point about urgency — the quantum threat timeline keeps getting shorter (Google's own target is 2029 for quantum migration).
On mining pools — it's something we've considered carefully. The challenge is that Dilithion uses Digital DNA fingerprinting to ensure one-miner-one-vote fairness. A traditional pool where one operator submits blocks on behalf of many miners would undermine that design goal. We're exploring pool architectures that could work within these constraints, but for now solo CPU mining is the intended approach — and it's deliberately accessible (any modern CPU can mine, no ASICs or GPUs needed).
