Jason just released a developer preview of “Quantumroot” - which if I’m reading it right means BCH can start building quantum resistant vaults (at very impressive levels of economic efficiency / low fees) into all wallets after the 2026 upgrade (provided all relevant upgrades lock in).
Would be amazing if BCH is already rolling out quantum resistant protection options & tooling by the end of next year. I think that should put us nicely ahead of the game & hopefully attract industry attention to our innovations.
I’m sure he’ll jump in with his own comments at some point.
Jameson Lopp’s proposed under-development Quantum BIP.
The proposal is to announce a sunset date at which non-quantum coins become unspendable, rather than letting a quantum attacker grab them and dump. But this by default burns all coins of anyone who doesn’t migrate to the quantum version in the meantime (Satoshi, people not following things closely etc.).
Interesting take on it.
Hunter Beast has published his proposal “Hourglass” in a draft format. The idea is to limit P2PK spends (ie Satoshi & other early coins, 1.7m total) to 1 output per block. This would slow down quantum harvesting of those coins to take nearly a year, instead of happening potentially within just a few hours.
The only downside is that it essentially deprecates P2PK, but that’s already been dead for years.
Seems like an excellent proposal to me at first consideration.
As BCH has no issue with hardforks, we could even consider a variant of this like limiting the P2PK spend to only once every X blocks (like once per 10) to slow things down further, although that might introduce mining games since there would possibly be a huge benefit to reorging that “special” block which harvests the 50 BCH from early P2PK addresses.
Edit: this proposal has anti-synergy with 1 minute blocks, which would again speed up the release of such coins (although it would be slower than without any hourglass).
Edit 2: A good counterargument by Jameson Lopp:
I think this could benefit from a lot more blockchain analysis in order to support the claim that it will reduce economic volatility. On its surface it feels like a half measure.
Sure, requiring P2PK output spends to be spread out over a year /could/ slow down the /tail end/ of said economic volatility. This is assuming that post-QDay, the machines doing the cracking can crack a key in less than 10 minutes.
However, a rational quantum adversary will seek to maximize their revenue. For example, the most valuable likely lost funds are 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr which has 31,000 BTC spread across only a handful of UTXOs. It’s not a P2PK address, but a P2PKH with an exposed pubkey due to address re-use. Even if this proposal is implemented we can still expect massive economic volatility at the front-end of the quantum era. Even if this proposal was extended to INCLUDE spends from re-used addresses, that would be 31,000 BTC in an hour or two.
Moving on to P2PK specifically, I’d expect a similar issue of front-loaded volatility once a quantum adversary runs through the high value reused addresses that haven’t migrated to a quantum safe scheme. Take, for example, James Howells’ funds at 198aMn6ZYAczwrE5NvNTUMyJ5qkfy4g3Hi - 8,000 BTC spread out across just 16 UTXOs, which would be spendable in a 3 hour timeframe in this proposal.
Quantum has been a huge topic of FUD/discussion the last couple of weeks. Nic Carter having a big meltdown over the whole thing (his published articles and research were fairly quality, but his discussion and debate on the issue afterwards was just appalling).
https://x.com/nic_carter/status/2002223319022776605
https://x.com/TheBCHPodcast/status/2003308460046451034
Also, BIP 360 guys have added Isabel Foxen Duke (who followed me on Twitter after I brought up the BCH quantum solutions) as a co-editor and reworked their proposal. Their current idea seems to be just adding a new Taproot Script Hash P2TSH, which is kinda quantum resistant or fixes the Taproot bug but doesn’t sound like it really addresses the issue entirely and is more of a “first step”. They won’t even get anywhere near shipping that, but I’m surprised to see them make such a weak attempt in the first place. Anyway, they’ll learn one day.
We are in a good position with Quantumroot. I expect first wallets to become available end of 2026 or in 2027. Currently, QCs can’t do anything, threat is still hypothetical. Still, the fear of QCs is real and can strain people psychologically. Having a plan for q-day will help that, so here’s a plan.
There’s been a lot of fear about quantum computers threatening Bitcoin Cash. Let’s cut through the noise and look at what we can actually do.
The Good News First
Quantum computers aren’t magic. According to Google’s own research paper:
- Cracking one key would take ~9 minutes (30 min for 100% success)
- Cracking enough keys to access 1 million BCH would take ~125 days minimum
- Cost: hundreds of millions to billions of dollars
- That’s almost as slow as it took to originally mine them (~194 days)
This isn’t a switch that gets flipped and suddenly someone owns all the old coins. It would be an expensive, slow process where attackers compete with each other and have to sell at prices that recoup their costs.
The Plan: Commit-Delay-Reveal
Here’s a scheme that would protect real owners without freezing or stealing anyone’s coins.
How it would work:
-
Commit: Publish a hash of your intended transaction. This reveals nothing about your keys. It just says “I plan to move these coins.”
-
Delay: Wait for the commitment to age (say, a few months to a year).
-
Reveal: Broadcast your actual transaction. The network checks that it matches your earlier commitment.
Why this protects real owners:
- Oldest commitment wins. If you committed before an attacker cracked your key, you win automatically.
- Attackers face uncertainty. Even if they crack a key, they don’t know if the real owner already has an older commitment waiting. They could spend billions cracking keys only to get front-run.
- No coins get frozen or burned. The rule just requires a commitment before spending. Everyone plays by the same rules.
This would work for ALL coin types: P2PK (like Satoshi’s coins) and P2PKH alike. The only requirement is that real owners commit before attackers do.
How We Get There
The technical path is straightforward:
- Spec out the OP_CHECKSIG overload to require a pre-commitment as part of signature validation
- Implement and test the upgrade
- Activate via network upgrade when ready, or keep it dormant until QCs actually arrive
Once the spec is finalized, users would be able to start publishing commitments immediately. The “delay” period starts counting from when you commit, so early adopters get maximum protection.
If quantum computers never materialize, no harm done. The commitments just sit there unused. If they do arrive, everyone who committed early is protected.
This is a solvable problem on a relatively quick timeframe. We don’t need to panic, and we definitely don’t need to freeze anyone’s coins.
The Three Types of Coins
P2PK (Pay to Public Key): ~1.7 million BCH including Satoshi’s coins. The public key is directly visible on-chain, so attackers could start working on these before any spend attempt. But with commit-delay-reveal, real owners would protect themselves by committing early. Oldest commitment wins.
P2PKH (Pay to Public Key Hash): The public key is only revealed when you spend. If you’ve never spent from an address, attackers don’t even know which key to crack. Commit-delay-reveal would add another layer: even if your key gets exposed and cracked later, your earlier commitment wins.
New coins going forward: Quantumroot vaults become available after May 15, 2026. Full quantum resistance using only SHA256. Problem solved for anyone who uses them.
What About Satoshi’s Coins?
Once the commit-delay-reveal spec is live, Satoshi (or any P2PK holder) could publish a commitment. If he does before QCs arrive, he’s protected. His aged commitment would beat any attacker who cracks the key later.
If he doesn’t, well, he’s had 15+ years to move those coins and hasn’t. At some point we have to accept that either:
- He lost his keys
- He’s deliberately leaving them as a QC bounty
- He won’t bother to publish a simple commitment
- He’s no longer alive
Whatever the reason, it’s not our place to interpret his intentions or “protect” coins he chose not to protect himself. The locking script is a contract. With commit-delay-reveal, the rule becomes: whoever has the oldest valid commitment gets the coins. Fair and simple.
Burning or freezing coins would be theft dressed up as protection. We’d be stealing from Satoshi (or his heirs, or his intended beneficiaries) to protect our bags from a hypothetical liquidity event.
BCH doesn’t do that.
What You Can Do Today
-
Stop reusing addresses. Every time you spend, your public key is revealed. Fresh addresses give you better privacy anyway.
-
Move to Quantumroot when wallet support arrives (late 2026 - 2027). This gives you full quantum resistance going forward.
-
Watch for the commit-delay-reveal spec. When it’s finalized, commit your old coins early. Oldest commitment wins.
-
Don’t panic. The timeline for cryptographically relevant quantum computers is likely 2030s at earliest. We have time to prepare.
Why Not Just Freeze the Old Coins?
Some people are pushing for blanket freezing or burning of “vulnerable” coins. This is wrong for several reasons:
It’s theft. You’re taking someone’s coins without their consent. Doesn’t matter if you call it “protection.”
It sets a deadly precedent. Once developers can freeze coins “for the greater good,” where does it stop? Dormant coins today, “criminal” coins tomorrow, sanctioned addresses next week.
It’s unnecessary. Commit-delay-reveal would protect everyone who bothers to use it. If you don’t protect your own coins when given an easy way to do so, that’s on you.
BCH survived worse. The chain absorbed millions of coins being dumped by BTC maxis after the fork. Someone bought them. Life went on.
The Bottom Line
BCH has a clear path forward:
- Quantumroot for new coins (available May 2026)
- Commit-delay-reveal to protect existing coins (spec it out, flip the switch when needed)
- No freezing, no burning, no theft
This is a solvable problem. The technical work is straightforward. Real owners who publish commitments early would be protected. Those who don’t, after years of warning, have made their choice.
Anyone pushing for blanket freezing while ignoring these solutions is either uninformed or has an agenda. Now you know the difference.
Hi everyone,
I’ve been working on a small proof-of-concept and wanted to share it here in this thread because I am unsure if this idea warrants it’s own thread of discussion.
The project is a hybrid key generation tool that produces realistic secp256k1 private keys while also generating linked SPHINCS+ (SLH-DSA) material. It also creates two address formats from the same underlying data, one using a standard double-SHA256 checksum and another using double-SHAKE256.
It is primarily a wallet-level tooling experiment focused on key derivation and address generation. This is quite different from Quantumroot, which focuses on efficient on-chain quantum-secure vaults using smart contracts and CashTokens.
I’ve put the code and documentation on GitHub here:
- Repository: https://github.com/DigiMancer3D/sphincs_bch_hybrid
- Usage guide: https://github.com/DigiMancer3D/sphincs_bch_hybrid/blob/main/USAGE.md
I would really appreciate any feedback, especially regarding the hybrid construction. Fair context: the dual-checksum address approach shows the difference between the two approaches. I’m still early in this work but may still be helpful.
Best regards,
DigiMancer3D
Cool! How would this map to on-chain contracts? Why the need for SHAKE256? Can you tell us more about SPHINC+, I’m interested in whether it would be possible to implement SPHINCS+ in Script using native OP_SHA256 and loops and functions?
The method I used could potentially allow for the original contract tx data to be used as entropy data then your contract/message/payload is handled normally at that point. When I use this similar setup with Tapleaf I use a ringCT method of proof then relay on each singer involved to have a copy of the hidden offchain or public onchain contract data as entropy. Unsure if that would be same as you asked about mapping contracts. But I would have a previous commitment proof and tx on-chain. The SPHINCS+ key is the private key to spend after an upgrade is made to have SPHINCS+ keys or if the 93-105 byte hybrid signature capable of being forked into use. SPHINCS+ (SLH-DSA) is a stateless hash based PQC. I don’t have the communication skills to explain this further other then the generic process of what it kinda does, sorry I do not normally submit things. I play with hashes as a hobby and have used other state-based cryptographies including inventing my own for fun mostly. But I noticed SPHINCS+ (SLH-DSA) has a setup that is controllable by using a parameter file you can essentially control the length value output then if an upgrade to this form of full PQC was made to the chain then people could just change the parameters and continue on with full SPHINCS+ PQC, or at least that is the idea. Shake256 or the double-shake256 even are both common post-quantum methods, I believe they help hide secrets better then sponge or scrapping (in my opinion). As for you question on implementing SPHINCS+ for script using native OP_SHA256, with the hybrid signature this would probably be possible, I don’t personally know as much about script op_sha256 but perhaps wrapping payloads with SPHINCS+ you could could potentially start to get somewhere. we would have to use the double-sha256 checksum instead of a double-shake256 but outside that I would need to look more into OP_SHA256. I have some attempts on github already playing with PQC for wrappers and with tapleaf but nothing I would be willing to officially bring to the table besides this one being referenced.
I don’t know why you’d need that, what does a SPHINCS+ signature sign? Isn’t it some sighash just the same? On BCH VM you have loops, functions and introspection opcodes so you can just generate the sighash you need in Script (similar functionality as BTC’s proposed CHECKTEMPLATEVERIFY).
We may even activate a dedicated OP_SIGHASH.
So really, if OP_SHA256 can work as the building block, with loops and functions I think a SPHINCS+ implementation should be able to fit in a contract. VM limits are a problem, max. stack item size is 10kB which limits the signature size one could use.
Really good new interview about Quantum, covering lots of the general quantum innovation, timelines, and impact on Bitcoin systems specifically.
Welcome to BCH research!
You say this is primarily wallet-level tooling. Would this allow us to generate quantum secure addresses instead of regular ones as part of Selene Wallet?
Found a nice post: Are we overthinking post-quantum cryptography? – Neil Madden
tl;dr: The author argues we’re over-engineering post‑quantum cryptography. Instead of replacing every classical algorithm, we should take a minimal step: deploy hybrid post‑quantum encryption only (for confidentiality against store‑now‑decrypt‑later), keep classical signatures for authentication, and rely on static, large public‑key schemes like Classic McEliece whose small ciphertexts (96–208 bytes) make them far more practical for existing protocols (JWTs, cookies, etc.) than the bulky NIST‑standardised lattice‑based options. That alone addresses the most pressing threat without the size‑blowup of PQ signatures.
There’s a nice chart showing the current state of things and how far we are from cracking public key encryption, reproducing it here:
Since we don’t have any consensus-layer encryption/confidentiality then first steps would be to implement PQC in RPAs and CashFusion.
On the RPA part, I was looking into this for a while. PQ fund security ≠ PQ private transactions. If ECDH stays, users may as well run Quantumroot alone and skip the stealth layer as there are two distinct surfaces:
Surface A: the signature that authorizes spending a UTXO.
Surface B: the key agreement that lets a sender create a one-time output only the recipient can detect and unlock.
Quantumroot solves A. Hash-based signatures (LM-OTS, SHA256), with post-quantum spend authorization. Excellent. However it does not touch B. RPA stealth derivation is ECDH, a NIKE (non-interactive key exchange): sender and receiver land on the same shared secret from each other’s pubkeys alone. The ephemeral pubkey lives on chain.
Hash cannot replace ECDH here. ECDH works on group math: aB = bA. SHA256 has no such property AFAIK. SHA256(a||B) is unrelated to SHA256(b||A). LM-OTS, XMSS, SLH-DSA are signatures, not key encapsulation. They authenticate, they do not establish shared secrets between parties who only know each other’s pubkeys. That is exactly why Quantumroot is used for spending and spending here needs authentication, not key agreement.
So Surface B needs PQ key agreement, and replacing Non-Interactive Key Exchange (NIKE) is hard. No practical lattice NIKE ships (SWOOSH is paper-only). Two options available here:
-
Key Encapsulation Mechanism - KEM (ML-KEM-768). it posts a ciphertext (~1088 bytes) instead of an ephemeral pubkey, recipient decapsulates and it cost one ciphertext per recipient. The addressing cost is just placement: on BCH the ciphertext rides in the token commitment of the P2S Quantumroot output it’s on-chain and bound to the output. <<<< @Bastian made transaction using ML-KEM-768 on chipnet.
-
PQ NIKE. Almost none exist. Only real candidate is CSIDH, isogeny commutative group action, near drop-in for classical DH but the tradeoff is that it’s slow to compute, and the code nowhere near as battle-tested as ML-KEM.
Tevador Jamtis PQ proposal (Monero research-lab issue 151) chewed through this exact NIKE vs KEM question for stealth addressing. They dropped lattice KEMs (Kyber/ML-KEM, NTRU) for CSIDH. Not on security. A KEM needs one ciphertext per output and cannot rerandomize a pubkey, which kills unlinkable address generation from a watch-only tier, and lattice addresses blow past 1300 chars. CSIDH keeps the NIKE properties small.
The attack that matters for RPA is that when cryptographically relevant qc arrives, they can recover Bob scan private key and recompute every ECDH shared secret from every ephemeral pubkey ever posted to him. Every past stealth payment becomes linkable to Bob. Funds wrapped in Quantumroot cannot be stolen, but the privacy graph collapses retroactively. Forward secrecy of the addressing layer is gone, so if ECDH breaks in 10-20 years, can a passive observer link every past stealth output Bob received? If yes, Quantumroot did not save the privacy aspect of RPA.
Quantumroot is the spend half. The privacy half needs PQ key agreement replacing ECDH at Surface B. The fork from ECDH is either KEM such as (ML-KEM-768) or PQ NIKE (CSIDH). One of those two + Quantumroot vault closes both surfaces: quantum-resistant funds AND quantum-resistant addressing privacy.
Refs:
maybe the pq solution is as simple as migrating away from key based authorization?
quantumroot is the safeguard for legacy key based auth. p2s and proof based authorizations can be developed for post quantum. this is possible and happening right now today.
Quantumroot is still a key-based authorization under the hood, it’s just that you make the signature once in a TX and reference as many dependent UTXOs as you want, and it’s just that the signature is OTS so you have to rotate the key on the authentication NFT. But the same scheme can work with plain P2PKH on the authorization NFT, and other inputs requiring the NFT just the same and being part of this vault smart contract structure.
This is why I think we should overload OP_CHECKSIG and OP_CHECKDATASIG with some QC-proof signing scheme(s), so I will support Pat’s CHIP and I hope we can at least activate SPHINCS+ in May 2027.
The CHIP creates a framework to support multiple signing schemes, so any later CHIPs would only have to discuss which scheme to add and why.