Can an upgrade make BTC's Taproot quantum secure? No – not without confiscating BTC from users. These aren't ancient, "abandoned" addresses either. BTC confiscations could hit holders who moved funds as recently as today.

Post-quantum vaults are now live on Bitcoin Cash's Chipnet, the 6-month-early preview network. 🔥 CashVM makes quantum readiness ultra-efficient: sweeps from quantum-ready addresses cut transaction sizes vs. P2PKH/P2WPKH by up to 10.9%, despite the increase from 20-byte hashes to 32-byte hashes (for highest-level, NIST Category 5 quantum security strength). Users who regularly buy or earn Bitcoin Cash to a Quantumroot vault will save on fees after just 6 payments. 🚀 Maximum Quantum Security With NIST Post-Quantum Cryptography Category 5 security, Quantumroot is expected to remain secure for decades into the post-quantum era. Quantumroot implements the standard LM-OTS signature scheme (RFC 8554), which itself relies only on SHA256 for security – no lattice-based or other relatively-experimental cryptography. From a cryptographic-security perspective, Quantumroot is maximally conservative. Low Transaction Fees Bitcoin Cash's highly parallel architecture – the "UTXO model" – offers better performance and lower-level control than account-based systems, enabling Quantumroot to offer 100-1000× lower fees than equivalent vaults on Ethereum. Privacy Nonces Pre-quantum transactions do not expose associations between vault addresses: a 32-byte privacy nonce included in the hidden token-based spending path prevents even quantum attackers from connecting the address with recovery policies unless revealed by a post-quantum recovery. Sweep-Free Upgrades The hidden recovery path can be upgraded without sweeping the vault: only unassociated token UTXOs are moved on-chain. This simplifies user experiences and makes it easier for vaults to upgrade recovery, inheritance, or business continuity policies. Other details: - Post-quantum contract code adds zero bytes to pre-quantum spends. - On average, post-quantum spends are just ~1.5KB per payment. (With sufficient aggregation, ZK-STARK BCH covenants/apps could improve this further.) - P2PKH addresses can support 708 input sweeps per 100KB transaction; Quantumroot increases that to 891 inputs. - Post-quantum sweeps can fit 868 inputs or 448 unique addresses per 100KB transaction. For more details and links to on-chain transactions, see the blog post: blog.bitjson.com/quantumroot… For a deep dive and walkthrough of the CashVM contracts, see the August 20 tech talk: youtube.com/watch?v=OjS539Ud…

The May 2026 upgrade is now active on Chipnet at block 279,792! 🎉 This upgrade completes the restoration of Bitcoin Script on Bitcoin Cash (CashVM), making CashVM a simple, ultra-efficient, high-level programming environment for sound money. Left: 2016 opcodes, right: 2026 opcodes 🔥 (source: vm.cash) Over the last decade, Bitcoin Cash has delivered: • 2018: Opcode restoration (OP_CAT, OP_XOR, OP_DIV, OP_MOD, etc.), • 2019: Schnorr signatures with multisig batch verification, • 2020: Density-based signature limits, • 2022: OP_MUL and introspection, • 2023: Cross-covenant commitments (CashTokens), • 2025: Density-based general limits and BigInts, • 2026: Loops, functions, bitwise, and Pay-2-Script. Each upgrade carefully preserved Bitcoin Cash's transaction-level parallelization, enabling global-scale, layer-1 throughput – without compromising Bitcoin Cash's scalability, decentralization, and censorship-resistance. Fully-validating, archival BCH nodes run on consumer hardware and still outperform clusters of high-powered, centralized sequencers required by account-based networks. With this upgrade, CashVM becomes even more powerful, allowing contract developers to efficiently implement post-quantum cryptography, homomorphic encryption, zero-knowledge proof systems, and more – without waiting for network upgrades. Case Study: Quantumroot Quantumroot is a quantum-secure vault contract design offering full 256-bit classical, 128-bit quantum security strength. Possible since May 2025, but made 10-100× more efficient by the 2026 upgrade: Quantumroot sweep transactions are 15% smaller per-UTXO than P2PKH wallets. Upgrade Details The 2026 upgrade includes four Bitcoin Cash Improvement Proposals (CHIPs): Loops CHIP Introduces the well-established, OP_BEGIN/OP_UNTIL loop construction to CashVM, bounded by the density-based limits activated in the 2025 upgrade. Loops eliminate duplication in repeated procedures, significantly reducing transaction sizes and enabling previously impractical constructions. Functions CHIP Enables factoring of contract bytecode into reusable functions with OP_DEFINE/OP_INVOKE, eliminating duplicated logic and reducing transaction sizes. Functions improve the efficiency of complex financial and cryptographic computations, including zero-knowledge proof verification, homomorphic encryption, post-quantum cryptography, and more. Bitwise CHIP Re-enables bitwise operations, including OP_INVERT for bit inversion, arithmetic shifts (OP_LSHIFTNUM and OP_RSHIFTNUM) for numeric values, and binary/logical shifts (OP_LSHIFTBIN and OP_RSHIFTBIN) for binary data. These operations allow CashVM contracts to more efficiently implement a variety of financial and cryptographic algorithms. Pay-2-Script CHIP Makes Pay-2-Script (P2S) outputs standard, enables longer token commitments (up to 128 bytes), and unifies the standard unlocking bytecode length limit with the consensus limit (10,000 bytes). These changes improve wallet ecosystem safety, simplify contract design, and reduce transaction sizes for many vault, multi-party covenant, and decentralized financial applications.Technical Specs For more details, see the CHIPs: - Loops: github.com/bitjson/bch-loops - Functions: github.com/bitjson/bch-funct… - Bitwise: github.com/bitjson/bch-bitwi… - Pay-2-Script: github.com/bitjson/bch-p2s

