Everything You Need to Know About BitVM

by Bob Bodily
by Bob Bodily

BitVM is a new Optimistic Roll Up + Fraud Proof + Taproot Leaf + Bitcoin Script computing paradigm designed by Robin Linus at Zero Sync. They published an excellent white paper, which was reviewed by Super Testnet and Sam Parker. This post is a summary about what BitVM is, why it might be beneficial, what the downsides are, and what the various opinions are among Bitcoin developers.


  1. This is not a silver bullet solution.
  2. No, BitVM is not as good as EVM, BitVM is slower, more expensive, and more complex.
  3. The core benefit of BitVM is additional programmability on Bitcoin without an upgrade. No new op_codes needed. No soft fork needed. Ready to go right now.
  4. Easy potential use cases include decentralizing various parts of applications that currently rely on centralized services (DLC oracles, congestion control/coinjoin aggregators, sidechain quorums).
  5. No, BitVM doesn’t solve trustless bridging for sidechains (this would likely require covenants).
  6. Yes, BitVM is strictly better than Greg Maxwell’s 2016 ZKP contingent payments example.
  7. BitVM is VERY complex to understand and implement. Upgrading Bitcoin with an op_code could accomplish the same thing.

Technical Deep Dive

Alright, now let’s dig into the technical side of things. I am heavily quoting many others throughout my summary here because it was the safest way to stay true to what they said without misquoting them.

BitVM’s purpose is “any computable function can be verified on Bitcoin.” – BitVM whitepaper

Which means that “Bitcoin is now as Turing Complete as any other chain, and this requires zero changes to Bitcoin” – Sam Parker

There are limitations (which we will get to later), but essentially what this means is as long as you: 

(1) have enough money to pay for off-chain computation/proofs, 

(2) have bandwidth to receive and send the necessary data (could be 100s of MB), and 

(3) can do as many Bitcoin transactions as needed,

THEN you can compute anything you want.

“All BitVM does is allow us to split the runtime of some logic that would be out of bounds of a single transaction across multiple transactions. That’s it.” 

– Sam Parker

So it might take a REALLY long time. And it might be REALLY expensive. And it might take hundreds of transactions. But you can do whatever you want.

Reiterated by Sam himself:

“So Bitcoin really isn’t any more Turing Complete by the technical definition as it was before, it simply has been given a runtime to its programs that we can reasonably say it’s “Turing complete enough” for any program that we could realistically want to execute.”

One of the key benefits here is there is no upgrade required. You can do it all right now. 

And you don’t have to use it if you don’t want to:

“This is opt-in. If you don’t trust your coins being locked to some Turing complete contract (totally reasonable) then don’t lock them to a Turing complete smart contract.” – Sam Parker

Since there will be some computational limits on what you can do, I think the lowest hanging fruit for something like BitVM is replacing a lot of the centralized “Bitcoin edge” services that people currently use.

For example we could “cut out all kinds of trusted or semi-trusted escrow services that a version of Bitcoin without this requires. Congestion control/Coinjoin aggregators, sidechain quorums, certain types of DLC oracles, all can go from trusted/semi-trusted to 100% trustless. Bitcoin’s trustlessness is only as strong as the weakest link in the interaction you are engaging in with it.” – Sam Parker


Now let’s get into what Eric Wall thinks about it:

“I just read the whitepaper and all the concepts check out to me. I have a natural disinclination for schemes that require very large pre-signed transaction exchanges in a setup phase—I don’t know which issues may arise from such schemes. Overhead and permission are the two big issues. 

For now, I’m cautiously excited, waiting for what the real-world experiments will yield. Maybe there are elegant, trivial solutions to the two-party limitations of this scheme, maybe there aren’t. Maybe the overhead is manageable for specific types of computation, like zk proofs. 

If BitVM works well to verify a zk proof inside it, then that’s interesting—BitVM would then serve the role of the zkwasm layer [I’ve discussed previously].”

He then continued with what is probably the best succinct summary of BitVM:

“Is it correct to say that BitVM today only describes a way by which a verifier can steal a bond from a prover depending on the outcome of a turing complete computation, but doesn’t really describe an architecture for peg-in/outs for outside participants?”

The answer to his question is yes, this is exactly what BitVM is at this point.

