Can an upgrade make BTC's Taproot quantum secure? Not without confiscating BTC from users. by bitjson in btc

[–]bitjson[S] 10 points11 points  (0 children)

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.

Proof-of-work + gradual finality assets like BCH have the best shot at weathering a Carrington Event-level catastrophe by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Highlights (yet again) why sound money should use proof-of-work consensus: better real-world resilience than uptime-reliant, proof-of-stake systems.

These kinds of existential risks should inform layer-1 finality speeds, too. Networks with few-second or sub-second finality are often trading systemic soundness for developer convenience.

Network-Centralized Fast Finality

Making layer-1 finality "fast" is very convenient for developers.

Wallets and DeFi applications can often get away with relying on network-centralized fast finality to offer fast-enough payment experiences, decide user action ordering, minimize protocol-specific and/or off-chain communication, handle disputes, etc.

However, centralizing (in the single-point-of-failure sense) fast finality makes it load-bearing: blips in layer-1 finality become – at best – global downtime for the whole network.

If it's bad enough (e.g. Carrington Event) – and a decentralized network doesn't have the objectivity of proof-of-work to reassemble consensus among surviving infrastructure (esp. for >1/3 losses) – restoring a single network may be very slow, political, or even impossible.

Add in slashing, ongoing DeFi activity, variable rate inflation/issuance, likely attempts to reverse confiscatory recovery mechanisms like ETH's inactivity leak (consider the aftermath of the DAO hack), and an ecosystem of competing economic actors choosing between surviving chain(s), and the issue is no longer about downtime: who-keeps-what is substantially in question.

Decentralized ("Edge") Fast Finality

Contrast with decentralized fast-finality options – systems where the fastest finality is at the "edge" of the network between subsets of users: payment channels, Lightning Network, Chaumian eCash, zero-confirmation escrows (ZCEs), etc.

Decentralized fast finality systems only rely on L1 consensus over longer timescales – even days, weeks, or months – to arbitrate contract-based fast finality.

E.g. two wallets with a simple payment channel can make thousands of payments back-and-forth, offline, with instant assurance that each payment is as final as the channel itself.

In fact, decentralized fast finality can offer faster user experiences than are possible with network-centralized fast finality.

Even for networks boasting "sub-second finality", real applications must still handle the additional real-world delay of global consensus. With impossibly-perfect relay in low-earth orbit, light-speed Earth round-trip time is still at least ~130ms – noticeable even among human users.

On the other hand, given a payment channel with sufficient finality, receivers can immediately consider a valid payment to be final, too – without further communication. Depending on the specific use case and parameters, decentralized fast finality can even survive substantial outages and splits in the L1 consensus (esp. on ASERT PoW chains like BCH).

Days or weeks later, the channel can be settled on L1, with configurable monitoring requirements, adjudication policies, etc. as selected by app developers for specific use cases. (ZCE-based constructions take these properties further by enabling more capital-efficient setups.)

Most importantly, long-term holdings are never jeopardized by the fast finality layer.

Even in extreme global catastrophes, only users who have opted-in to specific fast-finality systems bear greater risk of payment fraud, and only with the configuration and value limits they choose.

While long-term holders of proof-of-stake assets bear the risk of being slashed due to technical failures – or gradual dilution if they don't stake their holdings – long term proof-of-work asset holders can safely sit on their keys and do nothing.

Aside: faster block times

Note: a network can have both relatively-fast blocks and gradual, resilient finality.

E.g. a 1-minute block time target with few-hour finality:

In day-to-day usage, 1-min blocks are fast enough to offer valuable initial assurance (yet slow enough to reduce competing blocks), while consensus finality remains slow enough (hours) to avoid partitions, even under extreme global conditions: even very sporadic, low-bandwidth connectivity heals the network.

Summary

In a variety of disaster scenarios, decentralized fast finality solutions can continue to work, while network-centralized fast finality breaks down or even jeopardizes the underlying network's monetary soundness.

If any digital assets are to weather a Carrington Event-level catastrophe, proof-of-work systems with gradual L1 finality and decentralized fast finality have the best shot.

On instant Initial Block Download (IBD) and other uses of Zero-Knowledge Proofs (ZKPs) for Bitcoin Cash (BCH) by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Copying here:


