Security Analysis
Tidecoin’s security is layered. No single primitive protects the whole system. Transaction authorization depends on post-quantum signatures; wallet derivation depends on PQHD seed secrecy; script hashing depends on HASH160, SHA-256, and SHA-512 depending on output type; proof-of-work depends on the active mining phase; peer privacy depends on encrypted transport; and implementation safety depends on careful key handling and validation.
This page states the threat model and boundaries. It is not an audit report and not a guarantee that every implementation bug has been found. For normative consensus rules, see Consensus Rules.
Threat model
| Threat | Tidecoin design response |
|---|---|
| Quantum key recovery against ECDSA/Schnorr | Tidecoin does not use ECDSA or Schnorr for transaction signatures. |
| Harvest-now-decrypt-later against exposed classical public keys | Falcon-512 has been used from genesis for transaction signatures. |
| Need for future cryptographic agility | Falcon-1024 and ML-DSA-44/65/87 are implemented and height-gated for post-AuxPoW activation. |
| Public derivation leakage from xpub-style wallets | PQHD is hardened-only and does not expose BIP32-style non-hardened public derivation. |
| Weak script-hash margin under Grover’s algorithm | Witness v1 P2WSH-512 uses 64-byte SHA-512 script hashes after AuxPoW activation. |
| Quantum-vulnerable P2P key exchange | V2 transport uses ML-KEM-512 instead of elliptic-curve key exchange. |
| Small-chain standalone PoW attacks | AuxPoW path is built for scrypt merged mining with Litecoin-scale parent work. |
Signature security
| Scheme family | Tidecoin role | Security basis | Main boundary |
|---|---|---|---|
| Falcon-512 | Live mainnet transaction signatures | SIS over NTRU lattices in the quantum random oracle model | Category 1 target; compact but implementation-sensitive. |
| Falcon-1024 | Built for post-AuxPoW cryptographic agility | Same family at higher parameter set | Not active on mainnet before AuxPoW. |
| ML-DSA-44/65/87 | Built for post-AuxPoW cryptographic agility | Module-LWE and Module-SIS lattice assumptions | Larger signatures and public keys. |
The practical signature boundary is the scheme registry and activation gate. Before AuxPoW activation, Falcon-512 is the only consensus-allowed scheme. At and after AuxPoW activation, the node may accept the broader scheme set under strict verification rules.
Hash security
| Component | Hashing used | Security note |
|---|---|---|
| Legacy key-hash addresses | HASH160 | Compatibility surface; public-key exposure and address reuse should still be minimized. |
| Witness v0 script hash | SHA-256 | Bitcoin-compatible witness v0 behavior. |
| Witness v1 P2WSH-512 | SHA-512 | 64-byte script hash for stronger post-quantum preimage margin. |
| P2P transport key derivation | HKDF-SHA256 | Derives transport keys from ML-KEM shared secret and network-specific salt. |
| PQHD derivation | HMAC-SHA512 and SHA-256 domain-separated components | Hardened-only wallet derivation. |
Hash functions are less directly affected by quantum computers than elliptic-curve signatures. Grover’s algorithm gives a quadratic search speedup, which is why SHA-512 is used for the higher-margin witness v1 script-hash path.
Proof-of-work security
| Phase | Work source | Security goal | Main limitation |
|---|---|---|---|
| Pre-AuxPoW | YespowerTIDE | CPU-accessible launch mining and memory-hard standalone PoW | A small standalone chain can have limited economic hashpower. |
| Post-AuxPoW | Scrypt parent proof through AuxPoW | Inherit security from a larger scrypt mining base | Requires pool/miner adoption and correct AuxPoW integration. |
The scrypt merged-mining path is designed to raise both the economic cost of attack and the implementation cost of a quantum PoW oracle. This does not make proof-of-work immune to economic attack. It makes the relevant attack target the live scrypt merged-mining ecosystem rather than only Tidecoin’s standalone hashpower.
Transport security
Tidecoin v2 transport uses ML-KEM-512 to establish a 32-byte shared secret, then derives encrypted packet keys from that secret. The transport protects relay privacy against passive observation and plaintext message classification. It does not hide confirmed blockchain data, and it does not prevent a peer that receives a transaction from learning that transaction.
The important quantum boundary is key exchange. A recorded elliptic-curve transport handshake could become decryptable to a future Shor-capable adversary. ML-KEM avoids that specific failure mode.
Wallet and key-management security
PQHD removes BIP32-style non-hardened public derivation. That matters because post-quantum signature schemes do not support the same safe homomorphic public derivation pattern as secp256k1 BIP32, and exposed public derivation material should not become a substitute private key.
Operationally, the main wallet risks remain ordinary but serious:
| Risk | Mitigation |
|---|---|
| Seed loss | Back up the wallet seed and verify recovery. |
| Seed theft | Encrypt wallets, use offline signing for large balances, and limit hot-wallet exposure. |
| Address misuse | Avoid assuming all address formats have the same activation or spending rules. |
| Scheme confusion | Treat the scheme prefix as part of the serialized public key and validate against the scheme registry. |
Implementation safety
The codebase uses several defensive patterns around sensitive material:
| Area | Practice |
|---|---|
| Secret cleanup | Secret material is cleansed after use where wrappers own the data. |
| Sensitive storage | Secure allocators are used for private key material. |
| Object lifetime | Sensitive KEM keypair wrappers use RAII cleanup and delete copy/move operations. |
| Deterministic derivation | PQHD uses domain-separated derivation and deterministic retry behavior for scheme key generation. |
| Verification dispatch | Public-key prefixes select known schemes through a compile-time registry. |
These practices reduce risk; they do not replace external review, fuzzing, reproducible builds, or conservative release engineering.
Remaining risks
| Risk | Status |
|---|---|
| Unknown cryptanalysis of lattice schemes | Mitigated by NIST-vetted schemes and cryptographic agility, not eliminated. |
| Implementation side channels | Reduced by clean implementations and integer-emulated Falcon paths; still requires platform review. |
| RNG failure | Critical for key generation and signing; wallet and system entropy must be protected. |
| Consensus bugs | Mitigated by Bitcoin Core heritage and tests; any consensus change still requires careful review. |
| Low adoption of merged mining | AuxPoW code alone does not provide security unless miners and pools actually participate. |
| User operational mistakes | Backups, offline signing, and clear wallet UX remain essential. |
Source of truth
| Topic | Source |
|---|---|
| Scheme registry and activation gate | ../tidecoin/src/pq/pq_scheme.h |
| Falcon and ML-DSA implementations | ../tidecoin/src/pq/ |
| PQHD design | ../tidecoin/doc/design/pqhd.md, ../tidecoin/src/pq/pqhd_* |
| Script and witness security rules | ../tidecoin/src/script/interpreter.h, ../tidecoin/src/script/interpreter.cpp |
| Proof-of-work and AuxPoW | ../tidecoin/src/pow.cpp, ../tidecoin/src/auxpow.cpp, ../tidecoin/src/validation.cpp |
| P2P transport | ../tidecoin/src/bip324_pq.*, ../tidecoin/src/net.* |
| Whitepaper security analysis | ../tidecoin/doc/whitepaper.md |
See also: Design Positioning, P2P Transport, Proof-of-Work, PQHD, Verification Modes.