Adam Back jumped in with a more critical comment (that has tons of views):

“For people getting (over) excited, this is cool but effectively a generalization of a two-party game – it says right in the abstract – so it’s a bit like Greg Maxwell’s 2016 ZKP contingent payments implemented example.”

Except Adam missed a part of the paper and this BitVM is actually strictly better than Greg Maxwell’s 2016 ZKP example. Quote from Robin:

“It is strictly superior [than Greg Maxwell’s 2016 ZKP example because] in a ZKCP the prover has to know the solution upfront.”

Super Testnet was a reviewer on the article and posted:

“This is probably the most exciting discovery in the history of bitcoin script. It seems to knock down practically every door, and gives us access to covenants, sidechains, and powers similar to Liquid or the EVM, all at once with no forks required. I can’t wait to publish my demo.”

And to answer Eric Wall’s question about 1 to N party setups, Super Testnet posted: “It also allows for 1-N parties, similar to rollups. You can have a central party take a fee to perform computations for a group. Everyone in the group knows the central party cannot lie or the group can take, and distribute among themselves, a massive bond.”

So some additional trust, but with nice economic trust assumptions as the central party loses in the event that they are dishonest.


One main downside to BitVM is the complexity. There is a lot of presigning that needs to occur in order for BitVM to work.

Rijndael commented: “Seems like CTV would cut down on the presigning. This would be great to build with current bitcoin and then figure out how much interactivity could be cut out with ctv and whether thats a nice to have or a must have”.

If you aren’t up to speed here, CTV = BIP-119 = Simple Covenants. So if we upgraded Bitcoin to enable CTV, BitVM would be a lot nicer and more efficient.

Post Capone added his own take on the current positivity across many ecosystems within Bitcoin: “BitVM has spurred net positive commentary from 8 separate legions within bitcoin that notoriously slander each other into oblivion. Big stuff, man. Big stuff. Hats off to a lot of the analysis/feedback that has been piped out in such short order. It’s very cool to see. Ordinals was a magical moment. This feels like it has the gas in the tank to double down on that. We’re all clamoring over ourselves to hack it into working order.”

BitVM is very similar to Lightning Network as (at least in the paper) there is a 2:2 multisig requirement.

Dylan LeClair posted:

“Correct me if wrong: although technically much different, its like LN in the sense that it’s a 2:2 multisig where TXs/apps/contracts can be built above bitcoin, but verification & settlement occurs on-chain. As I understand it this would enable trustless BTC peg-ins (?).”

To which Sam replied:

“It enables basically anything you’d want to enable including trustless peg ins. It’s very similar in spirit to lightning in that way yes. I think running this protocol inside of a lightning channel is going to be the real power play personally. I suspect there’s a way to piggyback on Lightning’s justice transactions in a very synergistic way.”

Some have doubted whether BitVM can support a global state due to the state-channel-like description in the article, but Super Testnet responded “It supports global state. Party A can prove statements to party B about a global ledger such as bitcoin or a sidechain or even an alt-chain.”

Essentially BitVM “enables more expressive Bitcoin contracts. Particularly, it enables functionality that we thought we’d need a soft fork for. It might enable trustless sidechains, but that’s not fully solved yet.” – Super Testnet

And Rijndale responded that we likely still need covenants for trustless sidechains: “BitVM lets you spend ALL of a UTXO with a smart contract. For trustless sidechains we need to be able to spend PART of a UTXO with a smart contract”.

Bob’s take:

  1. Another whitepaper, another round of podcasts, and another loop around the sun. BitVM is very interesting, but it is still in the research phase with much still to be explored, so TBD on how many problems BitVM can solve for us all.
  2. There are likely some simple key use cases that could start leveraging BitVM right now to reduce trust assumptions (DLC oracles).
  3. We need a variety of different paths to give us additional programmability on Bitcoin, so I applaud anyone working on solutions in this area (BitVM included). I hope tons of devs build really cool demos with it that solve big problems for people.

Thanks for reading! If I missed anything, please correct me or ask questions in the replies.

Bob Bodily
Bob Bodily
CEO of Bioniq. Entrepreneur and lifelong learner. Finding product market fit for blockchain solutions one user at a time.