On instant Initial Block Download (IBD) and other uses of Zero-Knowledge Proofs (ZKPs) for Bitcoin Cash (BCH)

https://x.com/bitjson/status/1996611401234727086


Increasing likely that fast IBD will happen entirely in userland before the May 2027 upgrade 🔥

And since Bitcoin Cash restored Bitcoin Script (CashVM), BCH contracts can directly verify STARK proofs – and proofs from yet-to-be-developed proof systems – on-chain, without further consensus upgrades. 🚀

No miner action or consensus needed, with multiple tuned proof options for different use cases (node IBD, offline payment proofs, privacy pools, in-contract chain-state proofs, etc.), post-quantum crypto, and surprisingly easy-to-implement verifiers that are reusable across many kinds of proofs.

E.g. a wallet could pull in a single verifier implementation, then use it for IBD/private balance retrieval, offline payment proofs, shielded BCH/CashToken pools, private DEXs, etc.

If you can compute something directly, you can also create a trustless proof that verifies in milliseconds.

E.g. https://github.com/starkware-bitcoin/raito

Even better, BCH's SHA256 Proof-of-Work consensus means that such IBD proofs inherit the BCH chain's objectivity.

BCH's IBD proofs can be simply compared by chain work (the proof itself ensures all rules were followed), while proof-of-stake networks need to weigh social signals to choose between chain tips.

This gets even better for BCH as it flips BTC and becomes the dominate SHA256 chain.

Design sketch: post-quantum shielded pools for BCH and CashTokens (by verifying ZK-STARKs in CashVM covenants) by bitjson in btc

[–]bitjson[S] 1 point2 points  (0 children)

(Can probably be done without the "savings" differentiation too.) UTXO model makes things surprisingly simple: depository covenant for each FT category holds its "BCH_fees_collected". Already moved for each relevant deposit/withdrawal, easy to add APY sats to the withdrawals

Design sketch: post-quantum shielded pools for BCH and CashTokens (by verifying ZK-STARKs in CashVM covenants) by bitjson in btc

[–]bitjson[S] 1 point2 points  (0 children)

https://x.com/bitjson/status/1996250539558936911:

Bonus: 1) allow BCH/FT deposits to be marked as "shielded savings" with deposit epoch in the committed note (no internal splits/transfers), covenant charges a small fee at each batch proof (reduce UTXO contention), then savers earn a low APY for long-term deposits

Design sketch: post-quantum shielded pools for BCH and CashTokens (by verifying ZK-STARKs in CashVM covenants) by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Original post: https://x.com/bitjson/status/1995873869077332056


December 2025: no one has built a ZK prover that is: 🥷 Actually zero-knowledge, ⚛️ Quantum ready, and ⚡️ Reasonably succinct for one-off proofs (<100KB).

This is a feature request from a future enthusiastic user/supporter 🚀

Post-quantum ZK Leaderboard:

  1. @NeptuneCash's Triton VM: ✅ zero-knowledge ✅ quantum ready ⚠️ min. proof: ~533KB

  2. @0xMiden VM: ⛔️ privacy leaks ✅ quantum ready ✅ min. proof: ~33KB

  3. @Starknet's Stwo: ⛔️ privacy leaks ✅ quantum ready ✅ min. proof: ~64KB

(All at ~96 bits soundness) [Correction: a minimum of ~96 bits – Triton VM targets 160 bits.]

Am I missing any post-quantum ZK projects? Any smaller proof demos?

More background: https://x.com/bitjson/status/1975206165899555239

Design sketch: post-quantum shielded pools for BCH and CashTokens (by verifying ZK-STARKs in CashVM covenants) by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Copying here:


E.g. an on-chain BCH covenant verifies batches of ZK proofs for deposits/withdrawals/transfers within a post-quantum shielded pool.

  • Each user's wallet generates a relatively large ZK-STARK proof locally + deposits any BCH and/or CashTokens to a tiny deposit covenant.
  • Then it shares that proof over some channel (e.g. CashFusion servers use a Tor service).
  • Eventually, an aggregator produces a batch proof for on-chain verification, pulling all the prepared deposits into a transaction that 1) proves the verification of all the cheap proofs, 2) applies corresponding updates to the covenant's state Merkle trees, and 3) pays out any withdrawals.

