(Written by grok)
Hi Tari community,
With 2026 now being widely called the “Year of Quantum Security” (NIST, CISA, and industry coalitions are pushing hard for PQC migration timelines), I wanted to open a constructive discussion about the quantum threat to Tari (Minotari L1) and how we might proactively upgrade the protocol while preserving its core strengths: extreme privacy and Mimblewimble scalability.
1. Why Tari is vulnerable (quick principle recap)
Tari is built on Mimblewimble, which relies heavily on:
- Pedersen commitments (
C = rG + vH) for hidden amounts - Schnorr signatures on transaction kernels
- Bulletproofs (or Bulletproofs+) for range proofs
All of these rest on the elliptic curve discrete logarithm problem (ECDLP). A sufficiently powerful quantum computer running Shor’s algorithm can solve ECDLP in polynomial time. The practical consequence is that the computational binding of Pedersen commitments breaks: anyone could re-open any existing UTXO commitment to an arbitrary new amount v' and spend it with a valid kernel signature. This would allow inflation, theft of any UTXO, and destruction of monetary integrity.
Bulletproofs’ soundness and Schnorr security would also collapse under the same attack. (This is the same risk facing Bitcoin, Grin, Beam, and every ECC-based chain.)
Important: Tari currently has no public RFCs, GitHub issues, or roadmap items addressing post-quantum cryptography (PQC). Searches across rfc.tari.com, the tari-project GitHub repo, and this forum turn up zero results for “quantum”, “post-quantum”, “PQC”, “Dilithium”, “STARKs”, etc.
2. A realistic, privacy-preserving upgrade path (my proposed sketch)
We don’t need to panic, but we should start planning now — similar to how Bitcoin and especially Monero are already moving.
Core principles for any Tari PQC upgrade:
- Keep Mimblewimble’s perfect privacy (hidden amounts, no addresses, full anonymity set)
- Minimize disruption to existing users and miners
- Use mature NIST PQC standards + quantum-safe ZK
Concrete phased proposal (inspired by Monero’s Jamtis/FCMP++ work and Bitcoin’s emerging PQC discussions):
-
Phase 1 – Soft Fork (allow new transaction types)
Introduce new address formats and transaction kernels that use:- PQC signatures: CRYSTALS-Dilithium (ML-DSA) or Falcon (fast & compact)
- Post-quantum commitments: lattice-based or hash-based commitments that still support homomorphic addition (so transaction balance validation still works)
- Post-quantum range/membership proofs: STARKs (naturally quantum-resistant, transparent, no trusted setup)
Old Mimblewimble transactions remain fully valid forever (or for a long sunset period).
-
Phase 2 – Optional ZK Migration Window (6–18 months)
Users prove ownership of old UTXOs via a quantum-safe zero-knowledge proof (STARK-based) that they know the blinding factorr(without revealing it).
The protocol then creates a new PQC-style commitment and moves the funds to a quantum-safe UTXO.
This is exactly the pattern Monero is exploring with Jamtis + STARK-like proofs for their own PQC transition. -
Phase 3 (optional) – Eventually raise fees or deprecate old kernels after the migration window, but only if community consensus supports it.
This approach means:
- Historical transactions are not suddenly invalidated
- Privacy is fully preserved during migration
- Tari’s L2 digital-asset features can be carried forward unchanged
- We stay compatible with existing PoW mining hardware
3. Why now?
- Monero Research Lab already has active post-quantum work (FCMP++ live in Q1 2026, Jamtis with PQ encryption options like CSIDH).
- Bitcoin developers are discussing STARK-aggregated PQC signatures and soft-fork paths.
- NIST and governments are setting 2030–2035 deadlines for critical systems. (Probably 2029 by Google)
Tari’s small, focused, privacy-first community is actually in a great position to design this cleanly — we don’t have the legacy baggage of larger chains.
Call to action
I’d love to hear your thoughts:
- Is this threat on anyone’s radar already?
- Would you support starting an official RFC for a “Post-Quantum Mimblewimble” upgrade?
- Any preferred PQC primitives (Dilithium vs Falcon vs hash-based, STARKs vs other ZK)?
- Developers or researchers interested in collaborating?
I’m happy to help draft the first RFC or prototype some of the migration proof ideas. Let’s turn this into a community-driven strength rather than a future vulnerability.
Looking forward to a productive discussion!