Skip to main content

BitVM: A New Paradigm for Bitcoin

Introduction​

BitVM plays a crucial role in BOB's Hybrid Chain Roadmap by enabling superior Bitcoin bridging for our rollup. BOB will integrate a native Bitcoin bridge via BitVM that will serve as a backbone for Bitcoin DeFi in synergy with the Babylon LSTs and LRTs. From the network infrastructure to the tokens in your wallet, BitVM unlocks huge security advancements for Bitcoin DeFi.

Read on to learn how BitVM enables Bitcoin rollups and a new type of BTC bridge with a "1-of-n" trust assumption - all without a soft fork to Bitcoin.

Why BitVM Matters​

tl;dr:

BitVM2 is:

  • Secure: optimistic computation secured by Bitcoin.
  • Practical: only three transactions to complete a challenge.
  • Permissionless: anyone can challenge.

BitVM Bridge is the most secure BTC bridge to date.

  • BTC Bridges so far: t-of-n multisigs, honest majority assumption.
  • BitVM Bridge: 1-of-n security model, where anyone can challenge and prevent theft.

BitVM Summary​

BitVM is a way to expand the range of what is possible to do on Bitcoin. It does this by performing computation off-chain that is held accountable by an on-chain fraud proving mechanism. Since Bitcoin Script is very limited in what it can do, running more advanced programs on Bitcoin requires a way to verify that the results of off-chain calculations are correct.

Existing bridges typically rely on centralized entities—such as Wrapped Bitcoin (WBTC) and Coinbase Wrapped Bitcoin (cbBTC)—or semi-trusted networks like tBTC, where security depends on the honesty of the majority of participants. In contrast, BitVM bridges introduce a superior security model: BTC deposits cannot be stolen as long as there is a single honest and online node in the network, and this node can be the depositor themself.

BitVM verifies off-chain computation similarly to optimistic rollups:

  1. An operator performs a computation off-chain,
  2. then makes an on-chain claim about the results of that computation.
  3. If the claim is incorrect, a verifier will invalidate it directly on the Bitcoin blockchain.

In practice, this would look like a collection of operators depositing their collateral and committing to manage a pool of BTC according to the rules of a specific, pre-defined computer program (a bridge, for example).

If an operator attempts to withdraw BTC in a way that violates those rules, any verifier can prevent the withdrawal and slash the dishonest operator's collateral for the malicious attempt. The verifier does this by submitting a specific kind of transaction on Bitcoin that will be explained in a moment.

This reveals two important aspects of the setup:

  1. An operator only needs to provide enough collateral to cover the cost of disproving plus some extra amount to deter them from cheating and being slashed. This capital efficiency is exactly why BitVM is much better than other bridges, including collateralized bridges.
  2. The verifier can challenge a dishonest transaction directly to Bitcoin, slashing the operator and preventing the malicious withdrawal from happening. In other words, one honest verifier can prevent an infinite number of operators from cheating.

This setup is called optimistic because normal operation is assumed to be correct, allowing compute to happen at web2 prices while also maintaining a strong mechanism of on-chain accountability to prevent a dishonest claim from any operators.

Technical Details​

  1. Compress a program into a SNARK verifier implemented in Bitcoin Script. With Groth16, this will be about 1GB in size.
  2. Split the verifier into discrete sub-program chunks that are optimized for Bitcoin transaction size limits. These chunks are under 400kb each, eliminating the need for special miner cooperation at any step.
  3. During the setup step, each operator commits to the program by depositing collateral.
  4. Each operator continually runs the original program (e.g. a bridge) off-chain to determine the correct outputs of each input (e.g. how much BTC to withdraw and who to send it to during a bridge peg-out).
  5. The operator uses their own funds to cover the program's output (e.g. sends their own BTC to a withdrawing user), then requests a reimbursement by withdrawing funds from BitVM (i.e. the set of funds being managed by the operators).
  6. If challenged, the operator must reveal all of the intermediary program results (i.e. each of the inputs and outputs of the sub-program chunks). If the operator is cheating, at least one of the sub-program results will be fake.
  7. Anyone can disprove the operator by executing that specific sub-program in a Bitcoin transaction, showing that the operator's attempted withdrawal was invalid.
  8. The bad operator is kicked out and cannot access the BitVM funds.