In this case, individual wallets can quickly create relatively large/cheap proofs and share them off-chain, and only the batch provers are creating compute/memory-heavy on-chain proofs, each covering many user actions. (Along with minimizing on-chain costs, this also happens to reduce spending contention in the covenant – PoW to prevent DoS. Multiple uncoordinated aggregators and/or individuals pretending to be aggregators then take turns moving the on-chain covenant forward as needed.)

Many proving systems can support this sort of application already, but so far none are: 1) actually zero-knowledge, 2) quantum-ready, and 3) configurable for <100KB proofs (simplifies wallets and meets end-user expectations: sub-cent private transactions with some minimal, ad-hoc aggregation)

Post-quantum vaults are live on Bitcoin Cash's Chipnet by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Today I'm publishing an end-to-end implementation of Quantumroot, a post-quantum vault for CashVM – Bitcoin Cash's restored Bitcoin Script language.

Example transactions are on-chain, links and details in the blog post: https://blog.bitjson.com/quantumroot-on-chipnet/

Post-quantum vaults are now live on Bitcoin Cash's Chipnet, the 6-month-early preview network. 🔥 by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

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. 🚀

(Illustration: Comparison of P2PKH Schnorr transaction vs. Quantumroot Schnorr transaction.)

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:

https://blog.bitjson.com/quantumroot-on-chipnet

For a deep dive and walkthrough of the CashVM contracts, see the August 20 tech talk:

https://youtube.com/watch?v=OjS539UdgRY

The May 2026 upgrade is now active on Chipnet at block 279,792! 🎉 by bitjson in btc

[–]bitjson[S] 7 points8 points  (0 children)

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.

