Common questions about why INTcoin is built on post-quantum cryptography and what that actually means in practice. The longer-form motivation lives in “Why post-quantum cryptography matters for cryptocurrency”; this thread is the FAQ for specific technical questions.
Q: When are quantum computers actually a threat?
A: No one can put a date on it with confidence. The honest answer is somewhere between “never” and “within 20 years” depending on which research direction you find most credible. What’s certain: cryptographic primitives have a long migration tail — the legacy you’re protecting today will still need to be recoverable in 30 years’ time, and a chain whose entire signature surface is ECDSA will be retroactively un-securable the day a sufficiently large quantum computer exists. INTcoin’s design assumes that day comes within the network’s operational lifetime.
Q: What primitives does INTcoin use?
A: Three NIST-standardised post-quantum primitives:
- ML-DSA-87 (Dilithium5) — signature scheme. Replaces ECDSA. Signs every transaction.
- ML-KEM-1024 (Kyber1024) — key encapsulation mechanism. Used by the V2 P2P transport for handshake key exchange. Replaces ECDH.
- SHA3-256 — cryptographic hash. Used in HD-wallet derivation and address generation. Coexists with SHA-256 (which is used for block hashing — RandomX includes a SHA-256 step).
All three are FIPS-approved final standards as of 2024 (NIST FIPS 203 / 204).
Q: Why ML-DSA-87 instead of SPHINCS+ or XMSS?
A: Tradeoffs.
- SPHINCS+ is hash-based and has the strongest security assumptions (no algebraic structure to attack), but signatures are 8–50 KB and signing is slow. Unworkable for a high-throughput chain.
- XMSS and other stateful hash-based schemes require the signer to track state across signatures — a lost or rolled-back state file means catastrophic key reuse. Not safe for non-expert users.
- ML-DSA-87 signs in milliseconds, has 4627-byte signatures (large but tractable), and has no state requirement. It’s the practical choice for a UTXO chain.
INTcoin chose the highest-security parameter set (level 5) because signatures are stored on-chain forever — if level 5 is later found to be necessary, we don’t want to be forced into a flag-day migration.
Q: How big are signatures and keys?
A: Compared to ECDSA:
| ECDSA (Bitcoin) | ML-DSA-87 (INTcoin) | Ratio | |
|---|---|---|---|
| Public key | 33 bytes | 2,592 bytes | ~78x |
| Signature | 71 bytes | 4,627 bytes | ~65x |
| Secret key | 32 bytes | 4,896 bytes | ~153x |
This is the cost of post-quantum security. Block size is correspondingly larger (transactions take more bytes), which constrains throughput vs Bitcoin at the same blocksize-budget. We’ve sized INTcoin’s block weight target accordingly.
Q: What’s a “V2 transport” and why does it matter?
A: Every P2P connection between INTcoin nodes is encrypted using ML-KEM-1024 + ChaCha20-Poly1305. There’s no V1 (unencrypted) fallback. This protects:
- Transaction privacy in transit — nobody on the path between nodes can see which transactions you’re broadcasting.
- Eclipse-attack resistance — an attacker can’t forge messages from peers they’re not actually talking to.
- Forward secrecy — even if a node’s long-term key is later compromised, past sessions stay private.
Bitcoin Core uses an analogous design (BIP-324 / V2 transport), but it’s optional and based on ECDH. INTcoin’s V2 transport is mandatory and post-quantum.
Q: What about coins protected by ECDSA on other chains?
A: Coins on Bitcoin / Ethereum / etc. that have exposed their public key on-chain (any address that has ever sent a transaction) are vulnerable the moment a sufficiently large quantum computer exists. Coins sitting in addresses that have only received (never sent) are temporarily protected by SHA-256 + RIPEMD-160 hashing — the public key isn’t on-chain yet — but spending them later requires revealing the public key, opening the same attack window.
INTcoin sidesteps this entirely: the public key format is post-quantum from genesis. There’s no “upgrade path” needed for existing UTXOs because there’s no legacy ECDSA layer.
Q: Can I bridge from Bitcoin / use atomic swaps?
A: Not currently. A cross-chain atomic swap with Bitcoin requires both chains’ script engines to verify the same hashlock, which is straightforward — but the signatures on each side use the chain’s native primitive. So Bitcoin-side coins are protected by ECDSA (vulnerable), INTcoin-side coins by ML-DSA-87 (not). The swap mechanism works; the resulting holdings on Bitcoin side carry the legacy risk.
When Lightning Network ships on INTcoin (separate roadmap item), it will only interop with other ML-DSA-87 chains — Bitcoin Lightning channels can’t open against INTcoin Lightning channels because the signature schemes are incompatible.
Q: Is RandomX (the proof-of-work algorithm) quantum-resistant?
A: Quantum computers don’t break hashing-based PoW the same way they break public-key cryptography. Grover’s algorithm gives a quadratic speedup over brute-force preimage search — meaning a quantum miner could find blocks ~2x faster (in operations) than a classical miner of equivalent gate count. The economics work the same as classical mining: difficulty adjusts, network finds equilibrium. There’s no “quantum break” of SHA3 / RandomX in the way there is for ECDSA. PoW is fine.
Q: What if ML-DSA-87 itself gets broken later?
A: Defence in depth. The IIP system is designed for this case: if a future cryptanalysis weakens ML-DSA-87, an IIP would specify migration to a different scheme (likely SPHINCS+ or a future NIST standard), and addresses would migrate as users move funds. Coins sitting in pre-migration addresses would be at risk only after publication of an attack with practical complexity — historically this has been a multi-year window even for severe breaks.
Realistically: the closest attack we know of against ML-DSA is generic Grover-on-SHAKE in the parameter set’s security argument, which gives ~2^192 operations against the level-5 set. Useful as a planning concern, not as an active threat.
More questions?
Post in this category, #general on Discord, or open a #blockchain Discord thread for deeper technical discussion. The wider design rationale is in the INTcoin developer docs under CRYPTOGRAPHY.md.