IOSG Ventures: Detailed explanation of BitVM, the dawn of Bitcoin programmability
Original author: IOSG Ventures
*Acknowledgments: Thanks to Momir and Xinshu for their valuable revisions to the article.
TL;DR
Changes to Bitcoin Core are often met with resistance for reasons including: a) People prefer Bitcoin as a store of value rather than as a currency. b) Value stability and predictability over rapid innovation. c) Building consensus within a diverse community is difficult.
Many projects claim to have ways to solve Bitcoins scalability issues without requiring changes to the Bitcoin chain itself. Recently we have witnessed the hyperinflation of Bitcoin “L2s”.
While many of the claims were simply misleading marketing, we also recognized a new computing paradigm that could bring programmability to Bitcoin – BitVM.
The best scaling solution that BitVM can support is close to OP-Rollup type security assumptions (albeit with some additional considerations).
The success of BitVM and similar initiatives depends on technical feasibility, community support, and differentiation from other over-marketed projects.
Bitcoin is built as a transactional blockchain, and its scripting language is intentionally stateless to minimize the attack surface and ensure network security. Due to the lack of Turing-completeness, it is not possible to directly introduce smart contracts on the blockchain, except by forking and upgrading Bitcoin Core.
The traditional Bitcoin community has been resistant to change for the following reasons:
The narrative focuses more on a store of value than a circulating currency: the Bitcoin community intentionally focuses on maintaining the network as a peer-to-peer payment system, prioritizing security and decentralization over rapid development. As noted Bitcoiner Michael Saylor said, “No one is trying to use a fraction of a building on Fifth Avenue to buy a cup of coffee.” This quote reflects the community’s commitment to Bitcoin as a store of value. Tools rather than everyday currencies.
System stability trumps innovation: For an asset to be considered an excellent store of value, predictability is crucial. For example, even if the network only has 10 major upgrades, and each upgrade has a 90% success rate, the probability of a failure occurring is approximately 65%! According to the normal accident theory: In complex systems, we should expect that small factors that are usually negligible will occasionally lead to major events by accident. Therefore, the goal of the Bitcoin community has always been to reduce the number of potential errors.
Diverse community: Many Bitcoin holders understand Bitcoin from different perspectives and value it for different reasons. Reaching consensus in a diverse and decentralized community is inherently challenging, further slowing the pace of innovation. To illustrate the diversity of the Bitcoin community, look at the community’s response to Inscriptions and Ordinals. While one part of the Bitcoin community celebrates the success of ordinal numbers as Bitcoin’s CryptoKitties moment, another part of the community believes it’s a vulnerability that should be patched.
1. Rapid expansion of Bitcoin expansion plans
Given the above, why are there suddenly a plethora of new Bitcoin “L2” solutions?
Recently, we have observed a proliferation of Bitcoin “L2” solutions (already over 50 according to https://l2.watch/!), however, the community has been exploring different scalability methods for years:
Sidechains like Stacks offer smart contract capabilities and a wide range of applications, but although they have independent consensus mechanisms, these mechanisms have struggled to gain widespread acceptance.
Client-side verification projects like RGB utilize the mainnets UTXO model for more complex transactions off-chain, but their interaction with the Bitcoin mainnet lacks stability.
State channels like the Lightning Network, which are closely associated with core Bitcoin developers, are seen as a more orthodox scaling method.
The first generation BTC expansion solution
What novelties do recent scaling methods bring compared to existing solutions? In our opinion, the most exciting innovations come from coding programs on top of 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 enables and inspires it - the Bitcoin Taproot upgrade.
Taproot is a major upgrade to the Bitcoin protocol, activated in November 2021. With Taproot, the script’s hash needs to be committed on-chain by default. When a certain path of the script is executed, only the script on that path is submitted to the chain. This not only improves efficiency (the size of the transaction does not grow with the size of the script), but also enhances privacy (only the path that is the transaction is exposed, not the entire script).
Recognizing the huge opportunity unlocked by Taproot upgrades, Robin Linus pioneered BitVM, a groundbreaking innovation in the Bitcoin ecosystem.
BitVM is a computing paradigm that leverages Taproot upgrades to facilitate the implementation of Turing-complete contracts on Bitcoin without changing the network consensus rules. It allows verification (rather than execution) of computations, similar to Optimistic Rollups.
BitVM minimizes the on-chain footprint by submitting programs to the Taproot address while enabling complex off-chain computations that only require on-chain execution in the event of a dispute.
The process involves submitting the programs binary circuit at a Taproot address and verifying it using a challenge-response mechanism. In a nutshell, BitVM implements a Turing-complete Bitcoin contract, most importantly:
BitVM does not require a fork or any changes to the Bitcoin protocol.
BitVM does not congest the Bitcoin blockchain because computations are not performed on Bitcoin, but only verified using the Bitcoin network in the event of a dispute (Dispute).
Building binary circuits on Bitcoin
Binary circuit construction 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 like translating the complex simulation of electricity flowing through a computer chips logic gates (these tiny structures that determine whether a signal passes, on or off, on or off, depending on the presence or absence of electricity), into the language of Bitcoin.
Essentially, any computer program, from games to full Linux operating systems, is the result of a complex arrangement of these logic gates, and all digital things are basically based on binary numbers - 0s and 1s. By combining these binary numbers with logic gates such as AND and NOT gates, we create a variety of circuits, including arithmetic logic units (ALUs) and memory systems. This fundamental technology enables us to write and execute programs to perform a wide range of tasks.
Source: Stepping Through Logic Gates; basic logic gates (F represents 0, T represents 1)
The premise of BitVM is to use Bitcoin Script to commit to off-chain calculations (submitting a calculated hash to a Taproot address) by deconstructing any program into a combination of binary circuits and enabling execution verification. The process includes the Bitcoin script, but the script itself does not execute the entire calculation logic.
Bitcoin Script implements bit-value commitments, which are critical to being able to demonstrate and punish equivocation. It implements immutability because it allows individuals to submit values that cannot be modified by others.
This method involves using two hashes to represent each input bit: one hash for the number 0 and another for the number 1. When someone wishes to execute a program, they reveal a pre-image to indicate the input. Whether the value will be converted to 0 or 1 is determined by comparing the hash value of the preimage with the two hash values representing 0 and 1.
If inputs and outputs do not match, the validator has the right to punish the provider by confiscating the providers funds.
Challenge-Response Mechanism
Verification is usually done off-chain, with the optimistic assumption that the prover is honest. In the event of a dispute, the process moves on-chain and a challenge-response round is initiated. This mechanism ensures that calculations and verifications can be performed efficiently and cost-effectively in most cases, with final adjudication taking advantage of the immutability and transparency of the blockchain only when disagreements arise.
The dynamics of the challenge-response mechanism in BitVM involves a system where participants (such as Vicky and Paul) undergo a verification process through the execution of programs on the blockchain. When controversy arises, Vicky challenges Paul to prove the correctness of his program execution.
Vicky selects a logic gate from a binary circuit and Paul opens the gate by revealing the inputs and outputs. The process repeats until the ambiguity is confirmed or Vicky exhausts the possibility of further challenges. Vagueness means that Paul claims that a certain input X is 0 when one logic gate is open, but is 1 when another logic gate is open.
Paul needs to secure proof of his claim by depositing funds to the responding address using a pre-signed transaction. These transactions create a chain that allows funds to swing between challenge and response addresses based on ongoing interactions.
Funds from the responding address can flow along multiple paths depending on the outcome of the challenge:
If Vicky stops the challenge, indicating acceptance of Pauls proof, Paul will eventually regain the funds after a certain period of time.
If Vicky proves that Paul was inconsistent in his execution (equivocation occurred), she can claim those funds.
If Vicky suspects another part of the execution is in error, she can launch another challenge to move the funds to the next responding address. To do this, she must reveal a preimage of a specific tapleaf, which Paul then needs to use to unlock the funds and prove his correctness within a limited time.
This system provides a solid and transparent framework for dispute resolution and verification process execution on the blockchain. By incorporating financial incentives, it promotes completeness and accuracy in execution and recording of program results. Initially, the design supported a two-party challenge-response mechanism. However, as we will show later, BitVM contributors have found solutions that allow numerous actors to participate as challengers.
Bisection: Improving the efficiency of dispute resolution
To improve the efficiency of on-chain verification, verifiers can take advantage of bisection, a method of efficiently searching on pre-submitted logic gates to find logic gates that should be challenged. This method is better than random The challenge process has been significantly improved. By splitting the problem space in two, partitioning allows validators to quickly narrow down the scope of potential errors, thereby reducing the steps and time required to resolve disputes. This method provides a more efficient and direct path when dealing with complex verification processes, especially when the location of errors needs to be accurately determined.
Below, we use a simplified example to illustrate how the segmentation method works:
Paul and Vicky are doing a math problem. The question is to calculate (( 1+ 2)+( 3+ 4))+(( 5+ 6)+( 7+ 8)).
The correct way to complete this calculation is (( 1+ 2)+( 3+ 4))+(( 5+ 6)+( 7+ 8)) = ( 3+ 7)+( 11+ 15) = 10+ 26 = 36.
The answer given by Paul is 35, because his calculation method is (( 1+ 2)+( 3+ 4))+(( 5+ 6)+( 7+ 8)) = ( 2+ 7)+( 11+ 15) = 9+ 26 = 35.
When Vicky challenges Paul, she only has to challenge the calculation involving the first part of the calculation (i.e. opening the logic gate) because they agree that the second part of the calculation is accurate (( 5+ 6)+( 7+ 8)) = 26 .
3. Use BitVM to build a minimum trust bridge (Trust-Minimized Bridge)
The first practical implementation of BitVM is likely to be a program that represents a minimum trust Bitcoin bridge. By analyzing the implementation details of the bridge, we can better understand the additional complexity of implementing a BitVM program. Below, we summarize the proposal of BoB co-founder Alexei Zamyatin.
First, a method needs to be created that allows Bitcoin full nodes to operate a sidechain bridge program using only Bitcoin scripts, including a sidechain light client.
Then, a federation/multi-sig network needs to be established to facilitate the transfer of BTC and run challenge-response games. Alliances must commit to running the bridge program as part of the BitVM setup.
The complexity of the initial setup of the alliance grows quadratically with the number of members, because each member of the alliance must interact with every other member, so there is a certain upper limit to the size of the alliance, and the researchers speculate that N = 100 is feasible.
Unlike OP Rollup, which has no limit on the size of N, this scheme provides weaker security guarantees. However, this proposed working solution will most likely include rotation of coalition members such that N will be much larger than 100 over a longer time horizon. As long as one of the 100 members is honest at any time, the deposit remains safe. Assuming there are malicious actors, they can be challenged at any time on the chain, and if proven cheating, they can be banned from the alliance.
At any time, the alliance has an operator (Operators) who is responsible for managing deposits and withdrawals and verifying the status of the sidechain. Both operators and watchtowers are required to submit collateral to incentivize correct behavior and deter false challenges.
Another reason why this scheme does not meet the strictest definition of convolution is that users cannot unilaterally exit the sidechain, but must request withdrawals from the consortium, which operates on the 1/N security assumption.
4. BitVM v2: Can BitVM support permissionless verification (Permisionless Verification)?
On March 25, Robin Linus introduced BitVM v2. The key change in the BitVM v2 proposal is that the prover needs to submit the output state and all intermediate results all at once, instead of opening logic gates one by one during the challenge-verification process like v1. With this change, BitVM ensures that any challenge to these commitments must be supported by cryptographic evidence. This mechanism filters out unwarranted spam challenges because the challenger must provide a specific cryptographic proof to dispute the prover.
By allowing unrestricted participation in the verification and challenge process, BitVM 2 extends its security guarantees beyond the limitations of multi-signature federation and brings BitVM closer to the security assumptions of optimistic convolution.
However, the bridge still needs to be facilitated by consortium multi-signatures, meaning consortium members can cause liveness issues and, in the worst-case scenario, attempt to hold users to ransom to unfreeze their funds. This is an additional safety assumption that does not exist for optimistic convolutions, since in optimistic convolutions the user can exit to L1 without any intermediary approval.
Additional security assumptions on the base chain
5. Limitations of BitVM
As we discussed above, the best BitVM can offer is a safe assumption close to optimistic convolution. In addition to the complexity of managing the consortium responsible for insuring deposits and its liveness issues, some additional complexities unique to BitVM include:
While BitVM is theoretically capable of executing complex off-chain programs, in practice, as the complexity of these off-chain programs increases, the fees associated with executing fraud proofs on Bitcoin increase rapidly. Overly large programs may require multiple blocks to execute, further complicating the process.
Mining pools with a hashrate majority can steal from BitVM (similar to the problem with the Lightning Network) because they can collude to censor challenger proofs, or malicious actors can bribe them to ignore challengers.
Due to the interactive nature of BitVM proofs, malicious provers may manipulate the system and steal from validators. The attack can be constructed based on the following assumptions:
The prover starts the verification sequence by initiating a transaction
A verifier who doubts the validity of a provers actions initiates a challenge that includes a response fee paid to the prover
The prover chooses to collect fees while ignoring the challenge and not fulfilling their part in the verification process
In the end, BitVM is currently a conceptual framework and a virtual computer concept that can do almost nothing. BitVMs convolution is still far from the application level. Optimistic estimates are that we may see some BitVM programs put into use as early as 2025. The technical risks of implementing BitVM cannot be underestimated.
6 Conclusion
Considering the valuation of Ethereum scaling solutions, which currently account for approximately 15-20% of Ethereum’s market capitalization – the potential market capitalization of Bitcoin’s second layer solutions could be huge.
Although BitVM is still in its infancy - essentially an unfinished virtual computer concept - it has already sparked a lot of interest and announcements from various projects eager to exploit its potential. Many projects not affiliated with the BitVM team are rushing to make grand announcements in hopes of carving out a niche in what they see as a promising new frontier for Bitcoin. However, closer scrutiny reveals a more sobering reality: BitVM’s GitHub account has only a handful of contributors, and only a handful of Bitcoin “L2” projects are actually participating in the BitVM Builders Telegram group.
A key principle that any scalability solution for Bitcoin must adhere to is that Bitcoin’s core architecture should remain unchanged (according to the Predictability Principle). BitVM embraces this principle and becomes the first pioneering solution to provide a programmable layer on top of Bitcoin without changing its core.
This article was written in the very early stages of BitVMs development, and given its rapid development, the information here may quickly become out of date. For example, until recently, the idea of implementing ZK convolutions on Bitcoin seemed like a castle in the air because the required underlying capabilities—such as Bitcoin’s ability to verify ZK proofs—did not exist. Recently, however, BitVM researchers shared advances in Bitcoin scripts that could lead to the implementation of a STARK validator on Bitcoin.
Implementing a Bitcoin scaling solution goes beyond purely technical challenges; it encompasses factors such as community support, user experience, and timing. While the current moment offers a unique window of opportunity for these innovations, rapid inflation in the number of projects and the significant risks posed by misleading claims and marketing could undermine the prospects for more legitimate projects.
As the ecosystem stands at this crossroads, the question about whether Bitcoin scaling solutions can replicate Ethereum’s success is not only technical, but deeply rooted in the broader dynamics of the blockchain community. After all, the core Ethereum community has chosen L2 as a key part of Ethereum’s scaling roadmap, while the same can’t be said for the Bitcoin community yet.
