| The WhitePaper Reading Club [DevConnect] | Nov 18 2025 |
|---|---|
| BitVMX: Future of Rootstock | Derrick (BigBrain), Rongxin (WPRC) |
Summary
BitVMX enables trustless verification of arbitrary off-chain programs on Bitcoin without new opcodes or consensus changes. This is done by turning computation into a hash-chained execution trace that can be challenged and proven on-chain through efficient, pre-signed dispute games.
Why This Is Important
Building trust-minimized computation on Bitcoin has always run into severe friction. BitVM1 relied on massive Merkle trees for memory and trace representation (making real programs prohibitively expensive to verify). BitVM2 improved usability but sacrificed generality: every intermediate step had to be re-executable in Bitcoin Script. TrueBit-style systems and Ethereum rollup designs depend on stateful smart contracts, storage, or precompiles that Bitcoin simply does not have; ZK-based bridges require running elliptic-curve cryptography inside Script, which is extremely expensive and not natively supported. BitVMX avoids all of these by using a lightweight hash-chain trace, last-step memory model, and pre-signed dispute games that work entirely within today’s Bitcoin Script.
Key Innovation
There are three key innovations:
- A message-linking protocol with pre-signed transaction DAGs: Eliminates equivocation-based fraud proofs and emulates covenants by cryptographically binding each challenge and response, ensuring deterministic dispute flow using only existing Bitcoin Script.
- An n-ary search over a hash-chained execution trace: Replaces BitVM1’s heavy Merkle structures and binary searches with lightweight hash-chain commitments and fast n-ary narrowing, drastically reducing dispute rounds and on-chain costs.
- A general-purpose virtual CPU verified via simple hash checks: Supports arbitrary deterministic architectures (e.g., RISC-V, MIPS) by expressing program execution as uniform read/opcode/write traces that Bitcoin can verify through minimal hash equality and single-step execution checks.
Background
TrueBit (2017) first proposed “verification games” where heavy computation runs off-chain and only disputed steps are proven on-chain. Ethereum’s optimistic rollups and later BitVM applied this to blockchains. BitVMX refines BitVM by replacing Merkle proofs with hash chains and pre-signed Bitcoin transactions, making the model practical inside Bitcoin’s limited scripting system. The current implementation uses Blake3 as the hash function in the hash chain.
Team
Sergio Demian Lerner: one of Bitcoin’s longest-standing security researchers — known for identifying early Bitcoin vulnerabilities and proposing major scalability ideas (e.g., Rootstock’s merge-mined smart-contract layer, the “Patoshi pattern” identifying Satoshi’s mined blocks, and early work on drivechains). Ramon Amela Milian: (i) Research Engineer at Rootstock Labs (ii) Degrees from Universitat Politècnica de Catalunya and École Nationale des Ponts ParisTech (iii) Engineering and CS research in system design and formal methods. Shreemoy Mishra: (i) Senior Researcher at Rootstock Labs (ii) Economist & Engineer, PhD from UT Austin (iii) Research focus: blockchain infrastructure, DeFi inclusion, cryptographic bridging systems. Martin Jonas: (i) Principal Engineer at FairGate Labs, author of "Optimizing Algorithms for Bitcoin Script" series (ii) Cryptographic hash optimization work (e.g., BLAKE3 in Bitcoin Script). Javier Álvarez Cid-Fuentes:(i) Head of Research at Rootstock Labs (ii) PhD in Computer Science, University of Adelaide (2017) (iii) Research areas: distributed systems, network anomaly detection, computational problem solving
Components
| Virtual CPU | BitVMX defines a minimal deterministic “software CPU” that both sides can emulate identically off-chain. Its main components are: (i) a fixed instruction set (e.g. RISC-V or MIPS) that standardizes how operations are executed; (ii) memory-mapped registers and addresses, ensuring all reads/writes occur in predictable locations; (iii) a defined program counter and state-transition rule so every instruction leads deterministically to the next; and (iv) an agreed initial state (inputs, memory, and code) so any future mismatch can be proven objectively. Questions: Will this Virtual CPU be run inside some custom environment? |
|---|---|
| Hash-chain traces | Every instruction’s result is captured as a compact “trace” describing which memory address changed, what value it wrote, and what the next program counter is. Each trace is hashed with the previous step’s hash to form stepHash = H(stepHash[i-1] || trace). Key features: (i) this recursive structure commits to the entire execution history; (ii) any single wrong step changes all subsequent hashes; and (iii) it allows locating the first error in a reduced number of step hash queries to another party. |
| Challenge–response protocol | When the prover claims a result, the verifier re-runs it locally. If their final hashes differ, a dispute begins. The protocol: (i) uses an n-ary search over the hash chain to find the earliest divergent step; (ii) forces the prover to reveal that step’s trace and prior hash; (iii) checks on-chain whether H(prevHash || trace) == claimedHash or re-computes the step on-chain and checks the correctness of its trace; and (iv) if false or if the prover fails to respond in time, the verifier wins and the prover’s deposit is slashed. Questions: How do you pick n and l in practice? |
| Pre-signed transaction graph | Bitcoin does not support covenants, so BitVMX pre-constructs a DAG of transactions covering every possible challenge, response, and settlement path. Components include: (i) a setup ceremony where both parties sign all potential transactions before execution; (ii) timelocks controlling when each branch can be broadcast; (iii) message-linking using one-time signatures to pass authenticated state data between rounds; and (iv) branch isolation so once one path is chosen, others are invalidated. This turns the verification game into a sequence of deterministic Bitcoin spends. |
| On-chain verification | Bitcoin itself executes scripts that fit into standard Bitcoin transactions. The Scripts use: (i) a Blake3 implementation in script to recompute a hash from revealed data; (ii) OP_EQUAL to confirm it matches the committed hash; (iii) OP_CHECKLOCKTIMEVERIFY to enforce round deadlines; (iv) normal signature checks to authenticate spenders and (v) 32-bit arithmetic opcodes to compute each of the CPU (RISC-V) opcodes. These minimal primitives are enough for Bitcoin to enforce who wins or loses without ever executing the full computation. |
Smallest concrete example (using 1+2=3)
| Setup (off-chain prep) | (i) Agree virtual CPU (deterministic), program “add two numbers,” input x=1, y=2, initial state; (ii) both pre-sign a dispute DAG: Kickoff, Challenge, Response, Fault/Slash, Settle (with timelocks); (iii) broadcast Setup Tx (deposits locked; challenge window opens).  |
|---|---|
| Happy path (no dispute) | (i) Prover runs off-chain: reads 1 and 2, writes 3; builds trace t1 = (write.addr, 3, nextPC) and hash chain h0=0, h1=H(h0||t1); (ii) Verifier runs locally and gets the same h1; (iii) after the window, Prover broadcasts Settle Tx; funds released (cost ≈ “Happy path” above). |
| Sad path (single bad step) | Claimed lie: Prover says result 4 (not 3), so their chain is h1' = H(h0||t1') where t1' encodes 4.Dispute flow on-chain: (i) Verifier broadcasts Challenge Tx (points to step 1—trivial n-ary search since only one step). (ii) Prover must answer with Response Tx revealing h0, claimed t1', and h1'. (iii) Script recomputes H(h0||t1') == h1' (hash link). If the link fails → immediate Fault/Slash Tx pays Verifier. If the link holds but t1' encodes an invalid execution (e.g., wrong read/write/opcode per the agreed CPU rules), Verifier executes onchain script that proves the invalid CPU opcode execution and the pre-signed path for that error is taken and Fault/Slash Tx pays Verifier. (iv) If Prover fails to respond before timelock → Verifier takes funds via Fault/Slash Tx. (Total cost ≈ “Sad path” above.)What Script actually checks (conceptually): (i) Blake3 over (prevHash || traceBytes); (ii) OP_EQUAL to the committed step hash; (iii) OP_CHECKLOCKTIMEVERIFY for deadlines; (iv) signature checks on each branch. Bitcoin enforces the money flow; (v) correctness of execution of one CPU (RISC-V) opcode; it never re-does 1+2.  |
Use Cases
Possible use cases include: Bitcoin Bridges & Sidechains, Verifying ZK Proof Systems, Rollups on Bitcoin,