Understanding BitVM: The Dawn of Bitcoin's Programmability
TechFlow Selected TechFlow Selected
Understanding BitVM: The Dawn of Bitcoin's Programmability
Although BitVM is in its early stages and essentially an unimplemented concept of a virtual computer, it has already sparked significant interest and announcements from various projects.
Navigating Web3 tides with focused insightsAuthor: IOSG Ventures
*Acknowledgments: Special thanks to Momir and Xinshu for their valuable feedback and suggestions on this article
TL;DR
-
Core changes to Bitcoin are typically met with resistance due to: a) preference for Bitcoin as a store of value over a medium of exchange; b) prioritization of stability and predictability over rapid innovation; c) difficulty in achieving consensus within a diverse community.
-
Numerous projects claim to solve Bitcoin's scalability issues without modifying the base chain. Recently, we've witnessed hyperinflation in Bitcoin "L2s".
-
While many claims are misleading marketing, we recognize a new computational paradigm that could bring programmability to Bitcoin—BitVM.
-
The best scaling solution enabled by BitVM approaches the security assumptions of OP-Rollups (albeit with additional caveats).
-
The success of BitVM and similar initiatives depends on technical feasibility, community support, and differentiation from "overhyped" projects.
Bitcoin was built as a transaction blockchain, with its scripting language intentionally designed as stateless to minimize attack surface and ensure network security. Due to the lack of Turing-completeness, it is impossible to directly introduce smart contracts on-chain without forking and upgrading Bitcoin Core.
The traditional Bitcoin community resists change for several reasons:
Preference for store of value over currency: The Bitcoin community deliberately focuses on maintaining the network as a peer-to-peer payment system, prioritizing security and decentralization over rapid development. As famous Bitcoin holder Michael Saylor said: "No one tries to buy a coffee with a fraction of a building on Fifth Avenue." This reflects the community’s preference for using Bitcoin as a store of value rather than everyday currency.
-
Stability over innovation: Predictability is crucial for an asset considered a strong store of value. For example, even if the network undergoes only 10 major upgrades, each with a 90% success rate, the probability of at least one failure is approximately 65%! According to Normal Accident Theory: "In complex systems, we should expect normally negligible factors to occasionally combine and trigger major events." Therefore, the Bitcoin community aims to minimize potential points of failure.
Diverse community: Many Bitcoin holders understand Bitcoin from different perspectives and value it for different reasons. Reaching consensus within such a decentralized and diverse community is inherently challenging, further slowing innovation. The diversity can be seen in the community's reaction to inscriptions and Ordinals. While part of the community celebrates Ordinals as Bitcoin’s CryptoKitties moment, others view it as a bug that should be patched.
1. The Hyperinflation of Bitcoin Scaling Solutions
Given the above, why have so many new Bitcoin "L2" solutions suddenly emerged?
Recently, we’ve observed an explosion in Bitcoin "L2" solutions (over 50 according to https://l2.watch/). However, the community has been exploring various scalability methods for years:
-
Sidechains like Stacks offer smart contract capabilities and broad application scope, but their independent consensus mechanisms struggle to gain widespread acceptance.
-
Client-side validation projects like RGB leverage the mainnet’s UTXO model for more complex off-chain transactions, but lack stable interaction with Bitcoin mainnet.
-
State channels like the Lightning Network, closely aligned with core Bitcoin developers, are viewed as a more orthodox scaling approach.
First-generation BTC scaling solutions
What novel aspects do recent scaling approaches bring compared to existing ones? In our view, the most exciting innovations come from encoding programs on Bitcoin (via BitVM) and trustlessly staking BTC (e.g., Babylon). This article will focus primarily on the former.
2. BitVM - Overview
To explain what BitVM is, we should first introduce the primitive that empowered and inspired it—the Bitcoin Taproot upgrade.
Taproot is a major upgrade to the Bitcoin protocol activated in November 2021. With Taproot, the hash of a script is committed on-chain by default. When executing a particular path of the script, only that path needs to be revealed on-chain. This improves efficiency (transaction size does not grow with script size) and enhances privacy (only the executed path is revealed, not the entire script).
Recognizing the immense opportunities unlocked by the Taproot upgrade, Robin Linus pioneered BitVM—a breakthrough innovation in the Bitcoin ecosystem.
BitVM is a computational paradigm that leverages the Taproot upgrade to enable Turing-complete contracts on Bitcoin without changing network consensus rules. It enables verification (rather than execution) of computation, similar to Optimistic Rollups.
BitVM minimizes on-chain footprint by committing programs to a Taproot address while enabling complex off-chain computation—only requiring on-chain execution in case of disputes.
This process involves committing the binary circuit of a program to a Taproot address and using a challenge-response mechanism for verification. In summary, BitVM enables Turing-complete Bitcoin contracts, most importantly:
-
BitVM does not require a fork or any changes to the Bitcoin protocol.
-
BitVM will not congest the Bitcoin blockchain, because computation is not executed on Bitcoin—only dispute resolution uses the Bitcoin network.
Building Binary Circuits on Bitcoin
Building binary circuits is a method of representing computations or programs using binary logic gates (such as AND, OR, NOT), capable of performing any computable function.
BitVM is akin to simulating the flow of electricity through logic gates in computer chips—microscopic structures that determine whether signals pass based on presence or absence of current (on/off)—but translated into Bitcoin’s language.
Essentially, any computer program—from games to full Linux operating systems—is the result of complex arrangements of these logic gates. All digital things are fundamentally based on binary digits—0s and 1s. By combining these binary digits with logic gates (like AND and NOT), we create various circuits including arithmetic logic units (ALUs) and memory systems. This foundational technology allows us to write and execute programs for a wide range of tasks.
Source: Stepping Through Logic Gates; Basic logic gates (F stands for 0, T stands for 1)
The premise of BitVM is using Bitcoin Script to commit to off-chain computations (by submitting a hash of a computation to a Taproot address), decomposing any program into combinations of binary circuits, and enabling execution verification. This process involves Bitcoin Script, but the script itself does not execute the full computational logic.
Bitcoin Script can implement bit-value commitments, which are crucial for demonstrating and punishing equivocation. It ensures immutability by allowing individuals to commit values that others cannot modify.
This approach involves using two hashes to represent each input bit: one hash for digit 0, another for digit 1. When someone wants to execute a program, they reveal a pre-image to indicate the input. Whether the value converts to 0 or 1 is determined by comparing the hash of the pre-image against the two hashes representing 0 and 1.
If inputs and outputs do not match, verifiers have the right to penalize the provider by confiscating their funds.
Challenge-Response Mechanism
Verification typically occurs off-chain, optimistically assuming the prover is honest. In case of disputes, the process moves on-chain and initiates a round of challenge-response. This mechanism ensures that in most cases, computation and verification can proceed efficiently and at low cost, only resorting to the blockchain’s immutability and transparency for final adjudication when disagreements arise.
The challenge-response dynamics in BitVM involve a system where participants (e.g., Vicky and Paul) verify program execution via the blockchain. When a dispute arises, Vicky challenges Paul to prove correctness of his program execution.
Vicky selects a logic gate from the binary circuit, and Paul opens it by revealing its inputs and outputs. This process repeats until equivocation is confirmed or Vicky exhausts her ability to challenge further. Equivocation means Paul claims input X is 0 when opening one gate, but 1 when opening another.
Paul must secure his claimed evidence by depositing funds into a response address via pre-signed transactions. These transactions form a chain, allowing funds to swing between challenge and response addresses based on ongoing interactions.
Funds in the response address can flow along multiple paths depending on the outcome of challenges:
-
If Vicky stops challenging, indicating acceptance of Paul’s proof, Paul eventually recovers his funds after a timeout period.
-
If Vicky proves Paul was inconsistent in execution (equivocation occurred), she can claim those funds.
-
If Vicky suspects another part of execution is incorrect, she can initiate another challenge, moving funds to the next response address. To do so, she must reveal a pre-image of a specific tapleaf, which Paul then uses to unlock the funds and prove correctness within a limited timeframe.
This system provides a robust and transparent framework for resolving disputes and verifying program execution on-chain. By incorporating financial incentives, it promotes integrity and accuracy in execution and record-keeping. Initially, the design supported a two-party challenge-response mechanism. However, as we’ll later show, BitVM contributors have found ways to allow numerous participants to act as challengers.
Bisection: Improving Dispute Resolution Efficiency
To improve efficiency of on-chain verification, verifiers can use bisection—a method of efficiently searching over pre-committed logic gates to identify which gate should be challenged. This represents a significant improvement over random challenge processes. By halving the problem space repeatedly, bisection allows verifiers to quickly narrow down the scope of potential errors, reducing the number of steps and time required to resolve disputes. This method offers a more efficient and direct path, especially when handling complex verification procedures requiring precise identification of error locations.
Below, we illustrate how bisection works through a simplified example:
Paul and Vicky are solving a math problem: calculate ((1+2)+(3+4))+((5+6)+(7+8)).
The correct way to compute this is ((1+2)+(3+4))+((5+6)+(7+8)) = (3+7)+(11+15) = 10+26 = 36.
But Paul gives the answer 35, because he computes it as ((1+2)+(3+4))+((5+6)+(7+8)) = (2+7)+(11+15) = 9+26 = 35.
When Vicky challenges Paul, she only needs to challenge the first part involving calculation (i.e., open the relevant logic gate), since they agree the second part ((5+6)+(7+8)) = 26 is correct.
3. Building a Trust-Minimized Bridge Using BitVM
The first practical implementation of BitVM will likely be a program representing a trust-minimized Bitcoin bridge. By analyzing details of bridge implementation, we can better understand the additional complexities involved in realizing BitVM programs. Below, we summarize a proposal by Alexei Zamyatin, co-founder of BoB.
First, a method must be created for Bitcoin full nodes to operate a sidechain bridge program—including a light client for the sidechain—using only Bitcoin Script.
Additionally, a federation/multi-sig network must be established to facilitate BTC transfers and run the challenge-response game. The federation must commit to running the bridge program as part of the BitVM setup.
The complexity of initial federation setup grows quadratically with the number of members, as each member must interact with every other member. Thus, there is a practical upper limit on federation size—researchers speculate N=100 is feasible.
Unlike OP Rollups, which impose no limits on N, this scheme offers weaker security guarantees. However, the proposed working solution may include rotation of federation members, meaning that over a long time horizon, N would effectively be much larger than 100. At any time, deposits remain secure as long as at least one of the 100 members is honest. Malicious actors can be challenged on-chain at any time and expelled from the federation if proven cheating.
At any given time, the federation has an operator responsible for managing deposits and withdrawals and verifying sidechain state. Both operators and watchtowers must post collateral to incentivize correct behavior and deter frivolous challenges.
Another reason this scheme does not meet the strictest definition of rollups is that users cannot unilaterally exit the sidechain—they must request withdrawals from the federation operating under a 1/N security assumption.
4. BitVM v2: Can BitVM Support Permissionless Verification?
On March 25, Robin Linus introduced BitVM v2. The key change in the BitVM v2 proposal is that the prover must commit all output states and intermediate results upfront, rather than opening logic gates one by one during the challenge-verification process as in v1. With this change, BitVM ensures that any challenge to these commitments must be backed by cryptographic evidence. This mechanism filters out baseless spam challenges, as challengers must provide specific cryptographic proofs to dispute the prover.
By allowing unlimited participation in verification and challenge processes, BitVM v2 extends its security guarantees beyond the limits of multi-sig federations, bringing BitVM closer to the security assumptions of Optimistic Rollups.
However, bridge construction still requires a federation multi-sig to facilitate operations, meaning federation members could cause liveness issues—in the worst case, attempting to extort ransom from users to unfreeze their funds. This introduces an additional security assumption not present in Optimistic Rollups, where users can exit to L1 without approval from any intermediary.
Additional security assumptions on the base chain
5. Limitations of BitVM
As discussed above, the best security model BitVM can achieve approaches that of Optimistic Rollups. Beyond the complexity of managing federated deposit insurance and associated liveness concerns, additional BitVM-specific complexities include:
Although BitVM theoretically supports complex off-chain programs, in practice, as program complexity increases, the associated costs of executing fraud proofs on Bitcoin rise rapidly. Excessively large programs may require multiple blocks for execution, further complicating the process.
Mining pools holding majority hash power could steal from BitVM (similar to Lightning Network vulnerabilities), either by colluding to censor challengers’ proofs or being bribed by malicious actors to ignore challenges.
Due to the interactive nature of BitVM proofs, malicious provers may manipulate the system and steal from verifiers. An attack could be structured as follows:
-
The prover starts the verification sequence by initiating a transaction
-
A verifier suspecting invalid prover behavior initiates a challenge containing fees payable to the prover upon response
-
The prover collects the fee while ignoring the challenge, failing to fulfill their obligations in the verification process
Finally, BitVM remains currently a conceptual framework—an almost non-functional virtual machine concept. BitVM "rollups" are far from application-level readiness. At an optimistic estimate, we might see some BitVM programs deployed as early as 2025. The technical risks of implementing BitVM are also non-trivial.
6. Conclusion
Considering valuations of Ethereum scaling solutions, currently around 15–20% of Ethereum’s market cap, the potential market capitalization of Bitcoin Layer 2 solutions could be enormous.
Despite BitVM being in its infancy—essentially an unrealized virtual machine concept—it has already sparked significant interest and announcements from various projects eager to leverage its potential. Numerous projects unrelated to the BitVM team are rushing to make grand announcements, hoping to stake a claim in what they perceive as a promising new frontier for Bitcoin. However, closer scrutiny reveals a more sobering reality: the BitVM GitHub account has only a handful of contributors, and only a few Bitcoin "L2" projects are actively participating in the BitVM Builders Telegram group.
A key principle that any Bitcoin scalability solution must follow is that Bitcoin’s core architecture should remain unchanged (in accordance with the predictability principle). BitVM adheres to this principle, becoming the first pioneering solution to provide a programmable layer atop Bitcoin without altering its core.
This article is written at a very early stage of BitVM development. Given its rapid evolution, the information here may quickly become outdated. For instance, until recently, the idea of implementing ZK rollups on Bitcoin seemed as impractical as pie in the sky, because the necessary foundational capabilities—such as Bitcoin’s ability to verify ZK proofs—did not exist. Yet, recently BitVM researchers shared progress in Bitcoin Script that could lead to STARK verifiers on Bitcoin.
Implementing Bitcoin scaling solutions goes beyond pure technical challenges—it encompasses community support, user experience, and timing. While the current moment presents a unique window of opportunity for these innovations, the rapid inflation in project numbers and significant risks from misleading claims and marketing could undermine the prospects of more legitimate projects.
As the ecosystem stands at this crossroads, the question of whether Bitcoin scaling solutions can replicate Ethereum’s success is not merely technical, but deeply rooted in broader dynamics within the blockchain community. After all, the core Ethereum community has already embraced L2s as a key part of Ethereum’s scaling roadmap—something that cannot yet be said for the Bitcoin community.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
IOSG Ventures
