BitVM and the bridge problem

Wonder

1. How can Bitcoin enforce the result of an arbitrary calculation without executing the code on-chain?
2. Why does a challenge-response game built from Taproot scripts allow for near-Turing-complete verification with no soft fork?
3. What is the security trade-off when liveness depends on someone watching to challenge a fraudulent claim?

Explore

Part IBitVM

1. Bitcoin’s consensus rules intentionally exclude arbitrary code execution. This design prevents complex smart contract vulnerabilities but limits scripts to conditions such as signatures, multisig, timelocks and hashlocks. In October 2023, Robin Linus introduced BitVM, a protocol that enables off-chain computations while keeping the final result verifiable on-chain. It allows parties to lock bitcoins in a transaction where spending depends on an external calculation performed outside the blockchain.
2. The core mechanism replicates a NAND logic gate using Bitcoin’s existing opcodes: OP_BOOLAND acts as an AND gate, and OP_NOT acts as a NOT gate. Since NAND gates are universal, circuits built from them can in principle express any computation, all without changing consensus rules. This approach shifts the computational burden off-chain while maintaining on-chain security.
3. These complex NAND computation sequences are stored as leaves within the Merkleized Abstract Syntax Tree (MAST) of a Taproot transaction. This leverages the privacy and efficiency gains from Taproot, which activated in November 2021 at block 709,632, allowing complex scripts to remain hidden until needed. The structure supports the large script trees required for multi-step verification games.
4. If the prover claims a fraudulent result from the off-chain computation, the verifier can challenge it on-chain. The prover must then answer the challenge; if a step is shown to be inconsistent or the prover fails to respond in time, the verifier takes the locked funds. This ‘optimistic’ verification model shifts most work off-chain while maintaining security through the threat of dispute.
5. The first version worked between two parties, but BitVM2 (2024) allows anyone to challenge a claim, moving toward permissionless verification. The main target is trust-minimized bridges, where bitcoin locked on-chain can be released only if a claimed state of another system is valid.
6. The primary limits are heavy setup, large off-chain data requirements, and liveness assumptions. Someone must be actively watching to challenge fraudulent claims within the required timeframe; if no one does, an incorrect state may be finalized. This trade-off between decentralization and operational overhead defines the current practical boundaries of BitVM implementations.

Part IIBitVM and the bridge problem

7. Bitcoin’s consensus rules verify signatures and UTXO validity but cannot execute arbitrary off-chain state transitions. Moving value to a layer two requires a bridge that anchors the external chain’s state to Bitcoin. Traditional bridges rely on federations of signers; if the majority colludes, users lose their funds. This centralized trust model contradicts Bitcoin’s permissionless design, creating a need for mechanisms that minimize custodial risk without altering consensus rules.
8. Robin Linus introduced BitVM in October 2023, demonstrating how arbitrary computation can be verified on-chain through optimistic challenge games. The protocol breaks down complex logic into bitwise operations, specifically NAND gates, which are universal for digital circuits. These operations are encoded within the MAST structure of a Taproot transaction. Bitcoin does not execute the full program; instead, it verifies the correctness of individual steps only if a dispute is raised.
9. BitVM operates on an optimistic assumption: computations are correct by default unless proven otherwise. If an operator submits an invalid state transition, another participant can submit a counter-proof to challenge it. This shifts the trust model from a trusted federation to a 1-of-n honesty assumption. At least one honest validator must exist to catch fraud. While this reduces collusion risk compared to federations, it requires someone to keep watching and to be ready to pay for a challenge.
10. The mechanism incurs significant costs. Operators front their own capital to pay out withdrawals and reclaim it later, tying up liquidity. Challenge transactions are large due to the complexity of bitwise proofs, consuming considerable block space. Furthermore, many implementations use fixed peg amounts to simplify state management, limiting flexibility. These constraints mean that while BitVM is trust-minimized, it is not trustless; users still rely on the economic incentives and technical correctness of the challenge protocol.
11. Recent developments like BitVM2 refine these challenges, reducing transaction sizes and improving efficiency. Projects such as Citrea build rollups using this framework, aiming for security guarantees where a single honest party can prevent fraud. However, the bridge problem persists: Bitcoin cannot natively interpret other chains’ state roots. The bridge is a game with incentives built on top of Bitcoin, not something Bitcoin itself enforces. Users must weigh the reduced collusion risk against the increased complexity and capital requirements.
12. Inspecting a BitVM-based transaction reveals its structure. Open a block explorer and locate a Taproot output associated with a rollup bridge. Taproot hides unused script paths, so only the path actually spent is revealed; in a dispute, that path carries far more witness data than a simple signature. This tangible difference in transaction weight reflects the computational overhead of maintaining optimistic security on Bitcoin’s fixed block space.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• R. Linus, 'BitVM: Compute Anything on Bitcoin' (October 2023)
• R. Linus et al., 'BitVM2: Bridging Bitcoin to Second Layers' (2024)
• Bitcoin Optech, 'Accountable Computing Contracts' topic page (BitVM)
• Citrea Clementine bridge documentation
• BIP-341: Taproot