Chipnet upgrade in ~6 hours 🚀

10⁸th is just-verify-a-ZKP territory, but lower numbers are reasonable for toy VM comparisons. First take: a simple, single input (<10KB) computation can get to the 5334th Fibonacci number (1,115 decimal digits) in 2026 CashVM. L1 fee ~0.0001 BCH (script, metrics):

Bitcoin Cash opcodes active since 2009 vs. today + 2026 CHIPs:

Just made this quick opcode reference for Bitcoin Cash's virtual machine (CashVM): shows descriptions for each opcode and quick links to relevant technical specs.

Resharing Q&A from a dev team: "what is the status of Bitcoin Cash in terms of Bitcoin Script and the latest Bitcoin soft forks? SegWit, Taproot?" Me: BCH is computationally equivalent to ETH now, but BCH has significantly higher compute limits and lower fees. As of May 2025, almost anything can be compiled or ported to CashVM, and by May 2026, CashVM will effectively be a high-level language: arbitrary precision math, loops, functions, etc. In general, you can do anything with ECDSA-like compute density (CPU-per-byte) up to 100KB of code/data (in standard transactions, 1MB nonstandard). Pay for a bigger transaction, get more compute. (Re 2026 upgrade: many BCH stakeholders have already published lock-in approval statements – one of the 4 CHIPs had some contention earlier, but the disputing stakeholders have now endorsed that CHIP too. At this point, probably only discovery of an unfixable flaw would delay any of the 2026 CHIPs. Note that Nov 15 is the lock-in date + "chipnet" 6-month-early network upgrade, so after Nov 15, we'll be certain about which CHIPs are going into the May 2026 BCH upgrade.) For a demo, here's the LM-OTS post-quantum signature scheme implemented precisely according to RFC 8554 (NIST adopted) in pure Bitcoin (Cash) Script: blog.bitjson.com/quantumroot…. It's >2x more byte efficient than the WASM equivalent (I'll share more comparing them later) And performance wise, this is an example that e.g. is not possible to build on Solana. I wrote a bit more about that here: bitcoincashresearch.org/t/ch…, but TLDR: Solana's compute limits are too low per-byte + Solana's maximum transaction size is too small. BCH transaction validation is "embarrassingly parallel" to an absurd degree, so we were able to clean up the limits over the past few years to actually reduce the worst case validation performance from pre-2017 requirements (i.e. BTC nodes need higher specs than BCH nodes today) while expanding contract capabilities to ETH levels. BCH re-enabled many of the Satoshi opcodes + data signatures (from the stack) in 2018, a full set of introspection opcodes in 2022, native token primitives in 2023, and arbitrary precision math in 2025. The 2026 upgrade mainly improves code-factoring (trimming waste/duplication) vs. adding new capabilities. I picked that LM-OTS scheme as a technical demo since it hits several critical thresholds vs. ETH and SOL. On BCH, these Quantumroot transactions are actually faster-to-validate-per-byte than "payments only" Bitcoin Cash transactions have been since 2009 (and likewise vs. BTC transactions). Re screenshot: is an in-browser IDE (@BitauthIDE) I've built over the past few years. I'll be working a lot more on it this year (finally) now that CashVM is relatively feature complete – there's a lot more multi-transaction system design, invariant testing, constraint solving, symbolic execution, etc. capabilities I'd like to add. Re BCH opcodes: not sure if there are any websites with pretty tables (maybe I should build one), but here's a full listing with descriptions I wrote – today's opcodes (last addition 2023): github.com/bitauth/libauth/b… and the 2026 additions (loops, functions, and some additional bitwise ops): github.com/bitauth/libauth/b… Re language: Bitauth IDE includes a very basic language and compiler I call "CashAssembly" that compiles to CashVM bytecode – it's just a way of writing raw data and opcodes with some basic variable support and other features. It's essentially what you see on the old Bitcoin wiki, but with some lossiness cleaned up. The BCH space has other high-level languages too – CashScript is a JS-like stack (loops pending: github.com/CashScript/cashsc…) and AlbaDsl is a really promising Haskell DSL. Remember though that Satoshi based the Bitcoin Script language on Forth (a high-level language of its own) – it's honestly great for building substantial applications from many small modules. For heavy applications like ZK proof verification, it's hard to beat the low-level control of CashAssembly right now. I made lots of performance improvements to Bitauth IDE while working on Quantumroot, and I'll be happy to help fix any perf issues as your application grows. Bitauth IDE has lots of built-in testing capabilities too, so I'm happy to help you set up "tested scripts" with scenarios and such. I wrote more about testing CashAssembly here recently: t.me/bitauth_ide/1627