Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryScaling2023Design paperCorpus record

BitVM: Compute Anything on Bitcoin

BitVM. Robin Linus.

A way to dispute an arbitrary computation between two Bitcoin parties using hashlocks, timelocks and large Taproot trees, without a new opcode. Honest execution stays off-chain. A false claim can be challenged on-chain. It is not a global virtual machine.

BitVM lets two parties dispute a general computation on Bitcoin without a new opcode. The prover commits to a circuit in a Taproot tree. The verifier challenges a gate. Only a dispute hits the chain. Cooperative execution leaves almost nothing. The paper is not a deployed virtual machine and not a finished bridge.

The five-minute read

Dispute, not execution

Bitcoin nodes do not run the program. They adjudicate a challenge about a committed gate, using hashlocks and timelocks. That is the optimistic pattern, on Bitcoin script.

Two parties

The construction is a prover and a verifier who pre-signed the challenge transactions. A crowd of users is not a party in the paper's protocol.

The circuit is committed up front

The prover binds to bits and gates before the computation is accepted. A challenge opens one of those commitments. Ambiguity is what the script punishes.

Applications are sketches

The paper names games, proof verification and bridges as things the paradigm might allow. Naming them is not specifying them.

One action, walked through

  1. The two parties agree on a circuit and exchange the pre-signed challenge transactions.
  2. The prover asserts an output for an input.
  3. If the verifier accepts, they settle off-chain.
  4. If not, the verifier challenges a gate. The prover must open the committed inputs and output of that gate.
  5. A false opening can be punished on-chain. An absent verifier cannot punish anything.

The argument, unpacked

No new opcode is doing the work

The paper's constraint is the existing script. Taproot makes the tree of challenges practical. A project that needs a soft fork is not implementing this PDF, whatever it calls itself.

The verifier is the security assumption

Optimistic systems fail closed only if someone honest challenges in time. BitVM inherits that. A bridge sketch that does not name the verifier has not named its security.

What has to be true

  • Both parties can be forced on-chain within the timelocks.
  • The Taproot tree really contains the circuit they think it does. A substituted tree is a different contract.
  • Bitcoin consensus rules stay as they are. The paper depends on that.
  • Pre-signed transactions are available when the dispute starts. Lost keys are not handled.

What happened after the paper

BitVM is the citation for 'general dispute on Bitcoin without a fork'. Later BitVM bridge write-ups are later documents. Do not let a 2023 paradigm paper stand in for a production peg.

What to check before you use the idea

  • Who is the prover and who is the verifier?
  • What lands on-chain if they agree, and if they do not?
  • Does the design require a new opcode?
  • Is a bridge claimed, or only a two-party dispute?

Terms

Challenge
An on-chain step that forces the prover to open one committed gate of the circuit.
Cooperative case
The path where both parties accept the result and do not publish the dispute.

The problem the paper names

Bitcoin script cannot run a general program. BitVM asks whether two parties who pre-signed a challenge tree can still force a false statement to lose, using only the script that already exists.

What the design proposes

  • The prover commits to a circuit, gate by gate, inside Taproot leaves.
  • The verifier can challenge a gate. The response must open the committed bits.
  • If the parties cooperate, nothing but a settlement hits the chain.

How the mechanism is specified

  • The computation is verified by dispute, in the optimistic-rollup sense, not executed by every Bitcoin node.
  • The protocol in the paper is two-party. A bridge or a rollup with many users needs extra machinery the paper sketches and does not finish.
  • The on-chain footprint of a dispute can be large. The paper treats that as the failure path.

What this page does not treat as proven

  • No consensus change is required, and none is granted. Miners do not learn a new opcode.
  • A commitment to a circuit is not an implementation of a bridge. The paper says bridging is a possible application, not a completed one.
  • The verifier has to be willing and able to challenge. An offline verifier loses.

Why a venture studio still reads it

If a product says it is BitVM, ask who the prover is, who the verifier is, and what transaction actually lands when they disagree. 'Compute anything' is the dispute, not a smart-contract platform.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.