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.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 8
Code
Source, repository, and what is actually hosted
- bitvm.orghttps://bitvm.org/bitvm.pdf
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
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.
Claim 02 · Paper model
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.
Claim 03 · Paper model
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.
Claim 04 · Paper model
Applications are sketches
The paper names games, proof verification and bridges as things the paradigm might allow. Naming them is not specifying them.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 Dispute, not execution
02 Two parties
Observation
What the study says
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.
Model
What has to hold
Pre-signed transactions are available when the dispute starts. Lost keys are not handled.
Falsifier
What would retire it
Who is the prover and who is the verifier?
03 The circuit is committed up front
Observation
What the study says
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.
Model
What has to hold
The Taproot tree really contains the circuit they think it does. A substituted tree is a different contract.
Falsifier
What would retire it
Who is the prover and who is the verifier?
04 Applications are sketches
Observation
What the study says
The paper names games, proof verification and bridges as things the paradigm might allow. Naming them is not specifying them.
03 Sequence
One action, as an operating tape
- 01The two parties agree on a circuit and exchange the pre-signed challenge transactions.
- 02The prover asserts an output for an input.
- 03If the verifier accepts, they settle off-chain.
- 04If not, the verifier challenges a gate. The prover must open the committed inputs and output of that gate.
- 05A false opening can be punished on-chain. An absent verifier cannot punish anything.
04 Load-bearing
The argument, and where a pitch drops it
No new opcode is doing the work
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
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 is the security assumption
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
The verifier has to be willing and able to challenge. An offline verifier loses.
05 Register
What has to be true
Model · Not re-measured
Both parties can be forced on-chain within the timelocks.
Model · Not re-measured
The Taproot tree really contains the circuit they think it does. A substituted tree is a different contract.
Model · Not re-measured
Bitcoin consensus rules stay as they are. The paper depends on that.
Cryptography · Not re-measured
Pre-signed transactions are available when the dispute starts. Lost keys are not handled.
06 Divergence
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.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it 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 the desk 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.
09 Lexicon
Terms, opened into the record
- 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.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
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.