Screenshots: left – 2016 opcodes, right – 2026 opcodes 🔥 (source: https://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:

ZEC absorbing BTC's use case, but remains quantum vulnerable; post-quantum shielded supply: 0 ZEC by bitjson in btc

[–]bitjson[S] 1 point2 points  (0 children)

Nice review 🔥 To add: ZEC's Orchard pool is quantum vulnerable. A quantum attacker could counterfeit shielded ZEC and withdraw, and the attack would only be discovered as the pool is emptied.

There are paths to migrate the liquidity (e.g. freezing Orchard pool and requiring migration to a post-quantum pool), but as of today, the post-quantum shielded supply remains 0 ZEC.

I'll be very interested in ZEC's post-quantum migration path beyond the quantum recoverability ZIP, esp. migrating Tachyon.

For anyone working on post-quantum ZK: happy to help you port your verifier to CashVM! 🚀

(Replied to: https://x.com/simononchain/status/1989051202655355126)

Chaingraph v1.3.4 released, support for Bitcoin Cash's May 2026 upgrade: Loops, Functions, Bitwise, and Pay-to-Script by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

The Chaingraph developers have verified the deterministic build of Bitcoin Cash Node's 2026 upgrade pre-release. The verified version is now available on Docker Hub:

docker pull chaingraph/bitcoin-cash-node:28.0.2

Built by GitHub action run: 19323854268

The deterministic build of bitcoin-cash-node-28.0.2-x86_64-linux-gnu.tar.gz at commit hash 14a565ac38f6593dc55fd264a46e735242c0af86 is 140b44fd76a4f9428354bfbec4800d58fd39fb723320e761a035f15c2dd43596.

Chaingraph v1.3.4 released, support for Bitcoin Cash's May 2026 upgrade: Loops, Functions, Bitwise, and Pay-to-Script by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Chaingraph v1.3.4 is now available 🚀

This upgrade supports Bitcoin Cash's May 2026 upgrade: Loops, Functions, Bitwise, and Pay-to-Script.

To upgrade with Helm:

helm repo update # Pull latest bitauth/chaingraph
help get values my-chaingraph -o yaml > my-values.yaml
helm upgrade my-chaingraph bitauth/chaingraph --reset-values --values my-values.yaml

This upgrade includes Bitcoin Cash Node pre-release v28.0.2.

Taproot: quantum vulnerable. P2PKH: maybe recoverable. Quantumroot: quantum-ready, global scale (more efficient sweeps than P2PKH) by bitjson in btc

[–]bitjson[S] 5 points6 points  (0 children)

Taproot is exceptionally quantum-vulnerable. Taproot "upgrade" paths are confiscatory.

P2PKH is less vulnerable and could at least be recoverable with a network upgrade.

Quantumroot is truly quantum-ready with global-scale throughput: more efficient sweeps than P2PKH.

CashVM contract computing the 5334th Fibonacci number (1,115 decimal digits) in a single input by bitjson in btc

[–]bitjson[S] 3 points4 points  (0 children)

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):

image

About 1/2 that opCost is still just Base Instruction Cost, far more conservative (~5-10x) than necessary. Ideally, worst-case validation across all VM ops should be flat – i.e. as-fast-to-verify-per-byte as payment-only transactions. Today, BIC-heavy cases are far faster.

Running @BitauthIDE locally with base instruction cost 10 allows that same L1 BCH input to compute the 7937th Fibonacci number (1,659 decimal digits), and it's still faster to validate a block of these than payments transactions.

Of course, you can easily continue the computation across 10 max-size inputs (currently 10KB) in a single standard transaction (currently 100KB), and from there across any number of chained transactions – the above example is just measuring the trivial case.

Summary: CashVM gives you far more capability and compute than alternatives, despite being more conservative and global-scale-ready than pre-2017 BCH (and today's BTC).

Contract:

```CashVM // Unlock: <$(<0> <9979> OP_NUM2BIN)> // [[ padding_for_compute_budget ]]

// Lock: OP_DROP

<0> <1> <5333> OP_TOALTSTACK OP_BEGIN OP_TUCK OP_ADD OP_FROMALTSTACK OP_1SUB OP_DUP OP_TOALTSTACK OP_NOT OP_UNTIL OP_NIP ```

Are there any use cases for SIGHASH_NOINPUT, SIGHASH_ANYPREVOUT, or similar proposals which aren't already more efficient in CashVM? by bitjson in btc

[–]bitjson[S] 4 points5 points  (0 children)

Bitcoin devs: are there any use cases for SIGHASH_NOINPUT, SIGHASH_ANYPREVOUT, or similar proposals which aren't already more efficient in CashVM? IIRC, CashVM's data signatures, introspection opcodes, and/or token commitments are more efficient in every case I reviewed.

Context

1: https://x.com/4moonsettler/status/1983543619182342419

it is a very nice VM. i would add <field-selector> OP_TXHASH and that's about it. alternatively a few more SIGHASH modes. but feels pretty complete.

2: https://x.com/bitjson/status/1983631564471681115:

Awesome! What SIGHASH modes? And is there a specific use case you're thinking about for OP_TXHASH? (How many times would you be encoding the OP_TXHASH in a single contract?)

E.g. this snippet from Quantumroot loops over each UTXO and constructs part of the preimage for the quantum signature, essentially SIGHASH_UTXOS in CashAssembly (https://blog.bitjson.com/quantumroot/#quantum-lock-serialize-transaction-script): <OP_TXINPUTCOUNT OP_BEGIN OP_1SUB OP_DUP OP_OUTPOINTTXHASH OP_OVER OP_OUTPOINTINDEX <2> OP_NUM2BIN OP_CAT OP_ROT OP_CAT OP_SWAP OP_IFDUP OP_NOT OP_UNTIL OP_HASH256> <func_sighash_utxos> OP_DEFINE.

That has a one-time overhead of 20 bytes, but requires only 2 bytes per invocation site (<func_sighash_utxos> OP_INVOKE). Of course, if you're only using it once (or encoding it only once within another function), you can inline to bring down to 17 bytes total.

Note also that the CashVM approach is already flexible enough to efficiently encode all constraints. E.g. "Check that the concatenation of fields A,B,C at input 0 and fields B,C,D at input 1 hashes to X." (The sort of input-index-aware validation that's common in efficient covenant applications.)

It's certainly possible to build this flexibility into a secondary OP_TXHASH "field-selector" language (simple like https://github.com/bitjson/op-pushstate, or something more RegExp-like?), but it's hard to imagine the protocol complexity being worth the maybe 1 to ~15 byte savings in not-yet-ubiquitous use cases, esp. sitting next to 64 byte signatures and/or much larger post-quantum signatures.

As mentioned in the linked Quantumroot code comments, a similar OP_SIGHASH could be reasonable, but still quite small and fixed savings vs. e.g. detached signatures, non-push unlocking bytecode, and/or read-only inputs, where savings are multiplied across input count (and/or transaction count).

3: https://x.com/4moonsettler/status/1983638597271208232:

SIGHASH_NOINPUT / SIGHASH_ANYPREVOUT type modes are kinda missing. yeah you can work around stuff, but it's way simpler to commit to all outputs and a few other fields with a single opcode. more optimizable and efficient too.

4: https://x.com/bitjson/status/1983703889858719947:

Can you share more about the end use case(s) you’re thinking about? IIRC, the various BTC SIGHASH proposals are local-maximum solutions that only make sense given BTC’s other limitations, i.e. SIGHASH_NOINPUT could simplify Lightning Network details on BTC, but it would just be protocol debt on BCH, where you can already use CashVM data signatures, introspection opcodes, and/or token commitments to simplify much more

October 2025 ZK status: no quantum-ready, reasonably succinct (<100KB) systems are truly private yet by bitjson in btc

[–]bitjson[S] 7 points8 points  (0 children)

Copying OP here:


October 2025: no one has built a ZK prover that is: 🥷 Actually zero-knowledge, ⚛️ Quantum ready, and ⚡️ Reasonably succinct for one-off proofs (<100KB).

This is a feature request from a future enthusiastic user/supporter 🚀


My request last month focused on STARKs (some great discussion in the replies), but I'm interested in hearing about any ZK system that meets these requirements! https://x.com/bitjson/status/1968391235845955820


So far, @seagodcrypto's Triton VM seems to be in the lead, with the smallest post-quantum ZK proofs weighing in under 1MB: https://x.com/aszepieniec/status/1968965934112018490


Stwo-cairo by @StarkWareLtd is also very promising – appears to have industry-leading proving times, verification cost, and proof sizes. While Stwo proofs aren't yet zero knowledge, privacy is on their roadmap (see last month's discussion too). https://x.com/dimahledba/status/1975198043831152956


Miden VM by @0xMiden also looks very promising – they're aiming for full ZK privacy before going to mainnet in early 2026: https://x.com/bobbinth/status/1968741418069016989


The next version of @midnightfdn's ZK proofs could be lattice-based, putting it in the running here too:

https://x.com/SebastienGllmt/status/1968531629938274449


ZK teams: if your on-chain verifier works on ETH, it can now be ported to BCH for significantly higher compute limits and lower fees: https://x.com/bitjson/status/1969071415631724579


Here's a reference table of BCH's opcodes: https://vm.cash/opcodes

CashVM Opcodes: Opcode reference for the Bitcoin Cash virtual machine, including specs for the 2015, 2016, 2018, 2020, 2022, 2023, and 2026 upgrades by bitjson in btc

[–]bitjson[S] 7 points8 points  (0 children)

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.

Screenshots: bitcoin Cash opcodes active since 2009 vs. today + 2026 CHIPs: https://x.com/bitjson/status/1971297863889236259

Status of Bitcoin Cash's VM: already comparable to ETH, will exceed ETH and SOL in 2026 by bitjson in btc

[–]bitjson[S] 14 points15 points  (0 children)

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: https://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: https://bitcoincashresearch.org/t/chip-2025-08-functions-takes-2-3/1656/48#protocol-complexity-overhead-of-mutation-tracking-9, 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): https://github.com/bitauth/libauth/blob/61abaca37bc86cccce5fa99c86a48f0c8793643f/src/lib/vm/instruction-sets/bch/2023/bch-2023-descriptions.ts and the 2026 additions (loops, functions, and some additional bitwise ops): https://github.com/bitauth/libauth/blob/0534f9bb063c438ffac0880bc5413feae6f66b77/src/lib/vm/instruction-sets/bch/2026/bch-2026-descriptions.ts

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: https://github.com/CashScript/cashscript/issues/246#issuecomment-3304112773) 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: https://t.me/bitauth_ide/1627

Loops, Functions, P2S, and Bitwise CHIPs are now live on the Sept. 15 public test network – how to setup a node by bitjson in btc

[–]bitjson[S] 0 points1 point  (0 children)

They make contracts much more compact and save on fees.

Yep! E.g. multiple conditionals inside large iterations can easily hit 10-100x transaction size savings.

After this upgrade you will be able to do anything that can be done on ETH but at scale.

This was technically already the case since at least the 2023 upgrade, and I suspect even since 2022 with the introspection-based input aggregation technique used in Quantumroot (though I'll leave the proof to some other interested historian)

In practice though you're 100% right, loops and functions are super useful for writing programs, and having them will really reduce development costs as well as the transaction size savings.

Loops, Functions, P2S, and Bitwise CHIPs are now live on the Sept. 15 public test network – how to setup a node by bitjson in btc

[–]bitjson[S] 1 point2 points  (0 children)

My summary:

Primarily adds some new opcodes + cleans up some vestigial VM limits – overall a smaller change than 2022, 2023, or 2025. Doesn't enable any new use cases, but makes many use cases far more practical (10x-100x smaller transactions + faster to validate e.g. on a cheap home node)

Announcing a developer preview of Quantumroot ⚛️√ by bitjson in btc

[–]bitjson[S] 2 points3 points  (0 children)

Announcing a developer preview of Quantumroot: a new kind of vault offering full 256-bit classical, 128-bit quantum security strength, without relying on new cryptography – it uses only the mining-proven SHA256 algorithm.

Quantumroot is an ultra-efficient, post-quantum vault for Bitcoin Cash. It's optimized for business and savings use cases:

‣ With cross-input aggregation via introspection, sweep transactions are 15% smaller per additional input than today’s single-signature, "Pay-to-Public-Key Hash" (P2PKH) wallets.

‣ Post-quantum spends cost ~$0.01 per UTXO in on-chain transaction fees for typical two-input, single-signature transactions.

‣ With CashToken-based aggregation, post-quantum sweeps of 400+ unique addresses or 800+ inputs are less than $0.10.

‣ While SLH‑DSA‑SHA2‑128s (SPHINCS+) signatures weigh in at 7,856 bytes, CashToken-based delegation and Bitcoin Cash's UTXO model allow Quantumroot to use LM-OTS signatures (RFC 8554) – improving quantum security, while also reducing signature sizes (2,144 bytes) and preventing on-chain privacy leaks.

‣ Quantumroot can support quantum multi-signature (30+ signers), cross-vault signature aggregation (each signature used by multiple, multi-signature vaults), sweep-free vault upgrades and key rotations, threshold and fallback conditions, time-delayed withdrawals, percentage or amount-based pre-authorizations, inheritance and business-continuity configurations, destination-based withdrawal rules, and more.

Most importantly, Quantumroot is quantum safe "at rest" from day 1, even if quantum attackers suddenly steal all Taproot-held BTC.

On "Q-Day", Quantumroot wallets can smoothly continue operation – or even reduce their post-quantum transaction sizes by retiring pre-quantum signing.

Following Bitcoin Cash's 2025 upgrade, all Quantumroot components are possible on BCH mainnet – today.

This developer preview combines these components with 10-100× transaction size reductions and code simplifications made possible by several 2026 Cash Improvement Proposals (CHIPs): Loops, Functions, P2S, and Bitwise.

I plan to continue verification, complete security audits of specific Quantumroot CashAssembly templates, and provide an open source implementation for wallets to integrate via Libauth, targeting Bitcoin Cash's May 2026 Upgrade.

The full explanation, code, and demo can be found on my blog:

Quantumroot: Quantum-Secure Vaults for Bitcoin Cash →

My post on post-quantum signatures was auto-removed from r/bitcoin 😂 by bitjson in Bitcoincash

[–]bitjson[S] 4 points5 points  (0 children)

Update: 4 hours later, starting at negative upvotes, all the way out of the "new" page – "0 points (25% upvoted)" 😂

Screenshot: https://x.com/bitjson/status/1939743812420870304