Practical and Permissionless

Anyone can challenge a dishonest operator with only three Bitcoin transactions.

BitVM Bridge Summary​

One of the most exciting applications of BitVM is a BTC light-client bridge on Bitcoin. Specifically, BitVM reduces the trust assumptions needed for a safe peg-out when users want to withdraw or unwrap their BTC back to Bitcoin.

  1. Operators pay BTC to the withdrawing user from their own funds and then reclaim the BTC from BitVM.
  2. A smart contract on BOB uses the BTC relay to verify that there is a correct peg-out on Bitcoin corresponding to the withdrawal request by a user on BOB. If this check passes, a burn event on BOB is emitted.
  3. BitVM checks that there is a correct peg-out on Bitcoin matching the burn event on BOB.
  4. The operator uses the BitVM light client to create a SNARK, proving that:
    • there is a burn event on BOB that burns bobBTC,
    • the BOB block that includes the burn event was correctly created,
    • the BOB block is signed by Babylon Finality Providers (FPs) staked on Bitcoin,
    • the BOB block hash that includes the burn event is stored on the Babylon chain, and
    • the BOB block hash is part of a Babylon checkpoint on Bitcoin with at least 100 Bitcoin confirmations.
  5. If all is correct, the operator gets the BTC refunded.
  6. If the operator has committed fraud (e.g. by sending BTC to their wallet instead of the user's), the refund transaction is prevented and the operator is slashed and kicked out.

Under correct operation, the bridging process completes in less than one hour in each direction for users bridging in and out. This is much faster than existing Ethereum L1 or L2 bridges to Bitcoin.

Recent Technical Improvements​

  • Optimized Transaction Size: All transactions are under 400kb, eliminating the need for special miner cooperation. This was achieved through Fiamma's optimization of the disprove script chunk size and splitting the Assert transaction into multiple linked transactions.
  • Enhanced Security Model: Correct behavior is enforced through bit commits, following the BitVM2 standard, reducing trust assumptions compared to previous implementations.
  • Streamlined Verification: Our implementation uses hardcoded public inputs rather than checking them in complex scripts, allowing us to run unmodified RISC0 circuits.
  • Smart Contract Integration: Instead of superblock logic, additional verification is performed by BOB smart contracts using an on-chain relay, with double-checking of payments and block correctness in the prover.
  • User-Friendly Offramp: We're making it easy to convert wrapped tokens back to native bitcoin by integrating the BitVM bridge with BOB Gateway.

Common Misconceptions​

  • "BitVM" is not a virtual machine (VM) like the Ethereum Virtual Machine (EVM) or the Java Virtual Machine (JVM); it is not an execution environment for arbitrary programs. Rather, each instance of BitVM is a way to use existing tools in Bitcoin to create on-chain fraud proofs for off-chain execution of a specific, pre-determined program (e.g. a bridge or rollup).
  • In its current design, a specific BitVM instance only supports deposits and withdrawals of a fixed amount defined at setup, such as exactly 0.1 BTC. A user can only PegOut (i.e. withdraw) an amount that exactly matches a previous PegIn. A potential workaround is to create several instances of BitVM for the same purpose (e.g. bridge), each corresponding to a different PegIn size (e.g. 0.1 BTC, 1 BTC, 10 BTC).
  • The 1GB program is never put on-chain. That would require 1,000 separate transactions, each the size of an entire Bitcoin block! Instead, the setup process includes the creation of a Taproot tree that represents the relationship between the inputs and outputs of all the intermediary sub-programs. The last Tapleaf in the tree is used for the Payout transaction, enabling the operator to claim the funds if the program execution is not challenged.
  • Operators pay out using their own money, then are reimbursed by spending the UTXO from a previous PegIn after the challenge period. These settings (challenge period duration, operator capital) are what constrain the throughput of the bridge(/other collateralized program)