# Introduction The white paper of BitVM was released on October 9, 2023, sparking widespread discussions upon its release. BitVM is a computational paradigm designed for expressing Turing-complete Bitcoin contracts without the need for any changes to the network consensus rules. However, the current BitVM technology is still in the experimental stage and has not gained widespread adoption. Information about it is scattered, and although the [BitVM Chinese community ](https://twitter.com/Bitvm_cn)has organized some relevant materials, there is no systematic organization in the English community. Therefore, BitVM Club has decided to take on this task. The first version of the knowledge base is based on the extension of the[ Github code repository ](https://github.com/Rsync25/awesome-bitvm)by [@Rsync25](https://twitter.com/Rsync25), for which we are greatly appreciated. It is hoped that the knowledge base organized by BitVM Club can help more people understand BitVM. Additionally, there is a hope that BitVM technology can make Bitcoin more flexible and intelligent. The largest Telegram group for the BitVM is [BitVM Builders](https://t.me/bitVM_chat). We also welcome you to join the [BitVM Club Telegram](https://t.me/bitvm_club) group and follow us on [Twitter](https://twitter.com/Bitvmclub). > The original intention of BitVM Club is to focus on BitVM technology, aiming to encompass more BTC Layer 2 projects, and enable a broader audience to understand BitVM technology and the BTC ecosystem. > > The community operates independently and has received donations from [Bitlayer](https://twitter.com/BitLayerLabs). We hope to receive more project donations. > > If you are interested in making donations, please contact us at . Your support is greatly appreciated! Thank you!

# BitVM Whitepaper PDF {% embed url="" %} # BitVM Whitepaper Word ## BitVM: Compute Anything on Bitcoin Robin Linus [www.bitvm.org](http://www.bitcoin.org/) 2023.12.12 **Abstract** BitVM is a computing paradigm to express Turing-complete Bitcoin contracts. This requires no changes to the network's consensus rules. Rather than executing computations on Bitcoin, they are merely verified, similarly to optimistic rollups. A prover makes a claim that a given function evaluates for some particular inputs to some specific output. If that claim is false, then the verifier can perform a succinct fraud proof and punish the prover. Using this mechanism, any computable function can be verified on Bitcoin. Committing to a large program in a Taproot address requires significant amounts of off-chain computation and communication, however the resulting on-chain footprint is minimal. As long as both parties collaborate, they can perform arbitrarily complex, stateful off-chain computation, without leaving any trace in the chain. On-chain execution is required only in case of a dispute. ## 1 Introduction By design, the smart contract capabilities of Bitcoin are reduced to basic operations, such as signatures, timelocks, and hashlocks. The BitVM creates a novel design space for more expressive Bitcoin contracts and also off-chain computation. Potential applications include games like Chess, Go, or Poker, and particularly, verification of validity proofs in Bitcoin contracts. Additionally, it might be possible to bridge BTC to foreign chains, build a prediction market, or emulate novel opcodes. The main drawback of the model proposed here is that it is limited to the two-party setting with a prover and a verifier. Another limitation is that, for both the prover and the verifier, significant amounts of off-chain computation and communication is required to execute programs. However, these issues seem likely to be solved by further research. In this work, we focus solely on the key components of the two-party BitVM. ## 2 Architecture Similar to Optimistic Rollups\[1] and the MATT proposal (Merkelize All The Things)\[2], our system is based on fraud proofs and a challenge-response protocol. However, BitVM requires no changes to Bitcoin's consensus rules. The underlying primitives are relatively simple. It's mostly based on hashlocks, timelocks, and large Taproot trees. The prover commits to the program literally bit-by-bit, however verifying all of that on-chain would be too computationally expensive, so the verifier performs a sequence of carefully crafted challenges to succinctly disprove a false claim of the prover. Prover and verifier jointly pre-sign a sequence of challenge-and-response transactions, which they can later use to resolve any dispute. The model is designed to simply illustrate that this approach allows for universal computations on Bitcoin. For practical applications we should consider more efficient models. The protocol is simple: Firstly, prover and verifier compile the program into a huge binary circuit. The prover commits to that circuit in a Taproot address which has a leaf script for every logic gate in the circuit. Additionally, they pre-sign a sequence of transactions, enabling a challenge-response game between the prover and the verifier. Now they have exchanged all of the required data, so they can make their on-chain deposits to the resulting Taproot address. This activates the contract and they can start exchanging off-chain data to trigger state changes in the circuit. If the prover makes any incorrect claim, the verifier can take their deposit. This guarantees attackers always lose their deposits. ## 3 Bit Value Commitment The bit value commitment is the most elementary component of the system. It allows the prover to set the value of a particular bit to either "0" or "1" . Especially, it allows the prover to set the value of a variable across different Scripts and UTXOs. This is key, as it extends the execution runtime of Bitcoin's VM by splitting it across multiple transactions. Similar to Lamport signatures\[3], the commitment contains two hashes, hash0 and hash1. At some later point, the prover sets the bit's value either to "0" by revealing preimage0, the preimage of hash0 – or the prover sets the bit's value to "1" by revealing preimage1, the preimage of hash1. If, at some point, they reveal both preimages preimage0 and preimage1, then the verifier can use them as a fraud proof, and take the prover's deposit. That is called equivocation. Being able to punish equivocation is what makes the commitment binding – it is an "incentive-based commitment" . Combining bit value commitments with timelocks allows the verifier to force the prover to decide the value of a particular bit within some given time frame.
Figure 1: A concrete implementation for a 1-bit commitment. To unlock this script, the prover has to reveal either the preimage of hash0 or of hash1. In this example execution, the prover reveals hash1, and sets the bit's value to "1" . We can have copies of this commitment to enforce a specific value across different scripts. For simplicity, from here on, we assume there's an opcode OP BITCOMMITMENT,![](file:////private/var/folders/ch/tj276n357zqcmmrrb4h599x40000gp/T/com.kingsoft.wpsoffice.mac/wps-frankmiao/ksohtml//wps16.jpg) which is shorthand for the script above. The opcode consumes two hashes and a preimage of one of the hashes. It puts a bit value on the stack, according to which hash is matched by the preimage. ## 4 Logic Gate Commitment Any computable function can be represented as a Boolean circuit. The NAND gate is a universal logic gate, so any Boolean function can be composed from them. To keep our model simple, we show that our method works for simple NAND gates. Additionally, we show how to compose gates arbitrarily. Together this demonstrates BitVM can express any circuit. The implementation of a NAND gate commitment is simple. It contains two bit commit- ments representing the two inputs and a third bit commitment representing the output. The Script computes the NAND value of the two inputs to ensure that it matches the committed output bit.
Figure 2: Logic gate commitment for a NAND operation. Executing this script requires to reveal values for the bit commitments A, B, and C, such that A NAND B = C holds. (Here, we assume for simplicity, that an opcode for OP\_NAND exists . Actually it does not exist, however, it can be easily implemented using OP\_BOOLAND and OP\_NOT.) ## 5 Binary Circuit Commitment In the previous section we defined NAND gate commitments. We can express any circuit by composing gate commitments. Every step of the execution is committed to in a Tapleaf. They're are all combined into the same Taproot address, such that the prover could execute any gate in the circuit. Executing a gate requires the prover to open the corresponding gate commitment and set values for its inputs and output bits. The Taptree might become huge and have a billion Tapleaf Scripts, but its on-chain footprint is minimal.
Figure 3: A random example circuit which has 8 different NAND gates, and 4 inputs A,B,C, and D. Using billions of gates would allow us to define basically any function.
Figure 4: For each gate, the prover's Taproot address contains a leaf script with a corresponding gate commitment. This allows the prover to set the values of the circuit's inputs, (here, A,B ,C, and D), at any point later in time. ## 6 Challenges and Responses Committing to a circuit is not enough. To disprove an incorrect claim, the verifier has to be able to challenge the prover's statement. This is possible by them pre-signing a sequence of transactions during setup. The transactions are linked like challenge → response → challenge → response → .... If one of the parties stops engaging then, after some timeout, the other party wins the challenge and can take both deposits. As long as both parties are cooperative, they can jointly settle any contract with a 2-of-2 signature. The following mechanism is required only in case of fraud.
Figure 5: A pre-signed sequence of transactions to perform multiple rounds of challenge-and-response. This sequence is generated during setup. Vicky chooses a challenge by opening one of the hashlocks in her Tapscript leaves. This unlocks for Paul a specific Tapscript and forces him to execute it. The script forces Paul to reveal the gate commitment challenged by Vicky. Any inconsistent claim can be disproven quickly by repeating this procedure for a few rounds of queries. If the prover stops collaborating with the verifier off-chain, the verifier needs a way to force his hand on-chain. The verifier does this by unlocking a hashlock: each of the NAND Tapleaves in the prover's UTXO can only be spent if the prover knows a preimage held by the verifier. Therefore, the prover can prove that a given Tapleaf executes correctly by revealing its inputs and outputs, but only if the verifier "unlocks" it for him by revealing the preimage to the hash that guards that Tapleaf. Applying binary search, the verifier can quickly identify the prover's error after just a few rounds of challenge-and-response.
Figure 6: After each response, Vicky can punish equivocation. If Paul ever reveals two conflicting values for a variable, then Vicky immediately wins the challenge and is allowed to take his deposit. Vicky proves Paul's equivocation by revealing for any of his bit commitments both of the preimages. ## 7 Inputs and Outputs The prover can set inputs by revealing the corresponding bit commitments. Ideally, they reveal the commitments off-chain to minimize their on-chain footprint. In the noncooperative case the verifier can force the prover to reveal their inputs on-chain. It is possible to process large amounts of data by exchanging it upfront, but encrypted. This way the prover can reveal the decryption key at a later point in time. Multi-party inputs are also possible. Gates can have bit commitments from both parties. ## 8 Limitations and Outlook It is inefficient to express functions in simple NAND circuits. Programs can be expressed more efficiently by using more high-level opcodes. E.g., Bitcoin script supports adding 32-bit numbers, so we need no binary circuit for that. We could also have larger bit commitments, e.g. it is possible to commit to 32 bits in a single hash. Additionally, scripts can be up to about 4 MB in size. Thus, we can implement substantially more than a single NAND instruction per leaf script. The model proposed here is limited to two parties. However, it might be possible to have two-way channels, and chain them to form a network similar to Lightning. Exploring the two-party setting might yield interesting possibilities for generalization. For example, we can explore a 1-to-n star topology for the network. Another research question is if we can apply our model to the n-of-n setting and create more sophisticated channel factories. Furthermore, we could combine our system with different off-chain protocols, e.g., the Lightning Network or rollups. Other directions of research include cross-application memory, how to make statements about arbitrary data inscribed into the chain, or off-chain programmable circuits, i.e. an off-chain VM. It also might be possible to apply more sophisticated sampling techniques, similar to STARKs, to check a circuit in a single round. The next major milestone is to complete a design and an implementation of a concrete BitVM and also of Tree++, a high-level language to write and debug Bitcoin contracts. ## 9 Conclusion Bitcoin is Turing-complete in the sense that encoding fraud proofs in large Taptrees allows to verify the execution of any program. A major constraint of the model outlined here is that it is limited to the two-party setting. Hopefully, this can be generalized in further works. ## Acknowledgments Special thanks to Super Testnet and Sam Parker, who always kept refusing to believe that Bitcoin would not be Turing-complete. ## References \[1] Ethereum Research. Optimistic rollups. docs/scaling/optimistic-rollups/, 2022. \[2] Salvatore Ingala. Merkleize all the things. pipermail/bitcoin-dev/2022-November/021182.html, 2022. \[3] Jeremy Rubin. CheckSigFromStack for 5 Byte Values. 2021/07/02/signing-5-bytes, 2021.
Sponsor BitVM developers: bc1qf5g6z0py2t3t49gupeqrlewga0qz2etalu4xf9 # BitVM Introduction ### About BitVM is a computing paradigm to express Turing-complete Bitcoin contracts. This requires no changes to the network’s consensus rules. Committing to a large program in a Taproot address requires significant amounts of off-chain computation and communication, however the resulting on-chain footprint is minimal. As long as both parties collaborate, they can perform arbitrarily complex, stateful off-chain computation, without leaving any trace in the chain. On-chain execution is required only in case of a dispute. #### Potential Use Case * Complex smart contracts * Prediction Markets * Privacy * Multisig * 2WP for sidechains (Pegin and Pegout) * Bridges ## Project homepage ## Members ### Founder ] ### Contributors ## Resources ### Community project ### Community chat TG： ### Project news \ TG Pinned post： ```Bash some reads: - whitepaper: https://bitvm.org/bitvm.pdf - WIP implementation: https://github.com/supertestnet/tapleaf-circuits/ - bitcoin magazine explainer: https://bitcoinmagazine.com/technical/the-big-deal-with-bitvm-arbitrary-computation-now-possible-on-bitcoin-without-a-fork - simple explainer: https://github.com/fiksn/bitvm-explained - LN+ explainer: https://lightningnetwork.plus/posts/450 - base58 explainer: https://twitter.com/base58btc/status/1711728898730242112 Donate: bc1qf5g6z0py2t3t49gupeqrlewga0qz2etalu4xf9 ``` ```Bash fyi, @supertestnet and @jeremyrubin and everyone here's a more detailed version of the transaction graph diagram also including explanations. It's a SVG file that you can zoom into https://github.com/BitVM/BitVM/blob/main/docs/bitvm_graph.svg ``` ```Bash codereview Screen capture：https://t.me/bitVM_chat/8839 ``` Supertestnet Hiring builder：
### Project tools opcode Debugging tools： ## Others ### Interpretation
### Reference
## Based on # BitVM-FAQ ## BitVM-FAQ less-technical frequently asked questions on [BitVm](https://bitvm.org/bitvm.pdf) ### What is BitVM? It is a virtual computer for use in bitcoin contracts. As a virtual computer, BitVM can run programs. It can run anything a developer can write for it. What makes it unique is, it is compatible with bitcoin, meaning BitVM programs can be used to "lock up" bitcoins. In other words, you can put some money in a bitcoin address, and know that they only way someone can take it is if they correctly run a program of your choice -- *any program.* ### Does BitVM make bitcoin like ethereum? No. BitVM programs are executed off-chain, unlike ethereum programs, which are executed on-chain. In BitVM, you only use the blockchain during a dispute, to prove that someone ran a program *incorrectly* off-chain, whereupon you can take their money. If your counterparty runs the program correctly, nothing about the program goes on the blockchain. ### Can I use it today? although there's no need for any changes to be made to the bitcoin blockchain consensus rules, there's still a lot of work to do before BitVm can be used for any practical purposes, but you can check the toy implementation using testnet bitcoin for some simple programs [here](https://supertestnet.github.io/tapleaf-circuits/) ### What would be the use case in the future? since BitVm introduces a way to do any computations, many of the use cases are not yet discovered, or certain but some very exciting and tangible use cases would be enabling sidechains, where you can send bitcoin back and forth with a better trust-model than what currently is available, improving the current infrastructure (e.g. Lightning Network), verifying ZKPs and emulating bitcoin improvement proposals. ### Is there any roadmap? there's no roadmap per say, but you can find the todolist [here](https://github.com/supertestnet/things-bitvm-needs), if you want to get a grasp of what the future holds. ### Where can I learn more? here are some reads: * [whitepaper](https://bitvm.org/bitvm.pdf) * [WIP implementation](https://github.com/supertestnet/tapleaf-circuits/) * [bitcoin magazine explainer](https://bitcoinmagazine.com/technical/the-big-deal-with-bitvm-arbitrary-computation-now-possible-on-bitcoin-without-a-fork) * [BitVM Primer (Non-technical)](https://github.com/twhit223/bitvm_primer) * [simple explainer](https://github.com/fiksn/bitvm-explained) * [LN+ explainer](https://lightningnetwork.plus/posts/450) * [base58 explainer](https://twitter.com/base58btc/status/1711728898730242112) if you have another question or you want to follow the development and discussions on BitVm you can join [the BitVM Builders telegram group](https://t.me/bitVM_chat) # BitVM And Its Optimization Considerations > Original: > > *Written by Lynndell and Mutourend, Bitlayer Research Group* > > *Mail: , *
## **1. Introduction** Bitcoin is a decentralized, secure, and trustworthy digital asset. However, it faces significant limitations that prevent it from becoming a scalable network for payments and other applications. The scaling issue of Bitcoin has been a concern since its inception. Bitcoin’s UTXO (Unspent Transaction Output) model treats each transaction as an independent event, leading to a stateless system that lacks the ability to execute complex, state-dependent computations. As a result, while Bitcoin can perform simple scripts and multi-signature transactions, it struggles to facilitate the complex and dynamic contract interactions common on stateful blockchain platforms. This limitation significantly restricts the range of decentralized applications (dApps) and complex financial instruments that can be built on Bitcoin, whereas stateful platform models offer a more diverse environment for deploying and executing feature-rich smart contracts. For Bitcoin scaling, the main technologies include state channels, sidechains, and client-side validation. State channels provide a secure and diverse payment solution but have limited capacity to verify arbitrarily complex computations. This limitation reduces their applicability in various scenarios requiring complex, conditional logic and interactions. Sidechains support a broad range of applications and offer diversity beyond Bitcoin’s capabilities, but they have lower security. This security difference stems from sidechains using independent consensus mechanisms, which are far less robust than Bitcoin’s consensus mechanism. Client-side validation, using the Bitcoin UTXO model, can handle more complex transactions, but it lacks bidirectional checking and constraints with Bitcoin, leading to lower security. The off-chain design of client-side validation protocols relies on servers or cloud infrastructure, which could lead to centralization or potential censorship through compromised servers. The off-chain design of client-side validation also introduces more complexity into blockchain infrastructure, possibly leading to scalability issues. In December 2023, Robin Linus, the project leader of ZeroSync, published a white paper titled “[BitVM：Compute Anything On Bitcoin](https://bitvm.org/bitvm.pdf)”, which sparked considerable thought on enhancing Bitcoin’s programmability. The paper proposes a Turing-complete Bitcoin contract solution that can execute any complex computation on Bitcoin without changing the network’s consensus rules or altering Bitcoin’s fundamental principles. BitVM leverages Bitcoin scripts and Taproot to implement optimistic Rollups. It uses Lamport signatures (also known as bit commitment) to establish connections between two Bitcoin UTXOs, enabling stateful Bitcoin scripts. A large program is committed within a Taproot address, and operators and validators engage in extensive off-chain interactions, leaving a minimal footprint on the blockchain. If both parties cooperate, any complex, stateful off-chain computation can be executed without leaving any trace on the blockchain. However, if the parties do not cooperate, on-chain execution is required in the event of a dispute. Therefore, BitVM significantly expands Bitcoin’s potential use cases, allowing it to serve not only as a currency but also as a verification platform for various decentralized applications and complex computational tasks. However, despite the advantages of BitVM technology in Bitcoin scaling, it is still in the early stages and faces some efficiency and security issues, such as: (1) Challenges and responses require multiple interactions, leading to high transaction fees and lengthy challenge periods; (2) Lamport one-time signatures have long data lengths, necessitating a reduction in data size; (3) High hash function complexity requires Bitcoin-friendly hash functions to reduce costs; (4) Existing BitVM contracts are large, and Bitcoin block capacity is limited, so using scriptless scripts could help achieve Scriptless Scripts BitVM, saving Bitcoin block space and enhancing BitVM efficiency; (5) Current BitVM operates on a permission model, with challenges initiated only by consortium members and limited to two parties, which should be expanded to a permissionless multi-party challenge model to further reduce trust assumptions. To address these issues, the paper suggests several optimization ideas to improve BitVM’s efficiency and security. ## **2. BitVM Principle** BitVM is positioned as an off-chain contract system for Bitcoin, aimed at advancing the contract functionality of Bitcoin. Currently, Bitcoin scripts are entirely stateless, meaning the execution environment resets after each script. There is no native way in the Bitcoin scripting to ensure that scripts 1 and 2 have the same value of *x*. However, it’s possible to make Bitcoin scripts stateful using existing opcodes and Lamport one-time signatures, enforcing that *x* in script1 and script2 are the same. If participants sign conflicting values of *x*, they can be penalized. BitVM computations occur off-chain, while the verification of these computations takes place on-chain. Given the 1MB limit of Bitcoin blocks, when verification of complex computations is needed, the OP technology can be used in a challenge-response mode to support higher complexity computation verification. Similar to Optimistic Rollup and the MATT proposal (Merkelize All The Things), the BitVM system is based on fraud proofs and challenge-response protocols but does not require changes to Bitcoin’s consensus rules. BitVM’s underlying primitives are simple, primarily based on hash locks, time locks, and large Taproot trees. Provers commit to the program byte-by-byte, but verifying all computations on-chain would be prohibitively expensive. Therefore, verifiers conduct a series of carefully designed challenges to succinctly refute the prover’s false claims. Provers and verifiers co-sign a series of challenge and response transactions to resolve disputes, allowing for general computation verification on Bitcoin. Key components of BitVM include: * **Circuit commitment:** Provers and verifiers compile the program into a large binary circuit. The prover commits to this circuit in a Taproot address, with each leaf script under that address corresponding to each logic gate in the circuit. The core is to achieve logic gate commitment based on bit commitment. * **Challenge and response:** Provers and verifiers pre-sign a series of transactions to implement the challenge-response game. Ideally, this interaction occurs off-chain, but it can also be executed on-chain if the prover is uncooperative. * **Ambiguous penalty:** If the prover makes any incorrect claims, the verifier can take the prover’s deposit after successfully challenging, and thwarting the prover’s malicious actions. ## **3. BitVM Optimizations** ### **3.1 Reduce OP interaction numbers based on ZK** There are two main types of Rollups: ZK Rollups and Optimistic Rollups (OP Rollups). ZK Rollups rely on the validity verification of Zero-Knowledge (ZK) Proofs, which are cryptographic proofs of correct execution. Their security depends on computational complexity assumptions. Optimistic Rollups rely on Fraud Proofs, assuming that all submitted states are correct and usually setting a challenge period of about seven days. Their security presupposes that at least one honest party in the system can detect the incorrect state and submit fraud-proof. Assuming the maximum step count for BitVM’s challenge program is 2^{32}, it would need approximately 17GB of memory (2^{32}×4 bytes). In the worst-case scenario, around 40 rounds of challenges and responses might take about six months, with a total script size of around 150KB. Such a scenario would provide insufficient incentives, but it rarely occurs in practice. Using Zero-Knowledge Proofs to reduce the number of challenges in BitVM could enhance its efficiency. According to Zero-Knowledge Proof theory, if data *Data* satisfies an algorithm *F*, then the *proof* satisfies the verification algorithm *Verify*, outputting True. Conversely, if *Data* does not satisfy *F*, then *proof* will not satisfy *Verify*, outputting False. In the BitVM system, if the challenger does not accept the prover’s data, a challenge is initiated. For algorithm *F*, using a binary search approach, assuming 2^*n* iterations are needed to find the error point. If the algorithm’s complexity is too high, *n* is large, and it takes a long time to complete. However, the complexity of the Zero-Knowledge Proof verification algorithm *Verify* is fixed. By publicly revealing the *proof* and the verification process *Verify*, it is possible to see an output of False. The advantage of Zero-Knowledge Proofs lies in the lower computational complexity required to open the verification algorithm *Verify* compared to opening the original algorithm *F* using binary search. Thus, with Zero-Knowledge Proofs, BitVM no longer challenges the original algorithm *F*, but rather the verification algorithm *Verify*, reducing the number of challenge rounds and shortening the challenge period. Although the validity of Zero-Knowledge Proofs and Fraud Proofs relies on different security assumptions, they can be combined to construct a ZK Fraud Proof and implement On-Demand ZK Proof. Unlike a full ZK Rollup, the On-Demand model requires a ZK Proof only when a challenge is made, maintaining an optimistic design where the generated state is assumed valid until challenged. If a state is not challenged, no ZK Proof is needed. However, if a challenge is made, a ZK Proof must be generated for the correctness of all transactions within the challenged block. In the future, it could be possible to generate ZK Fraud Proofs for individual disputed instructions, avoiding the computational cost of continuously generating ZK Proofs. ### **3.2 Bitcoin-friendly one-time signatures** In the Bitcoin network, transactions that follow the consensus rules are considered valid, but beyond these rules, there is an additional concept of standardness. Bitcoin nodes only propagate and broadcast standard transactions, and the only way for valid but non-standard transactions to be included in a block is through direct collaboration with miners. According to the consensus rules, the maximum size for legacy (non-Segwit) transactions is 1MB, which could fill an entire block. However, the standardness limit for legacy transactions is set at 100kB. For Segwit transactions, the maximum size allowed by consensus rules is 4MB, known as the weight limit, but their standardness limit is 400kB. Lamport signatures are a foundational component of BitVM, and reducing the length of signatures and public keys helps decrease transaction data size, thus reducing transaction fees. Lamport one-time signatures require a hash function (like a one-way permutation function *f*). In a Lamport one-time signature scheme, the message length is *v* bits, and both the public key and the signature lengths are 2*v* bits. These long signatures and public keys consume a significant amount of storage gas. Therefore, it’s necessary to explore signature schemes that can reduce the length of signatures and public keys. Compared to Lamport one-time signatures, Winternitz one-time signatures greatly reduce the lengths of signatures and public keys, but they increase the computational complexity of signing and verifying. In the Winternitz one-time signature scheme, a special function *P* maps a *v*-bit message to a vector *s* of length *n*, with each element of *s* taking a value in {0,…,*d*}. The Lamport one-time signature scheme is a special case of the Winternitz scheme, where *d*=1. In the Winternitz scheme, the relationship between *n*, *d*, and *v* is approximately *n*≈*v*/log2(*d*+1). When *d*=15, *n*≈(*v*/4)+1. For a Winternitz signature with *n* elements, the public key and signature lengths are four times shorter than those in the Lamport one-time signature scheme, but the complexity of verification is four times higher. Using *d*=15,*v*=160,*f*=ripemd160(*x*) in BitVM for Winternitz one-time signatures can reduce the bit commitment size by 50%, thereby reducing BitVM’s transaction fees by at least 50%. In the future, while optimizing the existing Winternitz Bitcoin script implementation, exploration of more compact one-time signature schemes expressible in the Bitcoin script could be pursued. ### **3.3 Bitcoin-friendly Hash Functions** According to the consensus rules, the maximum size for a P2TR script is 10kB, and the maximum size for a P2TR script witness is the same as the maximum Segwit transaction size, which is 4MB. However, the standardness limit for a P2TR script witness is 400kB. Currently, the Bitcoin network does not support OP\_CAT, making it impossible to concatenate strings for Merkle path verification. Therefore, there is a need to implement a Bitcoin-friendly hash function using the existing Bitcoin script, in the most size-efficient manner for both script size and script witness size, to support Merkle inclusion proof verification. BLAKE3 is an optimized version of the BLAKE2 hash function and introduces a Bao tree mode. Compared to BLAKE2s-based, its compression function’s round count has been reduced from 10 to 7. The BLAKE3 hash function splits its input into chunks of 1024 bytes, with the last chunk being possibly shorter but not empty. When there is only one chunk, it serves as the root node and the tree’s sole node. These chunks are arranged as leaf nodes of a binary tree, and each chunk is compressed independently. When BitVM is used for verifying Merkle inclusion proofs, the input for the hash operation consists of two concatenated 256-bit hash values, totaling 64 bytes. With the BLAKE3 hash function, these 64 bytes can fit within a single chunk, meaning the BLAKE3 hash operation only needs to apply the compression function once to this single chunk. In the compression function of BLAKE3, seven round functions and six permutation functions are required. BitVM has already implemented basic operations such as XOR, modular addition, and right-bit shift based on u32 values, making it straightforward to assemble a BLAKE3 hash function using Bitcoin script. The stack uses four separate bytes to represent u32 words, facilitating the u32 addition, u32 bitwise XOR, and u32 bitwise rotations required by BLAKE3. The BLAKE3 hash function in the Bitcoin script is currently about 100kB, sufficient for constructing a toy version of BitVM. Furthermore, by splitting these BLAKE3 codes, the Verifier and Prover can significantly reduce the on-chain data requirements by dividing the execution into the challenge-response game instead of performing it entirely. Finally, implementing hash functions like Keccak-256 and Grøstl in the Bitcoin script will identify the most Bitcoin-friendly hash function and explore other new Bitcoin-friendly hash functions. ### **3.4 Scriptless Scripts BitVM** Scriptless Scripts is a method of executing smart contracts off-chain using Schnorr signatures. The concept of Scriptless Scripts originated from Mimblewimble, where no permanent data is stored other than the kernel and its signature. The advantages of Scriptless Scripts include functionality, privacy, and efficiency: * **Functionality:** Scriptless Scripts can expand the scope and complexity of smart contracts. The capabilities of Bitcoin script are limited by the number of OP\_CODES enabled on the network. In contrast, Scriptless Scripts move the specification and execution of smart contracts off-chain to discussions among the contract parties alone, without waiting for the Bitcoin network to fork to enable new opcodes. * **Privacy:** Moving the specification and execution of smart contracts from on-chain to off-chain enhances privacy. On-chain, many details of the contract are shared with the entire network, including the number of participants, addresses, and the amount transferred. Moving smart contracts off-chain means the network only knows that the participants have agreed that the terms of the contract are satisfied and the related transactions are valid. * **Efficiency:** Scriptless Scripts minimize the amount of data that needs to be verified and stored on-chain. By moving smart contracts off-chain, the administrative costs for full nodes are reduced, and transaction fees for users are also lowered. Scriptless scripts represent a way to design cryptographic protocols on Bitcoin that avoids executing explicit smart contracts. The core idea is to use cryptographic algorithms to achieve the desired functionality instead of using scripts. Adaptor signatures and multi-signatures are foundational building blocks of Scriptless Scripts. With Scriptless Scripts, transactions can be smaller than conventional transactions, thus reducing transaction fees. Scriptless Scripts can be used to implement logic gate commitments in the BitVM circuit, saving BitVM script space and enhancing BitVM efficiency, using Schnorr multi-signature and Adaptor signatures instead of providing hash values and pre-images like the BitVM solution. Although current Scriptless Scripts schemes can reduce BitVM script space, they require extensive interaction between the prover and challenger to combine public keys. Future improvements will aim to integrate Scriptless Scripts into specific BitVM functional modules. ### **3.5 Permissionless Multi-party Challenges** The current BitVM challenge requires permission because a Bitcoin UTXO can only be executed once, leading to a situation where a malicious verifier could “waste” the contract by challenging an honest prover. BitVM is currently restricted to a two-party challenge model. A malicious prover could use a verifier under his control to initiate a challenge and “waste” the contract, thus ensuring his malicious action succeeds while other verifiers cannot prevent this behavior. Therefore, on top of Bitcoin, it is necessary to research a permissionless multi-party OP challenge protocol that could expand BitVM’s existing 1-of-n trust model to 1-of-N, where N is much larger than n. Additionally, it’s important to address issues of collusion between challengers and provers or malicious challenges that “waste” contracts to achieve a more trust-minimized BitVM protocol. A permissionless multi-party challenge allows anyone to participate without a whitelist, meaning users can withdraw from L2 without the involvement of any trusted third party. Moreover, any user wanting to engage in the OP challenge protocol can question and remove invalid withdrawals. Expanding BitVM into a permissionless multi-party challenge model involves addressing the following attacks: * **Sybil attacks:** Even if an attacker creates multiple identities to participate in the dispute challenge, a single honest participant should still be able to win the dispute. If the cost for an honest participant to defend the correct result grows linearly with the number of attackers, the cost for the honest participant to win the dispute becomes impractical and vulnerable to Sybil attacks when involving a large number of attackers. The paper “[Permissionless Refereed Tournaments](https://arxiv.org/pdf/2212.12439.pdf)” proposes a dispute resolution algorithm that changes the game rules, where the cost for a single honest participant to win the dispute grows logarithmically, not linearly, with the number of opponents. * **Delay attacks:** An individual or group of malicious actors follow a strategy to prevent or delay the confirmation of the correct result (like withdrawing assets to L1) on L1, forcing the honest prover to spend L1 transaction fees. To mitigate this issue, challengers could be required to make an upfront stake. If a challenger launches a delay attack, their stake would be forfeited. However, if attackers are willing to sacrifice their stake to some extent to pursue delay attacks, there should be strategies to reduce the impact of these attacks. The algorithm proposed in the paper “[BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol](https://github.com/OffchainLabs/bold/blob/main/docs/research-specs/BOLDChallengeProtocol.pdf)” ensures that the worst-case delay caused by the attacker is capped, regardless of how much stake the attacker is willing to lose. In the future, there will be an exploration of a BitVM permissionless multi-party challenge model that is resistant to these attacks and suitable for the characteristics of Bitcoin. ## **4. Conclusion** The exploration of BitVM technology is just beginning, and in the future, more optimizations will be explored and practiced to achieve scaling for Bitcoin and enrich the Bitcoin ecosystem. **References** 1. [BitVM: Compute Anything on Bitcoin](https://bitvm.org/bitvm.pdf) 2. [BitVM：Off-chain Bitcoin Contracts](https://brink.dev/assets/files/2024-01-16-eng-bitvm-slides.pdf) 3. [Robin Linus on BitVM](https://www.youtube.com/watch?v=9aBuGObjEHs\&t=150s) 4. [\[bitcoin-dev\] BitVM: Compute Anything on Bitcoin](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/thread.html#21986) 5. [The Odd Couple: ZK and Optimistic Rollups on a Scalability Date](https://www.risczero.com/blog/altlayer-zkfraudproofs) 6. [What are Bitcoin’s transaction and script limits?](https://bitcoin.stackexchange.com/questions/117594/what-are-bitcoins-transaction-and-script-limits) 7. [BIP-342: Validation of Taproot Scripts](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki) 8. 9. [A Graduate Course in Applied Cryptography](https://toc.cryptobook.us/book.pdf) 10. [BLAKE3: one function, fast everywhere](https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf) 11. [\[bitcoin-dev\] Implementing Blake3 in Bitcoin Script](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022154.html) 12. 13. [Introduction to Scriptless Scripts](https://tlu.tarilabs.com/cryptography/introduction-to-scriptless-scripts) 14. [BitVM using Scriptless Scripts](https://stacker.news/items/284642) 15. [Solutions to Delay Attacks on Rollups](https://medium.com/offchainlabs/solutions-to-delay-attacks-on-rollups-434f9d05a07a) 16. [Introducing DAVE. Cartesi’s Permissionless Fault-Proof System.](https://www.reddit.com/r/cartesi/comments/16nkvwt/introducing_dave_cartesis_permissionless/) 17. [Delay Attacks on Rollups](https://ethresear.ch/t/delay-attacks-on-rollups/14508/3) 18. [Solutions to Delay Attacks on Rollups — Arbitrum Research](https://research.arbitrum.io/t/solutions-to-delay-attacks-on-rollups/692) 19. [Multiplayer Interactive Computation Games Notes](https://github.com/kleros/research-docs/blob/master/research-notes/interactivecomputationgamesnotes.pdf) 20. [BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol](https://github.com/OffchainLabs/bold/blob/main/docs/research-specs/BOLDChallengeProtocol.pdf) 21. [Permissionless Refereed Tournaments](https://arxiv.org/pdf/2212.12439.pdf) # PPT # BitVM Slides by Cartesi,Bringing ZK verifiers to Bitcoin using BitVM - ? > original: > > author: [Cartesi](https://web3.link/BitVmAndZK_ZkWarsaw.pdf) {% embed url="" %} # How BitVM works? {% embed url="" %} # BitVM : Off-chain Bitcoin Contracts {% embed url="" %} # Primer # What is BitVM? And why does it matter to rollups? > original: > > Author(s): [Alexei Zamyatin](https://twitter.com/alexeiZamyatin) of [Build on Bitcoin (B.O.B)](https://www.gobob.xyz/) and [Ian Sagstetter](https://twitter.com/iansagstette) of [Espresso Systems](https://twitter.com/espressosys) ## What is BitVM? And why does it matter to rollups? ## Author(s): [Alexei Zamyatin](https://twitter.com/alexeiZamyatin) of [Build on Bitcoin (B.O.B)](https://www.gobob.xyz/) and [Ian Sagstetter](https://twitter.com/iansagstette) of [Espresso Systems](https://twitter.com/espressosys) BitVM is an offchain virtual machine that could completely change the landscape for teams building Layer 2s on Bitcoin. They're already exploring how BitVM can be used to optimistically verify state updates provided by rollups. And, there have even been discussions on BitVM bringing a [ZK-Verifier to Bitcoin](https://twitter.com/stskeeps/status/1722339542630306284#).\ \ The best part? This can all be enabled without a softfork (although a softfork might [help](https://twitter.com/robin_linus/status/1737097335719575831) 😄).\ \ Below we cover what BitVM is, and how it can impact rollups being built on Bitcoin. We also provide a list of materials where you can learn more.\ \ Want to jump straight to the resources? Go [here](https://www.bitcoinrollups.io/bitvm-resources). #### The BitVM tl;dr The information on this page can get pretty technical. The short on BitVM is that it offers a major improvement to bridging and Layer 2 design on Bitcoin. It can likely bring us Optimistic rollups, and also make multi-sig bridge custodians effectively obselete. This improvement significantly decreases the trust assumptions Bitcoin users have to take on when interacting with Layer 2s, and it creates an entirely new design space of applications being built on Bitcoin. That's why it's one of the most covered topics in the technical Bitcoin community. We highlight what this means for rollups below, and also list a number of resources where you can learn more about BitVM. Our favorites to get started are [this blog by Tyler Whittle](https://mirror.xyz/twhittle.eth/zXzocAl-wWiMSBAzhKnd6w0AJsftqgPTUfnh115fVPM), this [tweet thread from Bob Bodily](https://twitter.com/BobBodily/status/1712305639366811997), and this [podcast episode on the Stephen Livera Podcast](https://www.youtube.com/watch?v=XxqQU6j6jI8). BitVM was introduced by the [ZeroSync team](https://zerosync.org/). #### What is BitVM? The core idea of BitVM is to take computation off-chain with an on-chain fraud proving mechanism. Bitcoin Script is very simple, so to run more advanced programs, you need to run them off-chain and somehow prove that the computation was done correctly. To verify computation, BitVM uses a similar scheme to optimistic rollups - a prover (who executes the computation off-chain) makes a claim about the output of the computation. If this claim is disputed, the verifier can challenge it on the Bitcoin blockchain. The Bitcoin blockchain would only be used for disputes in this scheme. Tl;dr? It allows you to develop new applications on Bitcoin that may provide more utility to BTC the asset. #### Why does it matter to rollups? BitVM allows us to create a fraud-proof mechanism that is conceptually similar to TrueBit’s or Arbitrum’s design - likely enabling optimistic rollups on Bitcoin! There are, however, a few subtle but important differences. As of writing, the committee of Provers and Verifiers, i.e., participants who can trigger a dispute, must be pre-defined for each BitVM setup. This means that the trust assumption of a BitVM setup is 1-of-N known participants, rather than “at least any one honest and online network participant”. Another difference is that due to lack of smart contract functionality on Bitcoin, we cannot make use of succinct non-interactive proving techniques, as opposed to Ethereum. As a result, the challenge-and-response protocol must be interactive. This means that the exchanges between accused Provers, and challenging Verifiers, must be on-chain Bitcoin transactions over a prolonged period. This takes place until either one of them is slashed due to timeout or equivocation. But, the Verifier can make use of a similar bisection protocol as other well-known fraud-proof mechanisms. It can essentially perform an efficient binary search over the pre-committed program (specifically, the program broken down into the underlying logical gates) to determine which parts should be challenged. This optimization already allows to cut down on-chain costs to approximately 30-40 transactions per challenge, in the worst case. Tl;dr? BitVM can likely give us optimistic rollups with different trust assumptions as to those on, let’s say, Ethereum. This is incredible for Bitcoin scaling. #### Can it give us trust-minimized bridging? First, let’s review the current state of Bitcoin bridges. When a user bridges BTC to a Layer 2, or another blockchain, they have to deposit that BTC into a bridge contract. On Bitcoin, a bridge will use one of two designs: * Statistical security: a multi-sig (or threshold signature) controlled by N parties. As long as the majority M of N is honest, the bridge is secure. Notable examples include rBTCs (multisig) or tBTC (larger set via threshold signatures). * Economic security: bridge operators are collateralized on the target chain in assets other than Bitcoin. If an operator steals BTC or fails to perform a peg-out, their collateral is liquidated and used to reimburse the user. While this design is very secure (users always get BTC back or are repaid in full in other assets), the associated capital costs for operators limit scalability. Collateral quality is another concern, as other assets may fluctuate in price compared to BTC or exhibit lesser security properties. Variations of [this design](https://eprint.iacr.org/2018/643) are used by Interlay, Cardano (anetaBTC), TeleBTC (on Polygon), Harmony and Stack’s sBTC. Both designs can be combined to improve security and balance between large signer committees and full/partial collateralization. See [here](https://docs.google.com/presentation/d/1PBufh0UbbC1YRA1Nj1TsbCRl836jmA5fr9Oo3B-1i7w/edit#slide=id.g27993ad3907_0_187) for more details on Bitcoin bridges. **BitVM & Bitcoin Bridges** BitVM can offer a major improvement over existing bridges in terms of security and capital efficiency. Specifically, we may be able to use BitVM to implement a light client for the target chain / Layer 2 that would allow us to verify correct processing of peg-in and pre-out transactions (on the other chain that is assumed to have smart contracts). The idea is that deposits made into BitVM are controlled by a committee of N Provers and Verifiers, and as long as one of these N participants is honest, the deposits remain secure. Whenever a user requests a peg-out the (current) Prover verifies the state of the L2 off-chain and, if everything is correct, sends BTC to the user. Verifiers observe this process and verify correctness. If the Prover misbehaves, i.e., remains unresponsive or sends BTC to a wrong BTC address, they trigger an on-chain challenge and prevent the Prover from accessing the BTC deposits. This, of course, requires the Prover verify the state of the L2 off-chain. It makes use of so-called cross-chain light clients: programs that can programmatically verify that certain state changes have happened on another blockchain. The sidechain, assumed to have smart contract functionality, implements a Bitcoin light client that can verify Bitcoin transactions, and vice-versa. Bitcoin’s Script language lacks expressiveness to encode light clients as on-chain programs. Instead, the sidechain light client is implemented via BitVM, a novel paradigm on Bitcoin based on optimistic program execution: participants pre-commit to the program via a set of pre-signed Bitcoin transactions, the execution happens off-chain, and if participants disagree a challenge-response protocol is performed to determine the correct outcome. The billion dollar question is how to scale the set of Verifiers and ensure a good user experience to users. Given this, BitVM can finally make centralized multi-sig bridges redundant! You can find the full list of materials on BitVM in the sections below. #### BitVM Papers * [BitVM: Compute anything on Bitcoin](https://bitvm.org/bitvm.pdf) #### Written resources on BitVM * [Deep dive into BitVM Computing Paradigm - Ichiro Kuwahara](https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca) * [BitVM and Bridges - Alexei Zamyatin](https://github.com/BitVM/BitVM/blob/main/docs/sidechain_bridges.md) * [The BitVM Primer - Tyler Whittle](https://mirror.xyz/twhittle.eth/zXzocAl-wWiMSBAzhKnd6w0AJsftqgPTUfnh115fVPM) * [BitVM: A Breakthrough in Computing on the Bitcoin Layer - Trust Machines](https://trustmachines.co/blog/bitvm-a-breakthrough-in-computing-on-the-bitcoin-layer/) * [The Big Deal with BitVM - Bitcoin Magazine](https://bitcoinmagazine.com/technical/the-big-deal-with-bitvm-arbitrary-computation-now-possible-on-bitcoin-without-a-fork) * [BitVM FAQs](https://github.com/PraiseTheMithra/BitVm-FAQ) #### Video and audio resources on BitVM * [BitVM Uses a 'Compilation of a Couple Tricks' to Overcome Limitations of Bitcoin's Script: Robin Linus](https://finance.yahoo.com/video/bitvm-uses-compilation-couple-tricks-141723622.html) * [What is BitVM? with Robin Linus and Super Testnet (SLP520) - Stephan Livera Podcast](https://www.youtube.com/watch?v=XxqQU6j6jI8) * [Zero Sync - Bitcoin Amsterdam](https://www.youtube.com/watch?v=rubs5SrkGsM) * [BitVM two way peg design - Ordinals Show](https://twitter.com/i/spaces/1YqKDgYMqlvxV?s=20) * [BitVM - A Tiny Web3 Podcast](https://twitter.com/cartesiproject/status/1729893087143759950) * [Everything on Bitcoin with Robin Linus & Super Testnet - Bitcoin Audible](https://pod.link/1359544516/episode/413027f0bdb982a8593d50f4466930f5) * [BitVM Takeover with Super Testnet - Layer Two Labs](https://x.com/LayerTwoLabs/status/1712855344764834076?s=20) * [BitVM, Convenants and Scaling - Bitcoin News](https://x.com/BitcoinNewsCom/status/1715392573555040265?s=20) * [BitVM and UTXO Dealership](https://twitter.com/i/spaces/1OyJAWapbAOKb) * [BitVM Discussion - Ordinals Show](https://x.com/TO/status/1716265121373172075?s=20) #### Related Github Repos * [BitVM Toy Implementation](https://github.com/BitVM/BitVM) * [Things BitVM Needs](https://github.com/supertestnet/things-bitvm-needs) * [Awesome BitVM - Rsync25, an amazing resource on technical resources regarding BitVM](https://github.com/Rsync25/awesome-bitvm) #### Tweet threads on BitVM * [Decentralized two way peg on BitVM - Alex Emidio](https://twitter.com/AlexEmidio7/status/1735276812198986210) * [BitVM Explainer - Bob Bodily](https://twitter.com/BobBodily/status/1712305639366811997) * [BitVM Explainer, BitVM GPT - Dylan LeClair](https://x.com/DylanLeClair_/status/1722995043932270854?s=20) #### Communities * [BitVM Telegram](https://x.com/robin_linus/status/1711757377983086894?s=20) #### Tweets mentioning Rollups and BitVM * [Chainway on their rollup using BitVM](https://twitter.com/chainway_xyz/status/1735361028160893235) * [Chainway, What is BitVM?](https://twitter.com/chainway_xyz/status/1737542123434467737) If you’d like to add materials to this site, please see our [contribute](https://www.bitcoinrollups.io/contribute) section. # BitVM: Ushering in a New Era of Bitcoin Computations > original: Are you ready for something groundbreaking in the Bitcoin universe? Well, guess what? There's a new game-changer in town, and it's called **BitVM**. Let's dive right into what this means for all of us.
## The Basics of BitVM Imagine being able to perform Turing-complete contracts on Bitcoin without altering any of its consensus rules. Sounds like a dream, right? But with BitVM, this dream is a reality! Here's how it works: * Instead of running computations on Bitcoin, they're *verified*. Think of it like the optimistic rollups you might've heard about. * A user (called the *prover*) claims a particular function's outcome. If they're bluffing, another user (the *verifier*) can swiftly call them out with a fraud proof and even penalize them. * The magic? ANY computable function can now be verified on Bitcoin. ## Why is this a Big Deal? You might be thinking, "Cool, but why should I care?" Here's why: * **Off-chain Efficiency**: Large programs can be committed off-chain, using methods like the Taproot address. This means a lot of work happens off the ledger, but the footprint on Bitcoin's chain remains tiny. * **Stealth Mode**: Parties can perform complex, stateful computations without leaving any trace in the chain. Only if there's a disagreement will there be a need for on-chain execution. ## Endless Possibilities With BitVM, Bitcoin's smart contract capabilities are no longer just basic operations. The doors are now wide open: * **Games**: Imagine playing Chess, Go, or Poker, all verified on Bitcoin. * **Bridging Chains**: It might become feasible to connect BTC with other chains. * **Prediction Markets & Novel Opcodes**: The sky is the limit with what could be achieved! ## Understanding Bitcoin's Limited Instruction Set For those well-versed in Bitcoin's intricate workings, you'll recall that its smart contract capabilities were intentionally designed to be limited. But why? 1. **Security**: A limited instruction set reduces the attack surface. Fewer operations mean fewer potential vulnerabilities, ensuring a robust and secure environment. 2. **Predictability**: With fewer instructions, the behavior of the protocol is more predictable, reducing unexpected outcomes or network issues. 3. **Simplicity**: Keeping it simple means fewer chances of bugs, making it easier for developers to understand, implement, and maintain. ## BitVM's Role: Breaking Boundaries While Keeping the Fort Tight BitVM, with its enhanced capabilities, might seem like it's challenging the core principles of Bitcoin's limited instruction set. But here's the twist: it's not. Here's how: * **Verification Over Execution**: BitVM doesn't execute complex computations on-chain. It merely verifies them. This distinction ensures that Bitcoin's chain remains as secure and predictable as ever. * **Off-Chain Magic**: Most of the heavy lifting with BitVM happens off-chain, preserving the simplicity and security of the Bitcoin protocol. Only in cases of disputes do we see on-chain action. ## The Best of Both Worlds With BitVM, it seems we're inching closer to achieving a sweet balance: * **Maintain Bitcoin's Core Values**: The benefits of a limited instruction set—security, predictability, and simplicity—remain intact. * **Unlock New Possibilities**: BitVM opens up a realm of possibilities previously thought to be out of reach for Bitcoin, from intricate games to bridging with other chains. ## Challenges Ahead While BitVM sounds promising, it's essential to understand its limitations. Currently, the model is restricted to a two-party system, involving a prover and a verifier. Both these parties require significant off-chain interactions. But with the pace of innovation in the Bitcoin realm, who knows what solutions the future holds? ## In Conclusion BitVM is shaping up to be a revolutionary step for Bitcoin, opening doors to possibilities we could only dream of. While there are challenges to overcome, the future looks bright, and the Bitcoin community has another reason to be excited!\ \ To learn more, [read the BitVM white paper!](https://bitvm.org/bitvm.pdf) # BitVM: A Computational Revolution in Bitcoin BitVM is a new computing paradigm that theoretically allows any computation within Bitcoin itself. This could open doors to more complex smart contracts, decentralized applications, and other function > original: > > author: Edilson Osorio Jr. The world of cryptocurrencies has been a stage for continuous innovations since the creation of Bitcoin. Each advancement aims to improve the efficiency, security, and versatility of transactions and contracts carried out on the blockchain. BitVM emerges as a revolutionary proposal, promising to bring arbitrary computation to Bitcoin without the need for a fork. This article seeks to elucidate the technical and practical aspects of BitVM, its advantages, disadvantages, and the challenges it faces. BitVM is a new paradigm of computation that utilizes the NAND logic gate, along with other gates, within Taproot leaves with pre-signed transactions. This approach theoretically allows for any computation within Bitcoin itself. The central idea is that by using only NAND gates, it is possible to construct circuits for arbitrary computation, something that is already well-established in the theory of computation. ### Operation The emergence of BitVM is not just a technical achievement but is also driven by clear incentives within the Bitcoin ecosystem. The ability to perform arbitrary computations directly on Bitcoin has the potential to significantly expand the applications of Bitcoin beyond simple monetary transactions. This could open doors to more complex smart contracts, decentralized applications, and other functionalities that were previously the domain of other blockchains, such as Ethereum. BitVM operates by elevating the logic of computation off-chain and allowing only a few steps of the computation to be processed on-chain, even if one of the parties presents a dishonest result. This is achieved through the combination of NAND gates within Taproot leaves and pre-signed transactions. Essentially, BitVM enables the execution of Turing-complete computations on Bitcoin in a verifiable and enforceable manner. #### NAND Logic Gate (NOT AND) A NAND logic gate (acronym for NOT AND) is one of the fundamental logic gates in digital electronics. It has two inputs and one output. The NAND gate produces a FALSE (0) output only when both of its inputs are TRUE (1). In all other cases, it produces a TRUE output. Mathematically, the NAND operation is the negation of the AND operation, hence the name "NOT AND." The significance of the NAND gate in computing is that it is a "universal" logic gate, meaning that any logical or computational function can be constructed using only NAND gates. This makes it fundamental in the construction of electronic circuits and computers.

Tapscript using NAND gates source: BitVM Paper

#### Taproot and Tapscript Taproot is a proposed upgrade for Bitcoin aimed at improving its privacy and efficiency. One of the key features of Taproot is that it allows multiple spending conditions to be combined into a single condition, making transactions more efficient and private. On the other hand, Tapscript is the scripting language that enables the execution of these conditions. Each "Tapleaf" or "Taproot Leaf" represents a potential spending condition within a Taproot structure. It was introduced to Bitcoin through Bitcoin Improvement Proposal (BIP) 341. The central idea behind Taproot is to combine the benefits of payment scripts (which allow for complex spending conditions for bitcoins) with regular single-signature transactions so that both appear indistinguishable on the blockchain. This is achieved using a combination of cryptographic techniques, including Schnorr signatures and Merkle trees. **The benefits of Taproot include:** * **Enhanced Privacy:** All transactions, regardless of their complexity, will appear as regular single-signature transactions on the blockchain. * **Reduced Space Usage:** Complex transactions using payment scripts can be represented more efficiently, saving space on the blockchain. * **Flexibility:** It allows for the creation of more complex and flexible smart contracts on Bitcoin without revealing the full complexity on the blockchain.

Taproot circuit source: BitVM Paper

In summary, while the NAND gate is a fundamental concept in electronics and computer theory, Taproot is a specific innovation within Bitcoin that aims to improve how transactions and smart contracts are represented and processed on the blockchain. Both are crucial concepts when discussing BitVM and its implications for the future of Bitcoin. #### Turing Complete The term "Turing Complete" refers to the ability of a computing system to simulate any Turing machine. In simpler terms, if a system is Turing Complete, it means it has the capacity to solve any computational problem, given enough time and memory. The Turing Machine, inspired by the renowned computer scientist Alan Turing, is a theoretical concept that represents how a computer works at its most basic level. Imagine a long tape containing information and a "machine" that follows specific rules to read and modify this information. Although not a real physical entity, this model is crucial in computer science as it sets a standard for determining the limits of computational capabilities. When we say that a programming language or system is Turing Complete, we are essentially saying that it has the ability to simulate any Turing Machine and, therefore, can be used to perform any computation that a Turing Machine can execute. In the context of BitVM and Bitcoin, the assertion that BitVM allows for the execution of "Turing-complete" computations on Bitcoin means that BitVM has the theoretical capability to execute any kind of calculation or program on Bitcoin, making it an extremely powerful and versatile platform for decentralized application development. #### Bristol Format in BitVM The Bristol format is a standard adopted to describe how circuits that verify information without revealing it (known as zero-knowledge proofs) are structured. In simple terms, it serves as a guide or template that shows how to organize and interpret these circuits. Here is a simplified representation of what it looks like: ``` 127 191 1 64 1 1 ... 1 1 63 65 INV 1 1 60 64 INV 2 1 65 64 69 AND ... ``` * The first line, `127 191`, defines the number of "wires" required in the circuit. * The second line. `1 64`, specifies how many "input wires" will contribute input bits to the function. * The third line, `1 1`, indicates how many "output wires" will exit the circuit. * Subsequent lines represent the logical gates within the circuit, such as INV (Inverter) and AND. The Bristol format is a compact and efficient representation of boolean circuits. In the context of BitVM, it is used to define circuits that can be evaluated and verified within Bitcoin. To convert, execute, and validate a Bristol circuit into a Taproot address, several dependencies are required. The proof of concept provides functions to convert each line into an array, set some necessary variables using the first three lines, and then tailor the circuit only for the logical gates. #### Zero-Knowledge Proofs Zero-knowledge proofs are a cryptographic concept that allows one party (the prover) to prove to another party (the verifier) that a certain statement is true without revealing any specific information about the statement itself. In other words, it is possible to prove that you know something without disclosing what you know. For example, imagine you want to prove that you know the password to a system but don't want to reveal the password itself. By using zero-knowledge proofs, you can convince someone that you know the password without actually showing it.

Alibaba Cave with Alice and Bob: Zero-Knowledge Proof Source: Wikipedia

**Benefits of Zero-Knowledge Proofs for BitVM:** * **Enhanced Privacy:** By using zero-knowledge proofs in BitVM, it would be possible to perform calculations and transactions without revealing the specific details of these operations. This means that the details of smart contracts or other operations could remain private while still verifying their validity. * **Efficiency in Disputes:** In scenarios where there are disputes over the execution of a contract in BitVM, zero-knowledge proofs could be used to quickly validate claims without the need to process the entire computation or transaction in detail. * **Reduced Data Volume:** Since zero-knowledge proofs do not require the disclosure of all the details of a transaction or calculation, they could help reduce the amount of data that needs to be stored and transmitted on the network. * **Expansion of BitVM Capabilities:** By incorporating zero-knowledge proofs, BitVM could support a broader range of applications and contracts that require advanced privacy and security, making it more versatile and powerful. #### Second-Layer Networks (Layer 2): Second-layer networks are solutions built "on top" of an existing blockchain (such as Bitcoin or Ethereum) to increase its capacity and speed. They allow transactions to be processed off-chain and then consolidated and recorded on the main chain at a later time. This helps alleviate congestion and reduce fees. **How Zero-Knowledge Proofs Would Facilitate Second-Layer Networks:** * **Compact Transaction Validation:** ZKPs can be used to create "proofs" of a large number of off-chain transactions. Instead of submitting each transaction individually to the main chain, a single ZKP proof that validates all these transactions can be submitted. This saves space and reduces fees. * **Privacy in Transactions:** In second-layer networks, where many transactions occur off-chain, ZKPs can ensure that the details of these transactions remain private while still proving their validity. * **Secure Interoperability:** ZKPs can facilitate secure communication between different second-layer networks or between a second-layer network and the main chain without revealing sensitive details. * **Efficient Dispute Resolution:** In second-layer systems, where transactions are typically confirmed between parties and then recorded on the main chain, disputes can arise. ZKPs allow one party to prove they acted correctly without revealing the exact details of the transaction, facilitating more efficient dispute resolution. * **Improved Scalability:** By combining second-layer networks with ZKPs, it is possible to process a significantly larger number of transactions off the main chain and then consolidate them into a single proof on the main chain. This can dramatically increase the number of transactions a blockchain can support. * **Development of ZK Rollups:** One of the most notable advancements combining second-layer networks with ZKPs is "ZK Rollup." In this system, transactions are processed off the main chain and then "rolled up" into a single ZKP proof that is recorded on the main chain. This combines the efficiency of second-layer networks with the security and privacy of ZKPs.
Sidechains (CoinDesk)

Sidechains Source: Blockstream

In summary, zero-knowledge proofs have the potential to revolutionize the functioning of second-layer networks, making them more secure, private, and scalable. In doing so, they can play a crucial role in overcoming the scalability challenges faced by many blockchains today. **Summary of Each Relevant Technical Feature:** 1. **NAND Gates in Bitcoin:** BitVM utilizes the NAND logic gate, which is a universal gate, allowing the construction of any logical function. In the context of BitVM, these gates are constructed using Bitcoin script, specifically with the help of hashlocks and opcodes like OP\_BOOLAND and OP\_NOT. 2. **Bristol Format:** The Bristol format is a standardized representation for boolean circuits. In the context of BitVM, it is used to represent and process circuits in a compact and efficient manner. This format is crucial for creating and validating circuits in BitVM, enabling the execution of more complex functions directly on the Bitcoin blockchain. The ability to represent circuits so compactly is vital for optimizing space and efficiency, especially considering the limited storage and processing capabilities of the blockchain. 3. **Taproot and Pre-Signed Transactions:** BitVM integrates with Taproot leaves to create a tree that covers every step of arbitrary computation. Pre-signed transactions are used to create a challenge-response game that can be executed on-chain. 4. **Arbitrary Computation:** Through the combination of NAND gates and the Taproot structure, BitVM can represent and execute any computation, making Bitcoin a more versatile platform for application development. 5. **Off-Chain Infrastructure:** Given BitVM's nature of elevating computation logic off-chain, robust off-chain infrastructure is required to support computation and verification. 6. **Zero-Knowledge Proofs (ZKPs):** ZKPs are cryptographic proofs that allow one party to prove to another that a statement is true without revealing any information beyond the statement's validity. In the context of BitVM, the successful integration of ZKPs could revolutionize how transactions and contracts are validated. While the direct application of ZKPs to BitVM has not been confirmed yet, if possible, it would open a vast array of opportunities, enabling more efficient and private validations. 7. **Second-Layer Networks (L2s):** These are solutions built "on top" of the main blockchain (Layer 1) to increase transaction capacity and reduce transaction times and costs. The potential integration of ZKPs into BitVM could facilitate the creation of L2s on Bitcoin, allowing for faster, more private, and cheaper transactions. This is because, with the efficient validation provided by ZKPs, transactions in a second layer could be aggregated and verified more compactly on the main blockchain. *** ### Use cases: Secure and Verifiable Transactions with BitVM In a growing digital world, the need for secure and verifiable transactions is crucial. Bitcoin, with its decentralized and immutable nature, offers a robust solution for value transfers. However, its current structure does not allow for chargebacks, which can be problematic in situations where trust between parties is low or nonexistent. Currently, simplistically, a buyer and a seller would agree on a deal and define all the values and documents that would result from that agreement. All this information would be passed through a system that would transform it into circuits, and the final result would be some hashes and Taproot wallets. The buyer would deposit the purchase amount, and the seller would deposit insurance in case they fail to meet the requirements. At each step or certified document, it would be submitted to Bitcoin through a transaction to prove that that step was completed on time. In case of attempted fraud or delay in document delivery by the seller, for example, the total purchase amount plus insurance would be awarded to the buyer as a penalty to the seller. In the traditional model, we would use an escrow for this critical business. With the use of BitVM, Bitcoin itself could validate and certify that the business occurred correctly so that the funds could only be unlocked until every step was proven as true. Consider the scenario of buying and selling a vehicle or real estate. Traditionally, fund transfer and the exchange of documents or keys occur almost simultaneously, often with intermediaries, to ensure that both parties fulfil their part of the agreement. However, with Bitcoin, once the transaction is confirmed, there is no way to reverse the funds, even if one of the parties fails to fulfil their part of the agreement. This is where BitVM comes in. Imagine a smart contract on BitVM where the buyer deposits the value of the vehicle or real estate in Bitcoin. This amount is only released to the seller once all documents or keys are verified and transferred to the buyer. This ensures that both parties fulfil their obligations before the transaction is finalized. This mechanism could have been extremely useful for platforms like OpenBazaar, a decentralized marketplace that unfortunately had to cease its operations due to a high rate of fraud related to the non-delivery of products. Although OpenBazaar attempted to mitigate these frauds using escrow systems, these intermediaries often charged prohibitive fees or refused to participate in certain agreements. With BitVM, the need for intermediaries like escrow systems could be eliminated. The smart contract on BitVM would act as an automatic guarantor, ensuring that payment is only released upon confirmation of product or service delivery. This would not only reduce fees associated with intermediaries but also increase trust in transactions, potentially revolutionizing the way we conduct business in a digital environment. *** ### Advantages and Disadvantages: #### Advantages: 1. **Expansion of Bitcoin's Capabilities:** BitVM allows Bitcoin to go beyond monetary transactions, opening doors to more complex smart contracts and decentralized applications. 2. **No Immediate Need for Upgrade:** One of the biggest advantages of BitVM is that it enables this expansion without the need for an immediate fork or significant protocol upgrade in Bitcoin. However, it is widely recognized by the developer community that, while not strictly necessary, an upgrade would be desirable to accelerate progress and optimize the functioning of BitVM. 3. **Enhanced Privacy:** With the integration of Taproot, BitVM transactions can appear as regular transactions, improving user privacy at a reduced cost. 4. **Efficiency:** Although still in its early stages and far from being a cost-efficient solution, BitVM has the potential to be an efficient on-chain computing solution, especially as optimizations are implemented. 5. **Reduction of Intermediaries:** BitVM can eliminate the need for intermediaries like escrows in transactions, reducing costs and increasing efficiency. #### Disadvantages: 1. **Initial Limitations:** As a developing system, BitVM has various limitations, such as being a two-party system and the need to create a new Bitcoin transaction for each smart contract interaction. 2. **Transaction Volume and Data Requirements:** BitVM implementation, especially in dispute scenarios, may require a large number of transactions to resolve and verify computations. Additionally, building a virtual machine using NAND gates can result in massive data requirements. This implies sharing large volumes of data among participating peers, which can be a challenge in terms of scalability and efficiency. 3. **Computational Complexity:** Creating the necessary circuits for BitVM, especially at more advanced levels of computation, requires a significant amount of computational power. This can be a barrier to broader implementations until optimizations are made. 4. **Possibility of Fork:** While BitVM can operate without the need for a fork, many developers see a fork, such as BIP119, as desirable to accelerate developments and further optimize the system. 5. **Reuse:** Currently, BitVM is unable to reuse its smart contracts, requiring the preprocessing of all requirements to establish a new contract, involving high data transfer volumes as well as the high processing required for off-chain circuit creation. *** ### Challenges BitVM, while promising, is still in its early stages of development and presents several technical challenges. In addition to the limitations mentioned, such as the need for large data volumes and the complexity associated with circuit creation, there are other aspects that deserve attention. One such challenge is the ability to create sidechains. Currently, BitVM does not yet support the creation of sidechains, which are chains parallel to the Bitcoin main blockchain. These sidechains have the potential to increase the scalability and functionality of Bitcoin, enabling faster transactions and the implementation of features not possible on the main blockchain. However, integrating sidechains with BitVM is still a goal to be achieved. Furthermore, BitVM, in its current form, does not support the creation of altcoins or other cryptocurrencies. This can be seen both as a limitation and as a safeguard. The creation of new coins or tokens, especially those with no intrinsic value or clear purpose, can attract fraudulent schemes and scams. These not only harm investors but can also attract unwanted regulatory attention to Bitcoin. BitVM's inability to create altcoins can therefore be seen as a protective measure against potential threats to the Bitcoin ecosystem. One notable limitation of BitVM is its "single-use" nature for smart contracts. Unlike platforms like Ethereum, where contracts have persistent addresses that anyone can call at any time, BitVM requires the creation of a new contract for each interaction. However, it is important to note that as BitVM evolves, new features and capabilities may be added. The developer community and stakeholders will need to address these challenges cautiously, ensuring that any innovation introduced into BitVM does not compromise the security, integrity, and reputation of Bitcoin. *** ### Conclusion BitVM, with its revolutionary proposal to introduce arbitrary computation capabilities into Bitcoin, represents a significant step in the evolution of the world's most renowned cryptocurrency. By using the NAND logic gate and the potential integration of technologies like Zero-Knowledge Proofs, BitVM aims to expand the functionalities of Bitcoin, allowing it to go beyond simple monetary transactions and enter the realm of smart contracts and decentralized applications. A practical and relevant use case for BitVM would be secure transactions, such as buying and selling vehicles or real estate. In traditional situations, fund transfers and document exchanges occur almost simultaneously, often with intermediaries to ensure transaction integrity. However, with BitVM, it would be possible to create smart contracts that ensure payment is only released after proper verification and transfer of all necessary documents. However, like any innovation, BitVM is not without challenges. The inability to reuse smart contracts, the need for large data volumes, the inherent complexity of circuit creation, the current limitation to a two-party system, and the high cost associated with a large number of on-chain transactions are obstacles that developers will need to overcome. Additionally, BitVM does not yet support the creation of sidechains or altcoins, which can be seen as a safeguard against potential threats to the Bitcoin ecosystem. Although BitVM can operate without the need for a fork, the developer community sees a fork, such as BIP119, as a desirable way to accelerate and optimize developments. The integration of such upgrades may be crucial to overcoming current challenges and unlocking the full potential of BitVM. In summary, BitVM represents one of the most exciting technical innovations in the Bitcoin space in recent times. While it is in its early stages and comes with significant challenges, the potential it offers to expand Bitcoin's capabilities is undeniable. The global community eagerly awaits future developments, hoping that BitVM can fulfill its promise and further solidify Bitcoin's position as a dominant force in the digital world. # Is BitVM the Next Evolution for Smart Contracts on Bitcoin? BitVM is a computing model that lets you run complex contracts on Bitcoin without altering its fundamental rules. Let’s take a look at what it is and how it can revolutionise the way we use Bitcoin. > original: ### What is BitVM? For years, Bitcoin has been the digital gold standard for cryptocurrencies. But one thing it lagged behind in was its ability to handle complex, [Turing-complete](https://en.wikipedia.org/wiki/Turing_completeness#:~:text=In%20colloquial%20usage%2C%20the%20terms,purpose%20computer%20or%20computer%20language.) smart contracts. [BitVM](https://bitvm.org/bitvm.pdf) was created by Robin Linus, who also created [ZeroSync](https://twitter.com/ZeroSync_), which is an implementation of [Stark Proofs](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) for Bitcoin. BitVM, short for “Bitcoin Virtual Machine,” can be envisioned as a secure, isolated environment embedded within Bitcoin’s ecosystem. In this virtualised space, you have the freedom to operate any computational program or execute any smart contract. However, here’s the interesting part: rather than carrying out these computations directly on the Bitcoin blockchain, which could be both costly and slow, BitVM merely authenticates them. It’s akin to a virtual test lab that allows you to simulate a program’s behaviour and confirm its outcomes, all without imposing any load or changes on the actual Bitcoin network. By serving as this middle layer, BitVM enhances efficiency and reduces the computational burden on the Bitcoin blockchain. This is particularly beneficial for operations that require complex computations or smart contracts, as it enables them to be validated off-chain before any irreversible actions are taken. This system thereby helps to maintain the integrity of the blockchain while also providing a platform for more complex, yet secure, operations. BitVM and [Ethereum’s EVM](https://ethereum.org/en/developers/docs/evm/) (Ethereum Virtual Machine) both offer smart contracting functionalities, but they differ in their approach and capabilities. Ethereum’s EVM is more versatile in supporting multi-party contracts and offers a broader array of computational tasks right on the blockchain, but this can lead to higher costs and a cluttered blockchain. BitVM, on the other hand, primarily focuses on two-party contracts and performs most of its computational work off-chain. This results in a minimal footprint on the Bitcoin blockchain and reduced transaction costs. However, BitVM’s current design limits its applicability in complex, multi-party settings, a domain where Ethereum’s EVM excels. ### How Does BitVM Work? BitVM operates on a simple yet powerful architecture involving two principal actors: the Prover and the Verifier. The Prover is the party that initiates a computation or claim, essentially saying, “Here’s a program, and here’s what I assert it will do or produce.” The Verifier, on the other hand, is responsible for validating that claim. This dual-role system enables a level of checks and balances, ensuring that the computational results are both accurate and trustworthy. The ingenuity of BitVM lies in its handling of computational workloads. Unlike conventional blockchain operations, which put significant computational burdens on-chain, BitVM performs most of its complex calculations off-chain. This drastically reduces the amount of data that needs to be stored directly on the Bitcoin blockchain, enhancing efficiency and lowering costs. This off-chain methodology also provides greater speed and flexibility, as developers or users can run intricate programs or simulations without worrying about overwhelming the blockchain. However, BitVM does employ on-chain verification when needed, especially in cases of disputes. Should the Verifier question the legitimacy of the Prover’s claim, the system will then refer to the unalterable, decentralised ledger of the Bitcoin blockchain to resolve the issue. This is accomplished through what are known as “[Fraud Proofs](https://www.bitdegree.org/crypto/learn/crypto-terms/what-is-fraud-proof).” If the Prover’s claim turns out to be false, the Verifier can submit a concise fraud proof to the blockchain, thereby exposing the dishonesty. This not only settles the dispute but also maintains the overall integrity of the system. By integrating both off-chain computations and on-chain verifications, BitVM has struck a balance that offers both computational efficiency and robust security. Optimistic Rollups are a Layer 2 scaling solution for blockchains that enable more efficient computation and data storage by performing most operations off-chain while maintaining the same level of security as on-chain transactions. The fundamental idea is to assume that all transactions are correct (“optimistic”) unless proven otherwise. Only if a dispute arises is the relevant data and computation published and verified on the main blockchain. This significantly reduces the amount of data that has to be stored on-chain, thereby freeing up space and lowering transaction fees. In BitVM, Optimistic Rollups can be particularly beneficial. Recall that BitVM primarily works with two parties: a Prover and a Verifier. Most of the computational work happens off-chain, reducing the amount of data that needs to be stored on the Bitcoin blockchain. When a transaction is initiated, BitVM can use Optimistic Rollups to bundle multiple off-chain transactions into a single on-chain transaction, further reducing the blockchain footprint. Moreover, in the event of a dispute, BitVM’s use of fraud proofs dovetails well with the “challenge-response” system inherent in Optimistic Rollups. If the Prover makes a false claim, the Verifier can quickly expose the dishonesty by providing a succinct fraud proof. This fraud proof would then be scrutinised within the Optimistic Rollup framework, and if validated, the dishonest party would be penalised. ### What New Capabilities Does BitVM Enable for Bitcoin? One of the most significant advantages of BitVM is its ability to facilitate more expressive and complex contracts. Traditional Bitcoin contracts have been largely confined to rudimentary operations, such as digital signatures and timelocks. BitVM revolutionises this space by offering a vast array of new possibilities for contract creation. Now, not only can users create contracts for financial transactions, but they can also construct them for more intricate Decentralised Applications (DApps) such as Chess, Go, or Poker games, or pretty much any kind of DApp that currently exists within Web3. Moreover, BitVM’s architecture makes it possible to develop truly decentralised prediction markets, enhancing the scope and functionality of what can be achieved through Bitcoin smart contracts. Another impressive feature of BitVM is its minimal footprint on the Bitcoin blockchain. By design, BitVM performs most of its computational work off-chain, thereby reducing the amount of data that needs to be stored directly on the blockchain. This has two major benefits. Firstly, it enhances the overall efficiency of the network as fewer resources are needed to verify transactions. Secondly, it prevents the blockchain from becoming cluttered with unnecessary data, preserving its streamlined operation and making it easier to manage and scale. This off-chain operation is particularly valuable in an era where blockchain bloat is a concern, maintaining the health and speed of the Bitcoin network. Finally, BitVM incorporates robust fraud safeguards to ensure the integrity of transactions. Using a system of fraud proofs coupled with a challenge-response protocol, BitVM guarantees that all transactions are honest and transparent. In the event that someone tries to cheat or submit false claims, the system’s Verifier can quickly catch and expose the dishonest party by submitting a succinct fraud proof to the blockchain. This not only serves as a strong deterrent against fraudulent activities but also enhances trust in the system, making BitVM a secure and reliable platform for a wide variety of applications. ### Nothing’s Perfect, What are BitVM’s Limitations? While BitVM offers a host of advantages, it is important to recognise its limitations as well. One of the most notable constraints is its design focus on two-party settings. This means that the system is currently not equipped to handle multi-party transactions or contracts, which limits its applicability in scenarios that require more complex interactions among multiple participants. As the world of Decentralised Finance (DeFi) continues to evolve towards more complicated ecosystems involving numerous parties, this limitation could hamper BitVM’s ability to keep pace with emerging needs and expectations. Another limitation is the requirement for both parties to perform substantial off-chain computation. While off-chain computations contribute to BitVM’s minimal impact on the blockchain, they also place a computational burden on the individual parties involved. Users must have the requisite computational resources to handle these tasks, and this can be prohibitive for those using less powerful hardware or those who wish to participate in numerous BitVM contracts simultaneously. Despite these limitations, it is worth noting that the technology is still in its very early developmental stages, as of now, it’s just a whitepaper. As it matures, it is likely that solutions will be found to address these challenges. Future versions of BitVM could potentially incorporate more advanced features that allow for multi-party settings. Concepts like linking multiple two-way channels to form a network—akin to Bitcoin’s Lightning Network—are already being considered as ways to expand the system’s capabilities. By adapting and evolving, BitVM has the potential to overcome its current limitations and continue to offer an increasingly versatile and efficient platform for Bitcoin-based transactions and contracts. # What is BitVM? A Beginner’s Guide to Turing-Complete Bitcoin Smart Contracts > original: # Simple explanation of BitVM > original: (Bitcoin magazine - [The Big Deal With BitVM: Arbitrary Computation Now Possible on Bitcoin Without a Fork](https://bitcoinmagazine.com/technical/the-big-deal-with-bitvm-arbitrary-computation-now-possible-on-bitcoin-without-a-fork) and LightningNetwork+ - [BitVM: Ushering in a New Era of Bitcoin Computations](https://lightningnetwork.plus/posts/450) did similar intro posts) ### How to convince people Suppose there is some complicated open-source program that takes 30 mins to run and in the end outputs 42. Peggy (the prover) could come up and say hey, I've taken the time to run this for all of you and 42 is the answer. Why should anyone trust her? Therefore she says I am willing to bet 1 BTC. But still In order to verify the answer you need to run the code on your machine. And thus the fact Peggy did it before does not help. If you see 42 you can then start convincing people "wow she was right, trust our computation". But for an outsider that is indistinguishable from a shill Peggy paid to confirm her false result. You might also start proclaiming I've got 43 on my terminal Peggy now owes me 1 BTC. How can such a bet ever get resolved? Obviously another trusted third party can still be lying. Also the majority of votes is not enough. To keep that 1 BTC Peggy might have created some fake forum posts as if 10 people confirmed her result (Sybil attack). You could couple that with a PoS like scheme (based on money or reputation) but this would still be shitty. ### Simple addition Now let's say instead of a long running computation the program is just 32+10 (but the majority of people still don't want to calculate this on their own). In this case bitcoin script could help. Peggy could create a "smart contract" in a sense after a 2 day timelock I can get my 1 BTC back but in the meantime anybody (first one) who comes up with a number X that is not 42 (`42 OP_EQUAL OP_NOT`) and the result of 32+10 (`32 10 OP_SUM`) can take my money. Now if she was lying and do the thing with 43 (trying to convince the world about the wrong result) two things could happen. Either nobody would notice or because there is 1 BTC for grabs Victor (the verifier) could come along, run the computation on his computer and be like oh cool I can just spend that 1 BTC of hers by providing 42 (the fraud proof). By claiming the money he makes everyone a favor since people are able to see Peggy was lying. \* Actually in such a scheme a miner could take all the money, but oh well, let's ignore that here ### BitVM The problem is just that bitcoin script is quite basic. It does not allow for constructs we are used from regular programming languages like loops. But this is by design. BitVM is a way to "chop up" that open-source code everyone has access to into smaller parts and put those on the bitcoin blockchain. Since tapscript is used you don't need to actually put this gigantic mess on-chain (only the root of that "tree"). Similar as a real computer that is built out of a huge number of logic gates, each part is a collection of boolean gates. Now Victor can play a game with Peggy on the validity of a specific simple part of the computation. (All parts need to be ok in order for everything to work out, but we are basically doing just random audits.) If Victor finds out Peggy was lying similar as previously explained he can publish the fraud proof on-chain (this small part is simple enough so bitcoin can be the "enforcer", afterall bitcoin knows about `OP_AND`, `OP_OR` and `OP_NOT`). Also if Peggy is not cooperative Victor can get her 1 BTC. Basically during that X days Victor can do multiple checks (limited by the initial construction). In the end he can be convinced Peggy actually ran the code and got 42 or get 1 BTC richer. In order for Peggy to play along there could be some direct monetary benefit attached for her too. The remarkable thing here is that bitcoin is able to be the trusted third party for an arbitrary turing complete computation despite the fact bitcoin script is not able to actually execute it. ### Caveats The BitVM protocol requires a lot of (off-chain) interactivity ("chatter") between Peggy and Victor. People think it is highly likely Peggy executed the code because there is always the possibility some honest Victor comes along and "exposes" Peggy in a verifiable way on-chain to collect the reward. However this is not a proof. Also the fact some Victor is doing a verification does not help, because Peggy could collude with him. In the end Victor is convinced beyond doubt but he still isn't able to prove Peggy was honest to everyone else. People say this will enable the construction of Ethereum like smart-contracts on Bitcoin. But I believe this is quite cumbersome and likely not even the primary design goal. BitVM it is more like [TrueBit](https://truebit.io/) protocol for arbitrary computation. Because also on Ethereum despite the fact the language is Turing complete not all computation is possible (beside not being affordable due to high gas price). That is because every node on the network has to redo all the computation in order to check so you can't have something that takes 30 min for instance (unless miners are cheating and just trusting the stuff blindly). ### Lightning comparison I just realized the stuff is a quite similar to lightning. When a new Victor comes along he basically opens a dual funded channel with Peggy (both contribute 1 BTC). They do a lot of computation up-front and then agree that after X days Peggy will part with 1.1 BTC and Victor with 0.9 BTC. Then if during that time Victor is able to prove Peggy was cheating he "force-closes" the channel and ends up with 2 BTC. But in a similar way Peggy can also flag an "impossible question" from Victor and get 2 BTC. Obviously this requires the monetary incentives to align perfectly or nobody will be willing to open "new channels". Adam Back also compared the scheme to [ZKCP](https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/). ### More Read more in the [BitVM whitepaper](https://bitvm.org/bitvm.pdf) or the [tapleaf circuits implementation](https://github.com/supertestnet/tapleaf-circuits/). # BitVM Primer > orginal: By Tyler Whittle ([@Dr\_DAO\_](https://twitter.com/Dr_DAO_)) ### Introduction Welcome to the BitVM primer! If you read the abstract below and get it on the first go, kudos to you. Please reach out to me so I can offer you a job at the [Taproot Wizards](https://taprootwizards.com/). If you’re like the 99% of us who are left simultaneously excited and confused, read on! ***Abstract - BitVM: Compute Anything on Bitcoin*** *BitVM is a computing paradigm to express Turing-complete Bitcoin contracts. This requires no changes to the network’s consensus rules. Rather than executing computations on Bitcoin, they are merely verified, similar to optimistic rollups. A prover makes a claim that a given function evaluates for some particular inputs to some specific output. If that claim is false, then the verifier can perform a succinct fraud proof and punish the prover. Using this mechanism, any computable function can be verified on Bitcoin.* *Committing to a large program in a Taproot address requires significant amounts of off-chain computation and communication, however the resulting on-chain footprint is minimal. As long as both parties collaborate, they can perform arbitrarily complex, stateful off-chain computation, without leaving any trace in the chain. On-chain execution is required only in case of a dispute.* Though it might be hard to distill from the abstract, BitVM marks a paradigm shift in what we thought was possible on Bitcoin. Put simply, the BitVM allows arbitrary computation to be executed on Bitcoin. Okay, “arbitrary computation” is a mouthful and doesn’t really help a non-technical reader. So let me give you an example: Chess. ### Chess, Programs, & Smart Contract Languages Chess is an example of a well-defined program with set constraints and a win condition. You have certain pieces that can move in certain ways around an 8x8 board. You know the game is over when a king is captured or neither player is able to win. You can consider chess a program with some arbitrary computation (e.g. there is not a chess.move\_knight(F4) command built into Bitcoin). Now let’s say Vicky and Paul want to play a game of chess against each other. What’s more, they want to make a big bet on it: 1 BTC to the winner! Given this game has such large stakes, they want a way to verify who won. Before blockchains, Vicky & Paul’s best bet was to find a trusted third party (let’s call him Terrance) who would observe the game, declare a winner, and custody/pay out the 1 BTC. But what if Terrance wasn’t so trustworthy? Maybe Terrance decides to run away and keep the 1 BTC for himself. Maybe Paul bribed Terrance to declare him the winner no matter what. Neither of these situations (or the myriad of others that could potentially arise) are ideal. Enter blockchains! A primary advantage of blockchains is that they shift the need to trust another human to the need to trust cryptography and code. So why don’t we see an on-chain chess game on Bitcoin like we [do on Ethereum](https://betterprogramming.pub/on-chain-chess-smart-contract-breakdown-7d01cdaaeb54)1? The answer lies in Bitcoin’s underlying language: [Script](https://en.bitcoin.it/wiki/Script). ### Bitcoin Script As an analogy, think of Bitcoin/Script like your high-school calculator and Ethereum/Solidity like your iPhone (or Android if you’re like me). Your iPhone can run any program an app developer can cook up. Your calculator, on the other hand, is relegated to some numbers and a few mathematical functions. Maybe there are a few extra buttons for some calculus on there, but no one is mistaking your TI-83 for an iPhone. Ethereum’s smart contract language, Solidity, is considered “[Turing complete](https://en.wikipedia.org/wiki/Turing_completeness#:~:text=In%20colloquial%20usage%2C%20the%20terms,purpose%20computer%20or%20computer%20language.)”. While this isn’t strictly true, it’s used in this context to mean Solidity can run pretty much any program imaginable. Chess, a Defi protocol, a zero-knowledge proof verifier - these can all be implemented directly on Ethereum. Script, however, is not considered Turing complete. This means it wasn’t possible to run all those cool programs you see on other chains on Bitcoin (until now!). \ If you clicked on the [Script link](https://en.bitcoin.it/wiki/Script) earlier, you’ll have seen a list of these things called opcodes. These are essentially the buttons of the Bitcoin calculator. You’ll see opcodes for simple things like addition (OP\_ADD) and cryptographic operations like hashing (OP\_SHA256). There are \~100 opcodes on Bitcoin, and they are specifically designed to limit the complexity of the computation that can be done. For example, as of writing there is not an opcode to multiply two numbers, nor is there an opcode to add to strings together. Satoshi removed these and many other opcodes very early in Bitcoin’s life to ensure that Script was not Turing complete. ### Bitcoin Nodes & Avoiding Arbitrarily Long Compute So why did Satoshi make Bitcoin so restrictive? The answer lies in the economics of Bitcoin. Bitcoin’s security relies on decentralization. It relies on users like you and me to run nodes and VERIFY that the transactions submitted to the network are valid. A full node runs the computation of every transaction in every block on the network. And unlike Ethereum, the fee a user must pay to get their transaction included is only loosely related to the amount of computation required to execute the transaction.2 Now think what might happen if someone got a transaction included in a block that took 2 hours for a node to run. That would effectively be a DDoS on the Bitcoin network! Nodes are expected to verify a block in a timely manner because miners can’t add a new block until the previous one is verified. By restricting the language of Bitcoin, Satoshi ensured the amount of computation required for a node to verify a block would never spiral out of control. Enter BitVM… What [Robin](https://twitter.com/robin_linus?lang=en) and the clever team at [ZeroSync](https://zerosync.org/) have figured out is a way to allow those arbitrary programs to be executed on Bitcoin without making every full node run every line in the program. BitVM achieves this through some crazy wizardry. First it simulates [Boolean logic gates](https://en.wikipedia.org/wiki/Logic_gate) (the building block of computers) within Script. Then, it uses something called hashlocks and the structure of taproot addresses to verify the arbitrary computation. Finally, through an elegant challenge protocol, the Bitcoin network can adjudicate which party (Paul or Vicky in our example) is correct. We’ll be diving deep into how that all works in future installments. Alternatively, [Shinobi’s article](https://bitcoinmagazine.com/technical/the-big-deal-with-bitvm-arbitrary-computation-now-possible-on-bitcoin-without-a-fork) gives a high-level overview for the curious reader. For now, let’s pop back up a level and talk about what this means. ### What does BitVM enable? With all that background knowledge out of the way, we’re brought back to BitVM. BitVM has created a way to verify arbitrary computation on Bitcoin. Before BitVM, Paul and Vicky couldn’t have played their chess game and had the result verified by Bitcoin. Now they can! BitVM will allow them to deposit 0.5 BTC each into a 2/2 multisig address that they both control. If they both agree that Vicky won, they both sign a transaction that sends the 1 BTC to Vicky. Easy peasy! If they disagree, however, there is a way to verify every chess move that happened **on Bitcoin** and **force** Paul to send Vicky the 1 BTC. This is what makes BitVM so special. While [chess is a cool example](https://github.com/mcbagz/LogicGates/blob/main/Example.ipynb), the design space on BitVM is limitless. It will allow users to verify that almost any program ran correctly all directly on Bitcoin! We’re just a few weeks in, and we’re already seeing strong groups [hacking away on toy programs](https://github.com/supertestnet/tapleaf-circuits) to test out this new system. As for me, I’m most excited about the potential for BitVM to: a). enable trust-minimized bridges, and b.) verify zero-knowledge proofs. These are two key components of a zero knowledge (zk) rollup. If you aren’t familiar with zk rollups, I recommend [this article](https://mirror.xyz/twhittle.eth/JU2OOxTJO6LLKjd99Dan9lA-z09iOAxrInXn5JHx9wA) where I cover why Bitcoin will ultimately need zk rollups. *tl;dr* zk-rollups are the holy grail of scaling Bitcoin. If BitVM turns Bitcoin from a calculator into an iPhone, then zk rollups will transform that iPhone into a supercomputer. Up until now, zk rollups haven’t been built on Bitcoin because there was no way to trustlessly get BTC from the main chain to the rollup, nor to verify zk proofs. With BitVM, we just may be able to do both! If BitVM can supercharge Bitcoin to enable zk rollups, a new era of fully on-chain Bitcoin applications is about to explode. Defi, DAOs, gaming, etc. will all be coming to Bitcoin. THIS, dear readers, is the promise of BitVM. It should have you stoked to see what comes next! *This concludes the BitVM Primer. I’m considering making this Part I in a series that walks the non-technical reader through the BitVM (full outline below). If that gets you excited, please let me know in the comments or on* [*Twitter (@Dr\_DAO\_)*](https://github.com/twhit223/bitvm_primer/blob/main/x.com/Dr_DAO_). *I’m always looking for new ways to help the community better understand Bitcoin.* *Example BitVM Walkthrough* * *Part I: What is BitVM and why should I care? (this article)* * *Part II: Computers, Programs, and Circuits* * *Part II: Committing to a Program on Bitcoin* * *Part IV: The Challenge Protocol* * *Part V: What challenges does BitVM face?* Huge shoutouts to [Dazza](https://twitter.com/dazza9x), [English](https://twitter.com/EnglishNFTea), [Isabel](https://twitter.com/isabelfoxenduke), [Jan](https://twitter.com/nonfungible_jan), , & [Super Testnet](https://twitter.com/super_testnet) for their thoughtful comments on this article. ### Notes # Things BitVM needs > original: A todo list for making bitvm great ## Implementations * [ ] Create github repos for more implementations of bitvm * [ ] E.g. one in rust * [ ] E.g. one in python * [ ] E.g. one in typescript * [ ] Improve [my javascript implementation](https://github.com/supertestnet/tapleaf-circuits/) * [ ] Prototype a bisection protocol -- there are no implementations yet! * [ ] "Translate" more circuit description formats so that bitvm isn't limited to "only" using bristol formatted circuits * [ ] E.g. here are some other circuit description formats: * [ ] “ABY format” (described [here](https://github.com/encryptogroup/ABY/blob/public/bin/circ/circuitformat.md), examples [here](https://github.com/encryptogroup/ABY/tree/public/bin/circ)) * [ ] “Fairplay’s Secure Hardware Definition Language (SHDL)” (examples [here](https://github.com/Ethsnarks/ethsnarks-sfdl)) * [ ] “Simple Circuit Description (SCD)” used by the TinyGarble compiler (described [here](https://github.com/esonghori/TinyGarble/tree/master/scd), I can’t find examples, but according to [this document](https://github.com/esonghori/TinyGarble) you can compile TinyGarble to find examples in bin/scd/netlists/). * [ ] "Verilog Netlists" (pictured [here](https://www.researchgate.net/profile/Kundan-Nepal/publication/220405407/figure/fig3/AS:670715174985734@1536922367281/C17-schematic-and-structural-verilog-netlist.png)) ## Programming * [ ] Develop and document a toolchain for making bitvm applications * [ ] One possible toolchain: write app in python, export for bitvm using "circuit" and "bfcl" libraries, test/debug/deploy * [ ] Another possible toolchain: write app in C, export for bitvm using HyCC, test/debug/deploy * [ ] My current toolchain: find a bristol circuit, test it using a tester I wrote in js, give up if I can't make it work as expected, otherwise convert it to a tapleaf circuit using the procedure outlined [here](https://github.com/supertestnet/tapleaf-circuits/), do a final test, and add a button for it on [this site](https://supertestnet.github.io/tapleaf-circuits/) * [ ] Make a high level programming language that compiles programs down to the "bristol formatted" logical circuits that bitvm currently uses * [ ] Make an IDE to help developers design apps by "hooking together" logic circuits that already work in bitvm * [ ] Contribute to [the chess app](https://github.com/mcbagz/LogicGates/tree/main) * [ ] Contribute to [the python toolchain](https://twitter.com/rot13maxi/status/1713731080912527404) ## Functions * [ ] Make a 32 bit multiplier in bitcoin script * [ ] Make a bunch of functions that help with making a sha256 implementation, such as: * [ ] Make a function for doing 6 "right rotations" on a 32 bit string (e.g. if the string was 00000000000000000000000111110000, a right-rotation by 6 digits would turn it into 11000000000000000000000000000111 -- it shifts everything over by 6 and moves stuff that "falls off the end" over to the start) * [ ] Make a function for doing 2 right rotations * [ ] Make a function for doing 7 right rotations * [ ] Make a function for doing 10 right rotations * [ ] Make a function for doing 11 right rotations * [ ] Make a function for doing 13 right rotations * [ ] Make a function for doing 17 right rotations * [ ] Make a function for doing 18 right rotations * [ ] Make a function for doing 19 right rotations * [ ] Make a function for doing 22 right rotations * [ ] Make a function for doing 25 right rotations * [ ] Make a function for doing 3 "right shifts" on a 32 bit string (e.g. if the string was 00000000000000000000000001111100, a right-shift by 3 digits would turn it into 00000000000000000000000000001111 -- it shifts everything over by 3 and discards anything that "falls off the end") * [ ] Make a function for doing 10 right shifts * [ ] Make a sha256 function that "pads" inputs to a multiple of 512 bits ## DevEd * [ ] Contribute to [this playlist](https://github.com/supertestnet/bitvm_deved_videos) of youtube videos documenting how to write apps for bitvm * [ ] Make text tutorials documenting how to write apps for bitvm * [ ] Contribute to [the FAQ](https://github.com/PraiseTheMithra/BitVm-FAQ) -- it should have less tech-talk and focus more on a high level overview of what we're doing (this will help devs AND everyone else too) * [ ] Help me improve the visual look and feel of [this showcase](https://supertestnet.github.io/tapleaf-circuits/) of bitvm apps (fork it [here](https://github.com/supertestnet/tapleaf-circuits/), make it better, do a PR) ## Money * [ ] Devs can be either *attracted* to a project or *hired* for a project, or both. If you can't contribute via code, consider giving money so Robin can *hire* devs to work on bitvm: bc1qf5g6z0py2t3t49gupeqrlewga0qz2etalu4xf9 ## Meta * [ ] Contribute to this todo list with other ideas for making bitvm great (click the Fork button above and do a PR with your changes) # BitVM explained in 4 slides > original: BitVM explained in 4 slides [Image](https://twitter.com/BTCillustrated/status/1712440417524810227/photo/1) [![Image](https://pbs.twimg.com/media/F8PO47dXkAA_jCR?format=jpg\&name=small)](https://twitter.com/BTCillustrated/status/1712440417524810227/photo/2) [![Image](https://pbs.twimg.com/media/F8PO5XeWAAAQF2I?format=jpg\&name=small)](https://twitter.com/BTCillustrated/status/1712440417524810227/photo/3) [![Image](https://pbs.twimg.com/media/F8PO57_XkAA1aB8?format=jpg\&name=small)](https://twitter.com/BTCillustrated/status/1712440417524810227/photo/4)
# THE BIG DEAL WITH BITVM: ARBITRARY COMPUTATION NOW POSSIBLE ON BITCOIN WITHOUT A FORK Any arbitrary computation can now be verified on Bitcoin, with no softfork necessary, in a challenge-response based protocol that can be enforced on-chain. > original: Fear the wizards. Not those wizards, real wizards. Announced today by developer Robin Linus of ZeroSync, an association founded to help scale Bitcoin by using zero-knowledge proofs, [BitVM](https://bitvm.org/bitvm.pdf) is a proposal that opens very interesting doors for Bitcoin application development going forward. It can enable pretty much any arbitrary computation, and use that computation to enforce what happens to bitcoin on-chain. It requires no consensus changes to Bitcoin at all. The trick is lifting all of that logic off-chain and being able to challenge a few steps of the computation on-chain if the other party asserts a dishonest outcome. In short, BitVM will bring arbitrary Turing-complete computation, in an enforceable way, to bitcoin itself – today. ## **THE BASICS OF LOGIC GATES** To really grasp the mechanisms behind the proposal, we need to understand a little bit about the physical and logical basis of computation. Everyone knows that under the hood your computer is just passing around individual 1s and 0s to do everything it does, but how does that work? What does it mean? Every single chip in your computer at its core is composed of millions or billions of individual things called logic gates. These little devices take either one or two "bits" of information, a 1 or a 0, and perform a simple logical operation on them to produce either a 1 or a 0 as an output, which then feeds into the next logic gate. There are many different types of logic gates, some that just take a single bit and put out the same number fed into it (the buffer gate). Others take a single bit and output the opposite value it receives (the NOT gate, or an inverter). Some take two bits, and output a 1 if both input bits are 1, with any other combination outputting a 0 (the AND gate). Lastly, at least here today in this list of examples, is a gate that takes two bits and outputs 0 if both inputs are 1s, and outputs 1 for all other bit combinations (the NAND gate). The interesting thing about a NAND gate is you can build any other type of logic gate from just NAND gates. It definitely won't be as efficient as just making a special purpose version of the other gate, but it will get the job done. So, given that you can build any logic gate out of NAND gates, you can build circuits for any arbitrary computation out of NAND gates. ## **BUILDING NAND ON BITCOIN** Now how do you build a NAND gate with existing Bitcoin script? Hashlocks and two other op codes you are probably unfamiliar with: OP\_BOOLAND and OP\_NOT. First, let's look at the hashlocks. You create a branching script that can be spent one of two ways, revealing the preimage to hashlock A, or revealing the preimage to hashlock B. Path A would put the number 1 on the stack, and Path B would put the number 0. This allows you to "unlock" a bit to be used as an input to the NAND gate we are building by providing the preimage to the hashlock. You can only fulfill the script with one or the other, not both, and there are reasons we will get into shortly for this. This simple primitive is just there to allow users to commit to single bits at a time for use in a NAND gate script. Now think back to what a NAND gate is, it takes two bits and outputs one. If the input bits are both 1s, then the output has to be a zero. If the input bits are any other combination the output is a 1. You can use the two-path hashlock trick above to commit to both inputs, as well as the output, you just need a way to verify the output is correct. This is where OP\_BOOLAND and OP\_NOT come in. After you have picked which values to assign as inputs, and which output value to verify it against, you can take advantage of a neat trick. OP\_BOOLAND does the exact opposite that NAND does, if both inputs are 1s, the output is 1. Everything else outputs 0. OP\_NOT takes whatever value is input and reverses it, a 1 becomes a zero and vice versa. This allows you to take the two input values and actually do a NAND operation on them *on the scripting stack*. You can then verify the output of that against the asserted output committed to with the hashlock trick using OP\_EQUALVERIFY. The script will not pass evaluation if the actual NAND operation output created on the stack doesn't match the output the user claims it will produce. You now have a NAND gate implemented in Bitcoin script, in a way that *actually enforces with Bitcoin script the virtual NAND gate operates correctly*. ## **WHERE THE ARBITRARY COMPUTATION COMES IN** So what can you do now that you can make a single NAND gate in Bitcoin script? You can create an entire tapleaf tree that covers every single step of any arbitrary computation, just like actual logic gates do to make computer processors. To accomplish complex computation, people put logic gates together in series, so that once you feed the initial inputs into the first gates, the output of each of them feeds right into another gate as input. The same thing is accomplished here by tying hashlocks together appropriately between gates. I.e. if one gate script has a choice between the preimages for value C1 or C2 as an output, the next gate in the series uses those same hashlock values in the matching input. This way the only way for someone to lie about the result from the previous gate is to reveal the other C hashlock. We can use this for a penalty mechanism. Both users take whatever computation they want to engage in, and break it down into a circuit of only NAND gates doing the computation gate by gate. They then take and encode every individual gate in the circuit, with the appropriate hashlock choices for each circuit step, and encode it into a tapleaf tree that a single UTXO can be locked to. There is one version of the tree for the user trying to prove they are executing the program correctly, and one version for the person verifying it is executed correctly. Now what they do is pre-sign a series of transactions for a challenge and response game that can be executed on-chain. Ideally the entire computation is run through and verified off-chain, and users cooperatively settle it by spending the funds together to the appropriate person based on the computations outcome. If the prover stops cooperating however, the verifier can challenge them on-chain. Step one is loading money into the scheme. One script path will let the prover just claim the money unilaterally after a timelock. The next script path will let the verifier instantly claim the money if they can show the preimages to both the possible values for any input or output of the current gate. The next script path will allow the verifier to force the prover to execute any specific gate contract on-chain (i.e. the one right after they stopped cooperating with off-chain). This path requires the verifier to release another hashlock preimage that only they have, functioning as a lock for each gate challenge to the prover. This guarantees the prover can only execute that specific gate. The verifier's pre-signed transaction for that path will spend it to a script with the following script paths: the verifier takes the coins after a timelock, or the prover executes the gate and spends the coin back into a script like the first one, the prover can claim the money after a timelock, the verifier can claim it instantly if showing both preimages to any single hashlock pair, or the verifier can challenge the prover again. Only a few rounds of this scheme will guarantee the contract settles correctly. Either the verifier runs out of pre-signed transactions to keep challenging the prover, because the prover keeps demonstrating correct execution of each gate, and the prover claims the fund; or, the prover does not respond to a challenge because it would allow them to be penalized, and the verifier claims the funds after a timelock; or the prover actually does execute a gate incorrectly on-chain and the verifier claims the funds immediately. Ideally everything happens off-chain and is settled cooperatively, but if cooperation fails there literally is no other outcome after just a few rounds on-chain than the contract settling correctly. ## **WHERE TO GO FROM HERE** Certainly, a proposal of this magnitude will be discussed for some weeks going forward. The amount of data needed to be processed and generated is *enormous*. We are talking taptrees with leaves numbered in the billions, and pre-signed transactions to go with them all at least a few hops long to ensure accurate settlement. The off-chain data management cost is absolutely massive. The other big limitation is this scheme will only work with two parties, one playing the role of proving correct execution, and the second playing the role of verifying it. While it is possible future research finds a way to generalize this to more participants, I at least see no clear path to accomplishing that. Also, even addressing that particular problem, I see no way to get around that this is an interactive protocol requiring participation at all times by all participants in the cooperative case. Nonetheless, this is a very interesting demonstration of how complex programs can be used to enforce conditional control over Bitcoin. There is definitely room for optimization in terms of how much logic can be packed into a single leaf script, or what can be done with different op codes to make the entire scheme more efficient. Simple deconstruction to the basic operations and game theoretic balances can enforce any arbitrary computation using Bitcoin. Truly the creation of wizards. # Deep dive into BitVM -Computing paradigm to express Turing-complete Bitcoin contracts- > original: > > author: [Ichiro Kuwahara](https://medium.com/@kuwahara_18214?source=user_profile-------------------------------------)
## What is BitVM? BitVM is a *“Computing paradigm to express Turing-complete Bitcoin contracts”* [proposed](https://bitvm.org/bitvm.pdf) by Robin Linus, which does not require a soft fork. Bitcoin script is designed to be Turing-incomplete, making it impossible to implement arbitrary contracts like those implemented on VM-based chains. Previous proposals to realize Turing-complete contracts on Bitcoin required a soft fork to activate new opcodes. BitVM is different from these proposals as it does not require one. Please note that it still has important limitations:\ ・Contracts are limited to those between two parties\ ・A significant amount of computation and interaction between the two parties is required (i.e., Hundreds of MB to several GB data interaction; local storage)\ Despite these constraints, the proposal has spurred vibrant community debate. The section below details how to establish contracts between a Prover, who asserts they know the answer of a specified problem, and a Verifier, who assesses the truth of that assertion.\ As long as both parties are cooperative, they can jointly settle any contract.\ If the Verifier does not agree that the Prover’s assertion is correct, a “Challenge and Response” scheme is initiated — this will be explained in detail later — and if the assertion’s inconsistencies are identified, the Verifier is entitled to seize the funds of the Prover. Before touching on how BitVM works, we will provide some preliminaries. ## **Preliminaries** **⚫️Logic Circuits**\ Code written in a programming language is converted into binary code (a series of 0s and 1s) by a compiler. The processor reads this binary code and executes instructions using logic circuits.\ Typical examples of components that make up logic circuits include AND gates, OR gates, NOT gates, and NAND gates. NAND gates are called “universal gates” because they can be used to build up all other gates.
In the paper NAND gates are used only for the sake of the argument, to abstract away all the complexity of crafting efficient bitcoin scripts. We refer to this circuit as a “Binary Circuit”.\ The author believes that\ *In practice using all the available bitcoin script opcodes makes onchain TXs 10x — 100x smaller than when using only NANDs.* The following figure shows a Binary Circuit with A, B, C, and D as inputs. The Prover claims that (s)he knows all inputs.
**⚫️OP\_NAND**\ Bitcoin’s existing Opcodes, OP\_BOOLAND and OP\_NOT can be combined to perform the functions of a NAND operation. We refer to this combination of OP\_BOOLAND and OP\_NOT as “OP\_NAND”. **⚫️Bit Value Commitment**\ The following is a script for the prover to commit to the input and output values (0 or 1) of each NAND gate: If the prover provides a preimage of hash1, \`1\` is pushed onto the stack. If the prover provides a preimage of hash0, \`0\`’ is pushed onto the stack. We refer to these Opcode sets as “OP\_BIT\_COMMITMENT”. ``` OP_IF OP_HASH160 OP_EQUALVERIFY <1> OP_ELSE OP_HASH160 OP_EQUALVERIFY <0> OP_ENDIF ``` **⚫️Binary Gate Commitment**
The following is a script for the Prover to commit to a LogicGate (NAND1) by combining OP\_NAND and OP\_BITCOMMITMENT. When they provide the following three values, three sets of values (0 or 1), namely A, B, and E, are pushed onto the stack. ``` ・Preimage of HashA0 or HashA1 ・Preimage of HashB0 or HashB1 ・Preimage of HashE0 or HashE1 ``` If the statement A NAND B == E holds true, this script can be unlocked. ``` // Reveal Preimage of hashE0 or hashE1 OP_BITCOMMITMENT OP_TOALTSTACK // Now the bit value of "E" is on the stack // Reveal Preimage of hashB0 or hashB1 OP_BITCOMMITMENT OP_TOALTSTACK // Now the bit value of "B" is on the stack // Reveal Preimage of hashA0 or hashA1 OP_BITCOMMITMENT OP_TOALTSTACK // Now the bit value of "A" is on the stack // // Verify that "A NAND B == E" // // Read "B" from alt stack OP_FROMALTSTACK #compute A NAND B OP_NAND # Read "E" from alt stack OP_FROMALTSTACK #Check A NAND B == E OP_EQUALVERIFY ``` **⚫️Challenge and Response**\ Challenge and Response is initiated when the Verifier does not agree that the Prover’s assertion is correct. If the assertion’s inconsistencies are identified, the Verifier is entitled to seize the funds of the Prover. The verifier selects one gate from the circuit, and the prover exposes the input and output (we refer to it as opening a Gate). Both parties repeat this process several times, until either an inconsistency is revealed, or the Verifier exhausted the space of possible challenges.\ If the Prover claims that D=1 when one gate is opened, but later claims that D=0 when another gate is opened, the prover has equivocated and the Verifier is able to seize the funds of the Prover. Note that the Prover is not required to open every Gate.\ In the example below, the Verifier asks the Prover to open NAND7, NAND1, NAND3,NAND6 and NAND5 in order.
Initially, when requested to open NAND6, the Prover asserts “I=1”. However, subsequently when asked to open NAND1, NAND3, NAND6, and then NAND5, the Prover is compelled to give the contradictory response of “I=0”. When asked to open NAND6, if the Prover realizes that it will give a contradictory answer regarding the value of I and does not open it, the Verifier is able to seize the funds of the Prover after a certain period of time. **⚫️Challenge Taptree and Response Taptree**\ A Taptree is used for both parties to commit to the Challenge and Response scheme. A Taptree is a Merkle tree composed of scripts as leaves, and a root (the Taproot) that can be used to tweak a secret key, enabling the use of either a key (the key path) or a script within the Taptree (a script path) to unlock an output.\ In the following example, the Verifier selects Gate7 by exposing the unlock condition of the Challenge Taptree and the Prover opens Gate7 by exposing the unlock condition of the Response Taptree.
If the Prover exposes a different value for the same variable (e.g. E=0 && E=1 ), the claim of the Prover is false and the Verifier can get all funds. This model is realized by following Equivocations Taptree.
So far we have learned that the Prover and the Verifier commit to logic gates using a combination of Bitcoin scripts and that Taptrees are used to commit to proof verification based on a Challenge & Response protocol.\ In the following sections, we will explain the details of the BitVM protocol. ## **BitVM Protocol Detail** The following is the flow of a contract using BitVM between the Prover who claims to know the value that satisfies some arbitrary equation and the Verifier. **1. Circuit Construction**\ The contract is implemented in a programming language and is compiled into a large Binary Circuit; the Prover claims that a certain set of Inputs given to the circuit evaluates to a certain Output. **2.Transaction construction and Pre-signing**\ A transaction is constructed and pre-signed between Prover and Verifier to commit to the Binary circuit input value proof and verification scheme. **3.Contract execution**\ Both parties sign and broadcast the Tx1 in figure below to lock their funds. Once the transaction is confirmed, the contract is executed.
Tx1 is on-chain, while Tx2\~Tx4 have not yet been broadcast. Tx2 and Tx4 are held by the Verifier and Tx3 by the Prover. Please note that the diagram above differs from the original proposal.In the figure above, the output of the first transaction is divided into two parts and sighasg\_all is used for pre-signing. If the output is not split, all tapleafs that may be used must be pre-signed. Please see [here](https://twitter.com/n1ckler/status/1711479253387051388) for the details. If the Verifier accepts that the Prover’s claim is correct, they skip the ‘4. Challenge & Response’ step and proceed to the ‘5. Settlement’ step. If the Verifier thinks the claim of the Prover is incorrect, they proceed to the ‘4. Challenge & Response’ step. **4.Challenge & Response**\ The Verifier selects a gate of his choice by exposing the unlock conditions of the Challenge Taptree, and the Prover opens the gate by exposing the unlock conditions of the Response Taptree.\ Ideally, this interaction is performed off-chain.(It can also be executed on-chain although)\ Both parties repeat this process several times, until either an inconsistency is revealed, or the Verifier exhausted the space of possible challenges. The following is an example of the Prover and Verifier repeating the Challenge & Response twice off-chain and an inconsistency is revealed.
In the first Challenge, the Verifier selects the NAND1 gate, and the Prover exposes its input and output (A=1, B=1, E=0). In the second Challenge, the Verifier selects the NAND4 gate and the Prover exposes its Input, output(E=1,F=1,H=0).\ Note that the Prover has an inconsistent response, E=0 the first time and E=1 the second time. Since the Prover has equivocated, the Verifier proceeds to the ‘5. Settlement’ step to seize the Prover’s fund. **5.Settlement**\ If the Verifier accepts that the Prover’s claim is correct in the ‘3. Contract Execution’ step, they skip the ‘4. Challenge and Response’ step. As long as both parties are cooperative, they can jointly settle any contract with a 2-of-2 signature. If the Prover has an inconsistent response, in ‘4. Challenge & Response’ step like E=0 the first time and E=1 the second time, The Verifier gets preimage(E=0) and preimage(E=1), which are conditions that Equivocations Taproot address can be unlocked.\ The Verifier gets the Prover’s fund by broadcasting Tx6 as below.
## **Further development** **・More high-level opcode for efficiency**\ Robin Linus states NANDs are used only for the sake of the argument, to abstract away all the complexity of crafting efficient bitcoin scripts.\ He believes that in practice using all the available bitcoin script opcodes makes onchain TXs 10x — 100x smaller than when using only NANDs.\ That’s why some [more high-level opcodes](https://github.com/BitVM/BitVM/tree/main/opcodes) for stuff like u32 addition, u32 xor, u32 rotations are created. **・More general contracts**\ The proposed model is limited to two parties. More research is needed to develop this model to N:N. **・Scriptless Script BitVM**\ ZmnSCPxj [stated](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021997.html) “Scriptless Script BitVM” by replacing hashes and preimages with points and scalars. Using this trick, we can reduce the Tx size and on-chain footprint. ## **Conclusion** BitVM is a project that enables Turing-complete Bitcoin contracts without soft forks.\ If you would like to contribute, [here](https://github.com/BitVM/BitVM/tree/main) is the Repo.Also you can discuss this topic in [Telegram group](https://t.me/bitVM_chat). [Bitcoin](https://medium.com/tag/bitcoin?source=post_page-----1c6cb05edfca---------------bitcoin-----------------)[Bitvm](https://medium.com/tag/bitvm?source=post_page-----1c6cb05edfca---------------bitvm-----------------)[Offchain](https://medium.com/tag/offchain?source=post_page-----1c6cb05edfca---------------offchain-----------------)[
](https://medium.com/tag/contracts?source=post_page-----1c6cb05edfca---------------contracts-----------------) # Youtube # Robin Linus on BitVM *Posted on 16 January 2024* [Robin Linus](https://twitter.com/robin_linus) joined Brink engineers to discuss his [BitVM](https://bitvm.org/) proposal and associated projects. In his presentation and Q\&A we discussed: * Stateful Bitcoin scripts * BitVM architecture * The Tree++ language * The [BitVM transaction graph](https://raw.githubusercontent.com/BitVM/BitVM/b196b4ea83c899264137342a5f75f0ec89456857/docs/bitVM_graph_v2.svg) * BitVM Bridges, peg-ins, and peg-outs * Limitations and future plans A PDF copy of Robin’s slides is available for [download](https://brink.dev/assets/files/2024-01-16-eng-bitvm-slides.pdf) and a recording of the presentation provided below. {% embed url="" %} **Robin Linus 00:00** Today, I'm going to talk about BitVM, which is a way to advance bitcoin contracts motivation. Yeah, first of all, we all know blockchain stone scale. Lightning also doesn't quite scale. Of course, it scales like Bitcoin by effect of 10 x or something, but unfortunately not far beyond that. And yeah, we're asking the question, can we scale bitcoin to billions of users at all? And in an ideal world, we would have like 100 x to 1,000 x higher throughput. **Robin Linus 00:34** We would have a free market of L2, like consisting of ZK rollup, side chains, 2nd layer protocols like ZKcoins and stuff like that. And that would enable both rapid innovation and also cheap experimentation. And all of these L2 tools could be interconnected via the Lightning net network. That is like somehow how I would roughly envision an ideal world of scaling bitcoin to billions of users. But unfortunately, we cannot do that because we don't have any bridges that would allow us to bridge BTC into any L2. **Robin Linus 01:12** Of course, we can use it on Lightning, but ZK rollup side chains, ZKcoins and stuff like that, they all cannot use BTC currently without, yeah, relying on some federation, on some multi stick merchant in the end. Okay, and BitVM is trying to solve that. BitVM is trying to enable bridges into other systems. And the overview is I'm going to talk about how to introduce state to bitcoin scripts, to have stateful bitcoin scripts. Next, I'm going to talk about the architecture of bitvm. And finally, I'm going to talk about how to enable bridges with the bid VM architecture, Bitcoin script, bitten scripts. Yeah, unfortunately, Satoshi disabled secretly all of the fun op codes, like he discovered a bug in OP\_CAT and then, or like in the op eh implementation of our cat and then he got kind of paranoid and disabled essentially all of the one of codes. And what we have been what he left us with is a very reduced version of Bitcoin script and it's reduced to the bare minimum. **Robin Linus 02:25** And it looks like as if we cannot do anything really. Interesting with it beyond the basic stuff that we know, which is like signatures, multi signatures, hash locks and time locks. But there are some op codes left and they're actually enough to do all kinds of interesting stuff as it turns out. Also, scripts can be up to form for megabyte in size. So even if it's verbose, like even if we have to compose things out of very limited of codes, in theory, we can express quite a few things within theoretically 4 megabyte large script. And since it is so interesting to play with that stuff, somehow in official community of Bitcoin script code golf has evolved and I'm part of that and part of that Bittranscript code golfing or as part of Bittranscript code golfing. **Robin Linus 03:30** The ideas behind bitvm arose in particular stateful bitcoin scripts because currently bitcoin script is completely stateless. So when you execute a bitcoin script, it's execution environment resets after every script. Like there is no native way to have, let's say, a value x that is the same in script 1 as it is in script 2. Bittranscript doesn't really support that natively. However, we can hack around that. And the general idea behind it is if we could just sign a value somehow. **Robin Linus 04:11** If we could create a signature for a value, then that would be already enough to introduce stateful Bitcoin scripts. Because yeah, we could enforce the same value for X in script 1 and in script 2. And we can simply do that by, yeah, checking the signature for script, for the value x in both scripts. And when the person who claims what the value is, or like the, yeah, the person who determines the value, if they're equivocate and sign to conflicting values for X, then we can punish them because we can easily prove that here's a signature that signs two different values for the same variable x. And that is the general idea behind it. **Robin Linus 05:03** However, how can we sign a value in Bittranscript? Because we don't have check signature from stack and there is not really a native way in Bitcoin script to sign a value. However, there are Lemper signatures. And Lemper signatures, they're very simple. And since they're very simple and they require only hash functions, they're possible in Bitcoin script. **Robin Linus 05:31** Lampert signatures are a quite simple concept. It's just for every bit of the message, you have two different hashes, hash 0 and hash 1. And if you want to sign a 0 bit, you'll reveal the pre image of hash 1, sorry, the pre image of hash 0. And if you want to us to sign one bit, then you review the pre image of hash 1. And just by revealing one of these two pre images, you can create a signature. **Robin Linus 06:03** The main drawback is, of course, it's quite large because for every bit in your message, you need to commit to two hashes and to unlock it, you need to reveal one of the pre images. So if you have like 32 bits, then you need 64 hashes and 32 pre images to unlock it. But it's still possible and we can easily, or we can just use it to sign stuff like the bytes, a 4 byte value or even eh, you hundred sixty. So a 20 by value we can also sign a 20 by value that is still feasible in Bitcoin script even though it's a bit clunky and it's large, it does enable signatures for values and that's why Lampert signatures also enable stateful Bitcoin scripts. And that in and itself is already quite big because stateful bittranscripts enable all kinds of interesting new features. Here's a little example of how that would look like in bitcoin script. Like the unlocking script would be just some pre image. And then in the first line it gets hashed and then we do duplicate it twice.
**Robin Linus 07:21** Or like we just duplicate it to have it two times and then we compare it to the first hash and then we compare to the second hash, and then we check if it was equal to one of them. And we pushed the bits on the stack to which one it was equal. So either it was equal to hash 1 or it was equal to h 0. And depending to what it was equal after that script was executed, we either have 0 or we have one on the stack. So that is a way to, or like the most simple way to sign a simple one bit value. **Robin Linus 08:00** And if we wanna have more bits, we can essentially just copy paste this script 160 times for a 160 bit value. For example. Oh, in general, please ask questions if I'm going to faster. So I'm so deep into the weeds. I've been working on that stuff for like three months straight and I'm very deep into the weeds and I'm not quite sure I if it makes sense what I'm saying. **Robin Linus 08:28** So if you have any question, just don't hesitate to ask BitVM, the paradigm, I kind of overloaded the term BitVM. It is multiple things. It's like the paradigm and it's also the actual implementation. And in the white paper that I published, I mostly describe the paradigm. And here for the introduction, I'm giving a high level overview of the Bitby and paradigm. First of all, yeah, the bitbm tries to keep things off chain. **Robin Linus 09:02** This is similar to Lightning that you just have some kind of contract that allows you to use the chain as a court when you have a dispute. But most of the time, you will not have a dispute. And the fact that you have, the court sets the incentives such that you probably will not have to use it, just like in real life, like most people get along with each other because, or like most businesses get along with each other because they know if they cheat each other, then there will be some legal consequences. And that's why everyone complies with the rules that we set up. **Robin Linus 09:42** And yeah, in a very similar fashion between m operates, it operates in a two party setting. There's always a prover and a verifier. Unfortunately, we can hardly get around that. But we can make it better such that we can expand it to a multi party setting, such as a single approver and verify us and all of them can challenge the approval at once. So like they can play the challenge response game in parallel against approval. **Robin Linus 10:13** And that has nice features because of only a single verifier is honest, then the security guarantees hold. But I will talk about that later more. For now, we will just say the BitVM paradigm in its pure setting lines, most simple setting, it's always using the proven verifier roles and there's two parties. Yeah, in general, we're using optimistic computation. That means we're not trying to execute all of the computation on chain. **Robin Linus 10:45** We're doing quite the opposite. We're trying to minimize the amount of computation that we have to execute on chain. **Robin Linus 10:51** And we're doing that by trying or like by disproving a faulty result instead of computing right result that is much easier. Like the verifier, just ask the prover for the end state, for the final say, for the result of the computation. And if that result is incorrect, then the verifier tries to find the most succinct way to disprove that incorrect result. And in general, that is much easier than the verifier computing the right result. I'm saying that is also kind of intuitive because for example, if I tell you, let's say, 100300 e equals 7, then you can easily say that 7 cannot be right because it's it is way too small. **Robin Linus 11:49** So without even computing the actual result, you can immediately tell the result that I just said 7 must be wrong because it's way too small. And that is like in general or like that there, there are many such often in computation, it's much easier to disprove an incorrect result than it is to compute the correct result. Another example is, for example, square roots, like the, to compute the square root of a number, you have to execute it quite complete complicated algorithm relatively in comparison to multiplication, for example. And the but proving or like verifying a result, like if you give me a square root, I just have to multiply it with itself to see if it's the correct result, which is much easier. That's another example of why, or like, it's another example for the fact that verification is often much cheaper than execution. **Robin Linus 12:51** And yeah, we have developed a tiny domain specific language that we call Tree++. That is kinda, it's a language built upon Bitcoin script and that enhances the capabilities of Bittranscript. And now I'm going to them give a short overview about what Tree++ is. Most of all, it's a templating link language for script. Since script is so limited, we often have to do like, we often have to copy paste a lot of things. **Robin Linus 13:28** And yeah, we, in general, it is very handy to be able to evaluate constant expressions such that, for example, I can write something like 2 to the power 5 or some binary number or something. That is the most basic thing that you can do. But you can also unroll loops. For example, if you have to do something 32 times or so, you can just write a simple loop that unrolls this template with particular parameters. You can compose functions and composing function allows you to compose functions and yeah, compose them into bigger function and bigger functions. In this way, you can manage a lot of complexity in relatively simple compositions. And using this templating language, we implemented some basic op calls that we call composite of codes. **Robin Linus 14:33** And it's, yeah, for example, bit wise XR or bit wise shifts multiplication. And it goes even to us implementing Blake 3. Some people wondered, why do we implement like 3 that there are already hash functions in Bitconscript, but why do we re implement something like 3? The reason is that we don't have OP\_CAT. Like we cannot concatenate bytes in bittranscript. **Robin Linus 14:58** And that means we cannot verify Merkel proof. Because for Michael inclusion proofs, you have to hash the path and to hash the path you always have to concatenate two nodes with each other to then hash them to get the next node. And unfortunately, that's not possible in Bittranscript currently since we do not have a cat or something similar. And that's why we had to implement our own hashing function. And then we can do it on like on the byte level. **Robin Linus 15:30** Yeah, we're representing large bytestrings, just like a single bytes on the stack. So 20 bytes would be 20 stack items, not a single stack item of 20 bytes, but like 20 single sec items. **Robin Linus 15:45** And this way, yeah, we can concatenate them and then we can, yeah, do everything with them, what we can think of or what we're used to from like regular computers. And yeah, that's allowed us to implement highly complex stuff such as Blake 3 in the end. And this language Tree++, we're use, we're using it to implement BitVM. **Robin Linus 16:15** Oh yeah, Tree++ also that's where the name comes from. It usually contains many tab trees. So it's more than just writing a single script. It's also a language to write like graphs of transactions, which have scripts that are connected with each other. And yes, they're potentially large. For example, the Blake 3 is script is quite large. It contains of I think about 100,000 of codes or so. **Robin Linus 16:43** But yeah, they don't have to be large to that, but they're potentially large. Yeah, and we're using Tree++ to implement bitvm. And here I'm talking about not bitvm the paradigm, I'm talking about bitvm, the actual virtual machine for Bitcoin, which is kind of similar to the E e theorem virtual machine, but it is way more limited and it's like an Ethereum. They, I have designed the entire chain to support this. Yeah, this sophisticated virtual machine. **Robin Linus 17:19** In Bitcoin, we totally don't have that. It's the exact opposite, actually. Bitcoin is stumped down such that it doesn't support all these things. So what bitvm actually is a huge pile of tricks or a pile of hacks that hacks something like EVM into Bitcoin without changing its consensus rules. **Robin Linus 17:40** Yeah, the main idea behind it is that Tree++ is nice, but we don't want everyone to have to handcraft and hand optimize low level bitcoin scripts for every application that they do. Because yeah, handcrafting these scripts is super, it's complex and it's arrow prone and it's expensive. It's an expensive process. It takes a lot of time. So a much nicer e idea would be to build a generic B virtual machine, which has like a nice instruction set. **Robin Linus 18:13** And then people can just use some high level language that compiles down to that instruction set and collected compiles down to instructions of that set. And then they can use nice high angle languages such as rust or something to write their applications. And we just have a single tab 3 circuit that, yeah, all the low levels of deaths can focus on. And we build this s circuit only once and then everybody can use it for any kind of application. And yeah, this VM, this circuits in particular, they're designed to succinctly disprove any faulty result of that virtual machine. **Robin Linus 18:59** That is also a cool thing because in general, it's not easy to, like for general computation, it's not easy to structure. It's such that it's easy to disprove any faulty result. **Robin Linus 19:12** You usually have to craft the circuits such that it has very narrow positions. And in these narrow positions, you can do queries and then you can do like a binary search over these narrow positions. But if the circuit doesn't have these narrow positions, then it's very hard. **Robin Linus 19:28** And yeah, by building a generic VM, we have that problem only once. And then we solve it once for every application. And yeah, ideally we would have something like a risk 5 architecture, such, yeah, that we can use existing tooling to compile down to our architecture. And that's exactly what we're doing here. Like rough specs of what we're implementing. Currently we're implementing the basic instruction set of risk 5, the 32 bit instruction set of course. And that can then act as a comply target for us. GCC, LVM, and like all the things, all the compilers that you know enough and you can use all of your existing C++ and rust and whatever libraries. **Robin Linus 20:22** And in particular, you can use existing stock and Slack verifier libraries. And yeah, then just compile them to the VM and run them in a bit here, a bit more detailed specs. **Robin Linus 20:36** The BM as we build it currently can run for 2 to the power of 32, so roughly 4 billion steps. It has 4 billion memory cells or 4 bytes each, which results in about 17 gigabytes of memory in the worst case, you would have about 40 rounds of challenge in response. The, in the worst case, the court case would run for about half a year. Every party would have to submit one, 1 transaction per week, approximately. And yeah, then in good one for about half a year in the absolute worst case. In total, you would have to write about 150 kilobytes of script over that half of year. And what's important to notice is that this worst case is heavily disincentivized. **Robin Linus 21:44** And also, once you start the trial, it is already certain who will win and who will lose. So there is no incentive really for an attacker to start this trial because they know in advance that they will lose, they will pay the fees. I think there was a question. Yes, Fabian. **Speaker 2 22:03** Yeah, I was like, I already thought of that because before you said that. So like, how was like complex scripts, how do you actually verify that the worst case holds like that you, there cannot be a state or like the, yeah, the program can run to state where you would need 41 rounds of change and. **Robin Linus 22:28** Response. Oh, that is quite easy because you just limit the trace size to like 4 billion. And if the program would run for more than 4 billion steps, then it's already wrong that that would be the result would be wrong. You can just say the program has lost. If the program doesn't terminate within any 4 million steps. Okay, yeah, make sense? **Robin Linus 23:02** And we think like for all practical purposes, the 4 billion steps will probably be way more than you need. Also, you can reset the VM off chain in a fashion similar to how lightning channels work. So you can just, when you agree on a particular computation, you can just reset the VM and just change the program and then you can use it for something else. The only limitation here is that it has to fit in these 4 billion steps. **Robin Linus 23:37** Yeah, the worst case likely never happens in any reward applications. The system would have to break that it would make sense for anyone to ever execute the worst case. And also, like, as an honest participant, you're always happy if somebody makes, opens a trial against you, even if you're un innocent because yeah, you will profit from it. You they will pay your fees and they will pay like a little bounty on top of it. So if you're honest, you're happy if somebody challenges you for no reason. **Robin Linus 24:13** Here is a rough overview of how that transaction graph looks like. Unfortunately, I cannot really zoom in here. I try to figure out how that works, but it doesn't really. You can have a high resolution version of the graph here at github.comslashbvmslashbvmslashdocs if you're interested. Just to give you a very rough overview here, the first part, or like there are three main parts of it here. The first part is the trace, the second part is the instruction, and the third part is essentially the memory. And what you do here in the first part is you do a binary search over the trace of the VM. The trace means that's the, at every step of the VM, you can mercalize the memory and then you get a root of them. You get a marker root of the memory. Somebody asked a question. Yeah, cool.
**Robin Linus 25:37** I think Gloria just posted the version 1 of the graph. There is also a version 2. Then what I'm showing here is, yeah, I confuse you, Gloria. Sorry. Yeah, what I'm showing here is version 2 and version 1 is almost the same, but slightly different. **Robin Linus 25:58** Yeah, like the first part is binary search over the trace. The trace is essentially just a list of mercury routes and every marker root represents the memory after executing a particular step. So for potentially for every step, you have a merger route of train on chain, you need at most lock trace them many merchant routes. So if your trace has two, 4 billion steps, then you need at most 30 too many trace rules that you have to commit to in the chain. **Robin Linus 26:38** And yeah, the process is actually quite simple. The Hoover, they commit to a particular 2 particular state node. And then the verifier just responds with a single bit saying if they think the root was correct or incorrect. And then if it's, if it was correct, then the binary search continues in the lower half of the trace. If it was incorrect, the binary search continues in the upper half of the trace. And the interesting thing here is that they really just exchanged the signal just for values like the approver signs 160 bits, the verifier signs one bit, then the approver signs again 1 hundred sixty bits, then the verifier 1 bit and so on, always 161 bit and so on until step 32. And after step 32, the approval has revealed 32 roots and the verifier has revealed 32 bits. And these 32 bits, if you put them together in a 32 bit number, then interestingly they represent exactly the index of the last correct route. That is just by how the verifier chooses the bits. They just choose the bits to be 0 or 1, depending if they think it's correct or incorrect. And that implies just very implicitly, it's nowhere explicit in the scripts, it's completely implicit that the, when you put these bits all together and interpret them as a 32 bit number, then you get the index of the last correct state node. And that means that index plus 1 must be the first incorrect state node. **Robin Linus 28:32** And this is how you implicitly find out which or like how the verifier defines what they think was the last correct state note. And once they have defined what the last correct state notice, they have automatically define a faulty state transition because they know a route for which they know correct route that is followed by an incorrect route. And that means they just have to prove that the instruction following from the correct state into the incorrect state, that this one single instruction was executed incorrectly. **Robin Linus 29:10** And that is a very important concept here that we just have to execute a single instruction. We can run the VM for a billion. We can execute a billion instructions. But on Shane, to disprove a faulty result, we just have to disprove a single step. And yeah, the entire first part is just to find the faulty step. And then the second part is that the verifier, they have found it and then they ask the prover to reveal that instruction. That's that they just showed. And then after they have reviewed that instruction, the verifier can disprove it because something has to be wrong about it. And there cannot be many things wrong about it. The first branches here on the left, that would be that in general, in every instruction has like the form operant a, operation operant B result. So something like a plus b equals C, for example, that could be an operation if you would use the ad op code. Then a simple, the most simple thing you can think of, the most simple op code you can think of is addition and then you have just a plus B equal C. So and what can happen here is that first of all, they could have read the value a incorrectly. And this is proven by this path here. **Robin Linus 30:37** If you got this route here, the most left route, you disprove the value a. It means the prover has committed to an incorrect value a. It is not at the position where they claimed. Like they are saying at address a, there is value a, but the verifier knows exactly how the Merkl tree looks at the correct state. So they can say, no, that's incorrect. There is not value at the address. And this is how they prove it with this path. **Robin Linus 31:08** The second path is to disprove the second upper run that would be value B. And the third one is to disprove the result that would be, yeah, the value c was written incorrectly into the memory. And the other branches, they're just like the 4th branch with like the little. Do you even see my mouse? I think you don't see my mouse, right? Can we see it? As you can see? Yep. Okay. **Robin Linus 31:38** Yeah, here, the first branch that's allows you to disprove the program itself. So that would be the proof I executed an incorrect instruction at the current program counter. There is not that instruction that there were the approval just claimed. So essentially here is the entire program encoded. And to change the program, we would just have to change this route here. Everything else can stay the same. Here is the only part where the actual program is committed to. **Robin Linus 32:16** Yeah, and here, these other two branches, they're just to disprove the program counter. I know this is super complex and I'm pretty sure my explanation didn't help that much. It's how to wrap your head around this stuff. Fabian. **Speaker 2 32:38** Maybe can you take one step back for a moment and like just make it more clear how this exactly then gets like, or how this is then the how the protocol works on the higher level. So I guess this is then the transaction like there are funds locked in a 2 of two. **Robin Linus 33:01** Oh yeah, I haven't even talked about how to deal with the firms yet. Yeah, this is more just like how to. Yeah, how to how to walk through faulty state transition. **Speaker 2 33:16** If you still getting to it, then it's fine. I just most interested. **Robin Linus 33:20** Right now. Yeah, a simple way to do it would be just that the funds are locked in the same output as the entire graph is in. So then just like the party who wins will be able to take the output and that would be like the most simple way to control funds with them. **Robin Linus 33:47** Well, that's graph, but there are more sophisticated ways to do it for the bridge later on. I feel like it would be just, maybe it's just too much to explain all the details of the BitVM graph here. I will go through the rest of the presentation and then if we have time, we can go back to this one. **Robin Linus 34:14** Yeah, the this is in general the bridge there. Sorry, this is the graph. And now the question is, how do we apply that graph to build bridges into other system. And the main idea here is if the bridge is a bit clunky, it would be fine. We can build the bridge such that is used very rarely and only for large amounts. For example, like a trip of just a random number would be, you can use the bridge only from minimum 10 BTC. And it would also take you, I don't know, three months to pick out or something. And that would still be fine because most end users can just use cross chain swaps. **Robin Linus 34:59** As soon as we have some kind of guarantee that the xbtc or whatever we call the asset on the side chain, on the site system, whatever we call that asset, as long as xbtc has, is guaranteed to be anchored into Bitcoin value. And as long as you have a guarantee that you will always get BTC if you want for your xbtc, then these xbtc have value. And once this XPTC have value, then you can easily picture that some market will arise of, yeah, liquidity providers enabling cross chain swaps between different chains. We already have that between liquid, for example, liquid and lightning. I think just aqua wasn't wallet that was just launched that is based on that idea that is kind of easy to have a lightning channel on on a side chain, on the liquid side chain and then interact with the regular lightning network just via atomic swaps that you as an end user just don't notice. And that is the rough idea. So if we just have some kind of secure bridge, even if it's slow and clunky, it would totally enable bridging BTC to other systems and then would enable it in the end efficiently because we can just use atomic swaps, the guarantees of the bridge. **Robin Linus 36:30** First of all, it's just a federation. But what's way better than what we have so far is that a single honest member suffice. Like if we, if the federation contains at least a single honest number, then the bridge is secure. And secure means the bridge is safe. And live save means nobody can steal the deposit. And live means you cannot stop a valid pack out. And. **Robin Linus 37:04** Yeah, we can have large federations, which is very good because yeah, it's, it's the more federation members we have, the more likely it is that there is also a single that there's at least one honest member. And another cool thing is that if you're an exchange or something or whatever stakeholder that has a high stake in the site system, then you can become a member of the federation. And once you're a member, then it's trusted for yourself because you can be that one honest member. And this way, you don't have to trust anyone, even if all the other members are malicious, you can guarantee safety and liveness. **Robin Linus 37:46** Here is a great diagram from our design department that just gives like a very rough overview of how we envision the bridge. And the in principle, it's quite simple. It uses an ingenious idea of Burak. He is the creator of arc and he invented the idea of connector outputs. And connector outputs is something very simple. It's just the idea that you can connect two outputs by resigning the transaction for one of the outputs, spending both of outputs. And this way you can atomically connect them to each other.
**Robin Linus 38:31** In concrete terms, this is a very simple, simplified version of the packing and peg out. But I try to explain now like Alice would peg in 100 BTC here, and she would create an output of 100 BTC that is an NFN multi sick. And those are this is like the federation, all federation members have to presign and they would presign, eh, here, this blue transaction. **Robin Linus 38:59** And the interesting part here is like they give the 100 BTC just to the operator, which is also an interesting optimization that we came up with. You can just give it to the opt 0,0 operator. I will explain later how you can pack out to any user, even though that money always goes to the operator. **Robin Linus 39:21** But the most important part here is the blue output. Yeah, the blue output precise the entire transaction. And it uses C cache all and also signs these two inputs, like there are two inputs coming from the kickoff transaction of the operator, which will happen later. It didn't happen yet, like at the point of packing, it didn't happen yet, but they will know how the co kickoff transaction will look like. So they can already compute the outputs that it creates and then they can use it to presign this blue transaction here. And this kickoff transaction is built such that the operator puts in an input and then there are two outputs. One is time locked. It takes six months until you can spend it. And the other one is the so called connect output. And you can spend it at any time. **Robin Linus 40:12** But the interesting part here is that once the operator publish the kickoff transaction, it will take them 6 months until they can execute the blue transaction. And they will not be able to execute the blue transaction before 6 months. And they can only execute the blue transaction if they still have their connector output. If something happens to their connector output, then they won't be able to execute the blue transaction because the signature here commits to all of the outputs of the kickoff transaction. So if the connector output gets somehow spent by someone in some way, then the operator will not be able to touch the funds here. **Robin Linus 40:52** So what we are doing here now is we have the connector output, which is a very powerful primitive because we can use it in conjunction with the BitVM. Like these red boxes, they're BitVM setups, 1 BitVM setup for each verifier. So the the prover, the operator of the bridge has for every other member one between m setup a separate BitVM setup and then work such that if one of the verifiers wins their challenge against the operator, then they win an output that allows them to spend the connector output of the operator. So if the verifier wins, if any web verifier wins their challenge against the operator, they win an output that allows them to spend the connector output of the operator, which guarantees that the operator cannot touch difference. **Robin Linus 41:48** And the good thing here is that all of these challenges can happen in parallel. So every verifier can attack the operator in parallel. And if only one of them succeeds, they can take the connector output, destroy the connector output, and this way they ensure that the operator cannot touch the funds. And this is like the rough idea how such a peg out can work. There are a couple more levels of complexity to it, but in general, this is the rough overview of of how the how of how it works. I can go into it to more detail, but I will finish the slides first. Limitations. What are the main limitations of private? Yep.这 **Speaker 3 42:41** Gloria has a question or. **Robin Linus 42:43** Come. Oh, yeah, I haven't seen that. Sorry. **Speaker 4 42:46** Hey, Stephen, here. Is it kind of like for Lightning also, the connector output would have a sizable output dashboard so that verifiers are incentivized to look for kind of cheating more. **Robin Linus 43:00** Yeah, the you have to align the incentive such that the verifier makes a profit if they're disprove the operator. So the operator will over will have a deposit. Yeah, the minimum. **Speaker 4 43:13** Value that has to be in the connector output to make it worthwhile.Connector output \ **Speaker 5 43:18** So would you publish the kickoff transaction first and have that bounty in there? And then you try to do the peg in. **Robin Linus 43:29** You would just publish your I that operator output. You would not publish the entire transaction, or at least you would not publish the sign transaction. Because yeah, this putting this kickoff transaction on chain is also like the signal from the operator, which means I just witnessed a valid pack out in the side chain. And that's why I'm going to proceed now with the pack out. Oh, does that make sense. **Speaker 5 44:05** Okay. So it's like an unvault.\ Robin Linus 44:09 Okay. It's also like the operator makes the claim that a valid headcount was initiated on the site system. **Speaker 5 44:19** Okay.. **Robin Linus 44:21** And that's important that they make a claim because once they had make a claim that is that they commit to, then you can use that claim and disprove it in a BitVM if it's incorrect from. **Speaker 5 44:34** Hum in. **Speaker 4 44:35** Conceptually, who's operator again? Like what do they do? **Robin Linus 44:39** The operator is just one member of the federation that is in charge of, yeah, operating the bridge in essentially of paying the people who wanna pack out. "Operator" **Speaker 4 44:51** So each federation is a single operator and then that operator is kind of checked by all the federation members. Yes. **Robin Linus 44:57** Okay, thanks. And they can like kill them and then the next party becomes the operator. Like if you win against the operator, if they cheated, then some. And there's no honest verifier, then the honest verifier will win and then they can kill the operator's connector output and essentially remove them from the federation. And then just the next party becomes the operator and you start from scratch with the same setup. **Robin Linus 45:28** Hum, thanks. I know it's highly complex and there are many levels of many pilots of hacks piled on top of each other. So don't hesitate to ask any questions. I know it's complex and I would certainly not understand it from my explanation. But yeah, limitations of BitVM, first of all, yeah, there's lots of complexity. The scripts that we're building are complex. It's a complex process. It's, it has complex assumptions about fees and all that stuff. So I, it is not a simple solution. It's a com like solution. Definitely. Also, it's complex to, yeah, balance the incentives. **Robin Linus 46:27** Of course, if the incentives are balanced, the chain is not needed. However, that's potentially capital intensive because you kind of have to predict the highest possible fees, and you have to put up capital to be able to pay for the worst case. So that's interesting thing. Like if you're able to pay for the worst case, then the worst case probably won't happen. But if you're not able to pay for the worst case, then there's an incentive to export that. So yeah, you, it's pretty much it boils down to capital costs, like the cost of putting up the capital and waiting or like being there if you would need it, that guarantees mostly that you don't need it at all. **Robin Linus 47:16** Whoops. Yeah, a very good thing here in comparison to other bridges that like other people have been doing research on Bitcoin bridges and they usually come up with solutions that require some kind of 1 to 1 collateral or even over collateralization. Here in our model, we don't need that at all because we have that nice connector output thing, which essentially guarantees that if the attacker cannot touch the funds, so there is no need to over collateralize anything. Also because yeah, all you need is them paying the winner's fees, but they cannot touch the deposits. So there is no way, there is no need to collateralize it. **Robin Linus 48:18** Yeah, and there are some scalability issues like you cannot scare to a thousands, federation of a thousand people because for every pack, our pack in all of the end parties have to pre sign and pack out transactions in the end. So there's a lot of presigning going on. It's way less than I originally anticipated. Originally, I thought every party has to presign the entire BitVM setup of all other parties. But this is not the case. It can be still 2 party setting. It totally works out. But that pagout transaction, like the blue transaction, if you remember, that has to be signed by all end parties. And you have to sign it n times because, yeah, you need the entire setup end times because when you kill malicious or like m minus 1 malicious operators, you still need the single honest verifier to be able to keep the bridge running. And that's why you need the setup end times. **Robin Linus 49:119** And in general, federation can sense of peg-ins. That's an issue. Like since all of them have to cosine, if one refuses to cosine, then you cannot do more pagins. That is definitely an issue, but it's not as big of an issue as if they could send the payouts pack sender impact and nobody loses money, right? But in a pack, sending a pack out, that would be equal to stealing one. **Robin Linus 49:47** Summary and outlook. BitVM definitely enables much more complex bitcoin contacts. The main use case that I see is a trust minimize bridge. In general, trust minimize bridges to all kinds of systems. Maybe there are also other use cases, but since it is slow and expensive, it doesn't really fit many use cases. But it fits the bridge use case quite well. Yeah, it is practical, but it is clunky. **Robin Linus 50:16** As I said, it's very cool that it doesn't require any soft fork. So we can do more innovation without any activation drama. And hopefully our toy version will be ready this month. **Robin Linus 50:30** We have already implemented since, I don't know, 2,3 months already, and we got it to quite sophisticated level. Just yesterday, we walked or like we executed all transactions for the first time down to the Merkel pass. So like the entire graph from like the top to the bottom yesterday for the first time. And yeah, hopefully we will even have a reckless main net this year. Well, people can already use some small real amounts and use it in the wild. No, that's it. Do you have any questions. **Speaker 3 51:17** Robin? That's great. Thanks for jumping on. I know folks will have some questions. I see Fabian's got his hand up group. Maybe quick question for myself first. The BitVM enables this federation in this peg and peg out W. Is there a name for this bridge you just called BitVM bridge or does it have its own, they distinguish from ByteDance itself. **Robin Linus 51:42** And I'm working on a paper together with Alex, say, and he calls it Sentient Bridge or something. But I have really come up with any name that really resonates strongly with me. So I'm open for suggestions. **Speaker 3 51:59** TBD. Alright, have any other question? **Speaker 2 52:04** Yeah, you had like some examples of stuff that is implemented and you mention Blake, which I've seen, but I've also seen somebody post something about a function chart 1 or 56 implemented in the PM. Is it something different? r I'm just curious because you didn't mention it in your presentation. **Robin Linus 52:23** I thinn that's different. I think that was more like pllaing around with ideas. We were really serious about like 3, like we have completely implemented it to the like it just works. And I think the short one and 56 version was more like theoreticall. It'slike, yeeh, we do have the buiiding blockk, but they haven't built it. Okay, ggttit. But maybe I'm wrong here. I'm hope, I hope I don't friend. **Speaker 5 53:02** I have a kind of a question reeated to that. LLikehow much of, I guess ii's kind of unclear to me wwat goos on chain, like you were talking about using 100,0000 o codds to implement like 3 is not something that you have in youu like is thha part f a the sccipt of a transaction you publish on chain? Yeah, but practically does that work if it like that's a non standard size, right? Is it 100 k? Oh, I guess it's witness discount. But yeah, like what goes. **Robin Linus 53:44** Can be by. So it should be stupid. **Speaker 5 53:48** Right? Right. **Robin Linus 53:51** Okay, never mind. Andd mybe here to show it, it's really liik the very laatt ransaction only hre, eitherrin this or in that transaation, you would execute one round of pplte 3. So only n the very worst case that the alicioussparry knows they hve lost, buutthey still keep doing it for half ayear and keep posting like the worst answer that they can to really get here and like to really end up there. And then at the end, they would haae to execute one round of Plate 3. **Speeker 5 54:33** And so this 40 rounds over six months is that worst case, as in the attacker waits untii the last mmnute. Yeah, to ooanotthr. Okky. **Robin Linus 54:42** Exactly. Yeah, that's like the attacker trying to maximize the length of the trial, the uration of the trial. **Speaker 5 54:54** And is it so you do you have to put all of the, I guess, value upfront? Okay. So you would like run out of fees and that's not be worth it anymore. You. **Robin Linus 55:13** Fee. Yeah, no, the fees are not that much of ann ssue. You caa always have anchor outputs and then just use these. But. **Speaker 5 55:20** Like if i's an expenssve fee mmrkee, yyah, anndit's expensive to publish a transactiion o make a proof, yeah, tthnnyou might not bother. **Speaker 5 55:58** Okay, intereettng. I have a, I guess so I don't wanna kind of, I'm likkea little worried that this will sound rude, I guess. So you mentioned kind of this very rich universe of possibilities of like, you know, the infinite amount of things that you can do here. Is that kind of the goal or something you're just trying to demonstrate and you're actually looking to deploy something a bit smaller or. **Robin Linus 56:36** Like we're really building these bridges and then everybody can use them to bridge BTC into their system Like some people want use it for Ethereum, others when I use it for bitcoin side chains, like Soren found it interesting or like rootstock people found it interesting. In general, everybody who's building side chains can use it. Everybody who's building ZK rollops, there's another company that is using this building. They can roll up some bitcoin. They're very interested in using the bridge. And in general, we wanna offer that's primitive for other people to bridge BTC into their system. **Speaker 5 57:12** Okay, so they could have side chains where they have whatever they want. Yeah, and it's, I see interruptable. Okay. **Robin Linus 57:20** And then you could have like all the like you can have all kind of clones. You can clone Ethereum, you can clone Z cash, you can clone Monero, whatever you want. And then just remove the shitcoin and replace it with BTC and then have essentially every feature, every blockchain architecture that you want. **Speaker 5 57:42** I see. Okay. **Robin Linus 57:43** Like the brand vision. Cool. **Speaker 5 57:46** Very cool. Thank you. Did you wanna go? **Speaker 4 57:49** So Stephanie, two questions. I think they're related. One is like a few months ago, up came out the only function available was, I think, checking if value is 0 or something. And then it would say that you take a long time to build all the functionality. But it seems now that you've already built a lot of that quite quickly, like what's what happened that things involve so quickly. And it also was a link between G++ and the VM implementation. Cuz I didn't quite get that, but I'm thinking it might be. Great question.Stephanie， **Robin Linus 58:19** Since. Okay. Yeah, like super test night is not here, like in the Zerosync team would BitVM or like this, what I'm presenting here is built by the ZeroSync team. And so, but Tessen was toying around with BitVM in general, and he built the first prototypes. But they will, his goal was just to build something as soon as possible and give people something to play around with. And what we're doing here is, yeah, I'm more complex approach that is aiming for more real world use cases. And it's essentially two different projects. So it's maybe we should just not overload the name that VM too much. Maybe we need to find a official name for this project to distinguish it from other things that are also called PDM. Okay, and the second thing, the difference between Tree++ and the BitVM is that Tree++ is like that domain specific language built on top of Bitcoin script, like it allows these things that I mentioned, like I'm rolling stuff or here it is essentially just a templating language for script. That's the main reason, main thing here. And we're using Tree++ to implement BitVM **Speaker 4 59:54** Okay. So it wouldn't be like if you're writing a one of these contracts, you would be using the bitfield implementation with the language you wanna use and you wanna. **Robin Linus 01:00:05** You would use rust or something, you would use C++ rust or whatever high language you're used to and then compile that down to the BitVM instruction set. And then, okay. So s normal contract developers will not deal with Tree++ at all. And they will not deal low level stuff. It's a very way more like solidity in the end for the developer experience. All of that stuff here, Tree++ is not solidity. Like we will have another language that will probably be just some rust dialect that will be, yeah, the main language to them express programs to run them in video. This is just, yeah, and then a templating language on top of big Country. Thank you.. # What is BitVM? with Robin Linus and Super Testnet (SLP520) {% embed url="" %} **Links:** * Paper: [bitvm.pdf](https://bitvm.org/bitvm.pdf) * X: [@robin\_linus](https://twitter.com/robin_linus) * X: [@super\_testnet](https://twitter.com/super_testnet) * Super Testnet’s Tapleaf circuits: [supertestnet/](https://github.com/supertestnet/tapleaf-circuits/)[**tapleaf-circuits**](https://github.com/supertestnet/tapleaf-circuits/) * Shinobi article on BM: [bitcoinmagazine](https://bitcoinmagazine.com/technical/the-big-deal-with-bitvm-arbitrary-computation-now-possible-on-bitcoin-without-a-fork) * AJ Towns ML response on BitVM: [BitVM: Compute Anything on Bitcoin](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/021985.html) **Sponsors:** * [Swan.com](http://swan.com/livera) (code LIVERA) * [CoinKite.com](http://coinkite.com/) (code LIVERA) * [Mempool.space](https://mempool.space/) **Stephan Livera links:** * Follow me on X[ @stephanlivera](https://twitter.com/stephanlivera) * [Subscribe to the podcast](https://plinkhq.com/i/1415720320) **Podcast Transcripts:** Stephan (00:01.528)\ Robin and Supertestnet. Welcome back to the show. Super Testnet (00:05.122)\ Thank you so much for having me. Robin Linus (00:06.317)\ Thank you for having me. Stephan (00:10.064)\ Great, so look, let’s just start. We’re gonna talk about BitVM and obviously have this explained for the Bitcoiners out there. So Robin, do you wanna just start with a little bit of your motivation? Like why did you, why were you working on this idea? Robin Linus (00:26.149)\ At the end, we want to scale Bitcoin. A good way to do that would be having some kind of trusted two-way pack, like some kind of bridge to bridge Bitcoin to other chains. Since my background is mostly in zero-knowledge proofs and validity proofs, I always wanted to have some kind of validity proof verifier on Bitcoin. And yeah, since it’s very hard to change Bitcoin and it’s very hard to find consensus on new proposals, some crazy people like Supertestnet and Sam Parker and I, we created that Telegram group to like try to hack some kind of CKP verifier into Bitcoin. And that was the motivation behind BitVM. Stephan (01:11.888)\ Great. And so do you mind giving us sort of an explanation in layman’s terms of what BitVM is? Robin Linus (01:24.237)\ It tries to mimic basically the same functionality that the Ethereum virtual machine gives you. So it enables basically smart contracts on Bitcoin, complex smart contracts. Stephan (01:39.48)\ Okay, and so I think Supertestnet, let’s hear a little bit from yourself as well. You were commenting that this is a really exciting discovery in the history of Bitcoin script. So can you elaborate a bit on your thoughts there? Super Testnet (01:53.27)\ Yeah, one of my favorite things to do is try and find novel and interesting things to do with Bitcoin script. Sometimes things that people haven’t thought of before. So a couple of things I’ve made in the past. A couple years ago, I made something called rule 110 in Bitcoin script. It’s one of my GitHub projects where I made this automaton or this… What do they call them? A single cell like animation that I ran in Bitcoin script where it would like draw a triangle on the screen. It was really fun. And I used a lot of Boolean logic for that, which is like this primitive in computer science. And then the next year I made something called for loops in Bitcoin script, which this is last year. I made something called for loops in Bitcoin script, which are another primitive that allows you to have a… You unroll the loop where you say, I’m gonna run the same code like seven times, and on the seventh try, then it’ll finally close the loop and exit and do something else with the code. And that also involved a lot of really core primitives. And then this year, I tried to implement SHA-256 in Bitcoin script. I actually wanted to reimplement the entire SHA-256 algorithm, doing it entirely in Bitcoin script. Robin helped me a lot with that. And that was kind of what… got us talking for the first time, then we joined this group together where we were trying to do more stuff with Bitcoin script because we were actually pretty successful with that. And the BitVM sort of emerged out of that where we realized if we can do SHA-256, if we can do loops, if we can do Boolean logic, we can combine all these things and turn them into a virtual machine that has pretty powerful characteristics. Stephan (03:40.14)\ Okay, and so I think most people might not be really familiar with what Bitcoin script is. And so do you mind just, you know, can one of you just give a very basic level explanation for that for the non-programmer Bitcoin users out there? Robin Linus (03:59.329)\ Shall I? Or like, super? Stephan (04:00.92)\ Yeah, Robin, do you want to just give an explanation there? Robin Linus (04:03.701)\ Okay, Bitcoin script is like a simple smart contracting language that allows you to express mostly things like signatures, multi-signatures, timelogs, hashlogs, like the most basic primitives of smart contracts. And with these things, you can already express stuff like lightning network or like multi-signatures, you can have like basic vaults. And yeah, you can have like the… most simple smart contracting functionality that people are aware of nowadays. And it is intentionally limited, like it’s intentionally not Turing complete. It’s a stack-based language and like it’s similar to FORTH and the yeah it’s intentionally limited to not create unnecessary attack surface. And it was even more expressive in the beginning, but then Satoshi realized at some point that there was like a bug in one implementation, in one opcode. And then he just got paranoid and deactivated lots of opcodes at once and kind of crippled Bitcoin script a lot to dumb it down, to not create any unnecessary attack surface. Stephan (05:24.245)\ I see. And Supertestnet, anything to add there in terms of Bitcoin script? Super Testnet (05:29.986)\ Just that one of the things Satoshi left in, or a couple of the things Satoshi left in, was Boolean logic, which is this primitive that’s used in the creation of computer circuits. In fact, like every microchip is a series of these things called Boolean logic gates. And by leaving those functions inside of Bitcoin, he made it so that you can recreate a lot of the functions that he removed. And so that’s kind of what we’re, we’re like exploiting the fact to make BitVM. Stephan (06:04.932)\ I see. So maybe one way to think about this is Bitcoin has a programming language. It’s been specifically cut down. And part of that was for historical reasons where maybe it was seen that could create risks of shutting down the network. And what’s going on here is a kind of creation of like a, almost like a Stephan (06:35.74)\ computes its scripting. Is that a fair way to put it? Robin Linus (06:40.753)\ Yes, maybe an important detail is that this BitVM never really executes much computation on Bitcoin. It only ever disproves incorrect executions. So that is very different than regular computation. Stephan (06:55.544)\ I see, yeah, so that’s, right, it’s an important distinction to make rather than the idea of like every computer having to do all the computation, it’s more like a, as you point out in your paper, it’s more like a solver and a, what’s the other term? A disprover, yeah. Sorry, a prover and a verifier, right. And so I think that’s maybe more aligned with, let’s say, how people are thinking about it in a Bitcoin context, it’s more like this idea that Super Testnet (07:12.662)\ Let’s take it. Robin Linus (07:13.035)\ and a verifier. Stephan (07:21.24)\ everybody’s running their own Bitcoin node because obviously there’s no centralized server here. Everyone’s running their own Bitcoin node and you are just sort of engaging in a similar way like with lightning there’s kind of like a you know, you’re just engaging in this two-party channel state back and forth and maybe it’s some similar dynamic with that so bitVM sort of has similarities with DLC lightning and Things like this, but it’s being done in a way where you are. Let’s say disproving now, I guess Robin Linus (07:37.42)\ Yes. Stephan (07:50.608)\ Probably the big thing that a lot of people will be listening and thinking, well, hang on, what’s the point of all this? I just want to have my sound money. Like, is this going to help me or is this going to help Bitcoin become sound money or become more saleable in some way? Do you have any thoughts to share on that? Robin Linus (08:05.913)\ Yeah, like my personal vision is that we really have hyper Bitcoinization. That means like I can pay everywhere with Bitcoin. And to do that, we would need to be able to process way more Bitcoin transactions than we currently can. Even the Lightning Network doesn’t really scale to billions of people. And yeah, the big dream would be that we can really process millions of transactions per second, millions of Bitcoin transactions per second. And yeah, stuff like. sidechains would enable that. And if we had like some kind of bridge to sidechains, then we could basically process all of the all of humanity’s transactions, all of mankind’s transactions on bitcoin. And that would be the big dream. So yeah. Super Testnet (08:47.174)\ I would add that similar things have been said about the Lightning Network. There’s a lot of people who just aren’t interested in using it, and that’s perfectly fine. If you just want to get some Bitcoin, put it into cold storage, and that’s what you want Bitcoin for is to protect your savings. That’s great. You can do that. But some people also want to use their Bitcoin for regular day-to-day payments. Lightning is a good option for that. And some people want to use them in fancy scripts and contracts, and BitVM is good for that. So I like options. people being able to do what they want and I think BitVM may open up some additional options in how people might want to use their bitcoins. Stephan (09:26.428)\ I see, yeah. And so the elements of scalability that you mentioned there, so I guess what I’m reading from you, gentlemen there, is Robin, you’re speaking there about scalability, and Supertestnet, you’re speaking also about scripting capability. Now, of course, I’m sure Robin, you also agree on the scripting capability. But in terms of scaling Bitcoin, as you mentioned, there’s this idea of a two-way peg and having side chains. Is it also correct to say there might be other scalability wins here, potentially from emulating aspects of covenants? I’ve heard people talk about, let’s say as an example, check template verify, which could help people have congestion control, which in turn could help people with Lightning Network. Do you see any benefits in that vein with BitVM? Robin Linus (10:16.565)\ We are still very early at exploring the boundaries of what BitVM can do and what it can’t do. In that paper that I released yesterday that was focused on the two-party setting, which is very similar to Lightning channels. However, it might be possible to have an open-ended setting. You have one prover and basically everybody can become a verifier and challenge their claims. And if that is possible, then we can use BitVM to emulate basically every opcode proposal, I think. Super Testnet (10:54.198)\ Sometimes it’s called a star topology or an asterisk topology or it’s also known as a hub and spoke model Robin Linus (10:55.126)\ So. Super Testnet (11:00.862)\ where you have a central party who is acting as the prover, and then he has a two of two relationship with a bunch of users. And so this whole group can connect to this one central party. They can rely on that party to make computations for them because each of them knows he can’t lie, he can’t make a false computation, otherwise he would lose his money and forfeit a bond that the group could take. So you can kind of expand work in a two-party setting to work in a star party setting or a one to end party setting. Stephan (11:38.832)\ Oh, interesting. Okay. Yeah. So because that was another area where people were commenting that this would not enable some kind of global state, right? That’s more like channel sort of style state. But what you’re saying is it could be you could have hubs and now that could be seen like a big centralization vector. But in this case, the individual users are able to make sure they’re not being stolen from. So that could mitigate that, right? Robin Linus (11:49.418)\ Thank you. Robin Linus (12:05.42)\ Yeah. Super Testnet (12:08.074)\ Yeah, in some versions of the hub and spoke model, you have to trust the hub not to steal from you, but at least in this case, and also in the case of Lightning, there’s also some parts of the Lightning network use a hub and spoke model, like what are they called? Lightning service providers do this. And in both cases, you don’t have to trust the hub. The hub can’t take your money. If you want to use them, you can, and if you don’t want to use them, you don’t have to. But at least if you do choose to use them, you know that you’re not trusting them to not steal from you. You’re just relying on them to provide some service to you and others. Robin Linus (12:34.669)\ Thank you. Stephan (12:48.156)\ I see. Okay, and so maybe at a high level we can think of this. I know in your paper, Robin, you call out that it has some similarities with what’s known as an optimistic roll-up. So do you mind spelling that out for us? Like what are some of the similarities here with BitVM and optimistic roll-ups? And sort of what does that mean benefit wise to Bitcoin users? Robin Linus (13:15.681)\ The fundamental idea behind optimistic roll-ups is this idea that you can just make a claim and claim that some statement is true. For example, hey, I burned some coins in some side chain, so I’m allowed to take some coins on the main chain. And the idea of optimistic roll-ups is just that I make that claim and if that claim is correct then everything is fine and I can just take the money. But if that claim is incorrect, then everybody can challenge me and disprove. my claim and succinctly give a fraud proof for my claim and then I lose my money. This setting has been explored on altcoins. Robin Linus (13:57.909)\ BitVM is basically a way to import this idea onto Bitcoin. Super Testnet (14:05.878)\ It’s also. Stephan (14:05.892)\ Fantastic, okay. Go on, go on Supertestnet. Super Testnet (14:09.334)\ It’s also been explored more recently in the Bitcoin setting by the proposers of Matt, Merkle lies, all the things. So that’s a, that’s a recent proposal that’s been talked about in the Bitcoin mailing list. And they were also, they’ve also been exploring this, this kind of what we call optimistic computation. So they were part of an inspiration actually cited in the paper as an inspiration because we kind of used their modeling and figured out a way to say, well, you know, actually taproot merkleizes all the things. So let’s just do what they’re doing, but in taproot. So it was kind of fun. Robin Linus (14:43.831)\ Yeah. Stephan (14:45.452)\ Okay, great. And so let’s take it maybe one step more into detail. So Robin, can you explain a little bit about the mechanics of BitVM and how it’s working just to overview that for us? Robin Linus (14:57.041)\ Okay, the most basic idea is to boil everything down to binary circuits. And to make that we need something called bit commitments. A bit commitment is basically, I have a variable, let’s call it A, and the variable can have the value zero or it can have the value one. Now I as the prover, I want to set that value and I want to set it once and for all. I want to say, okay, A has now the value 1. And whenever I reuse that variable A again, I have to use the value 1. If I don’t use the value 1, if I like the next time I claim the value would be 0, then I equivocated like then equivocation means like I said it’s 0 one time and the other time I said it’s 1 and that allows you as the verifier to take my deposit. So you can punish me for equivocating. If I ever say A is one and also A is zero, then you can take my money. That is the Bitcoin. Stephan (15:58.992)\ Gotcha. So in this context, equivocating is kind of like cheating in a lightning channel or something like that. Like you did the wrong thing. Robin Linus (16:04.413)\ Yeah, yeah, like I can only claim that like a valid claim is that a is one or a is zero. But if I claim a is one and then the next day I claim a is zero, then yeah, then I lied. Then I made like a claim that is inconsistent and every inconsistent claim can be punished. That is at the heart. Super Testnet (16:29.138)\ An equivalent thing in lightning is with justice transactions. When you want to close a lightning channel, you have to say what the latest state is. And if at some point prior in the history of that lightning channel you said, no, this is not the latest state, this new state is the latest, then you’ve contradicted yourself or equivocated and someone can punish you, or your counterparty can punish you and take the money that you tried to take from them, or even more. Super Testnet (16:59.292)\ We define variables and then if you equivocate on the variable, if you say it was this and now it’s this, then your counterparty can take your money in that context. Robin Linus (17:13.673)\ The really cool thing is that it’s off-chain state. I can reveal the preimage has two hashes, hash 0 and hash 1. If I reveal the preimage to hash 1 to you, then I set the value to 1. If I reveal the preimage of hash 0 to you, then I set the value of the commitment or the value of the variable to 0. Depending on what preimage I reveal, Stephan (17:13.68)\ Got it, okay. Robin Linus (17:43.013)\ I can set the value. The cool thing about that is that it’s introducing state across different UTXOs or across different scripts. And that is a very novel thing, because usually scripts are limited to a particular UTXO, like only this execution and then the environment is deleted forever. But with this trick of bit commitments, you can introduce the variables that… exist across different scripts and across different UTXOs. And that is pretty much at the heart of the innovation here, that we can have state across different UTXOs. Super Testnet (18:23.082)\ Another factor in the… that lies at the heart of how BitVM works is the concept of deconstructing a program. So any program that exists, like any piece of code or any software has to end up running on a microchip. And since microchips are constructed out of these tiny little circuits called logic gates, you can actually deconstruct any program and turn it into a bunch of these logic gates that are hooked together. And so we do that. We actually take, In the virtual machine, you insert a program, you say, I want to run this program, and the virtual machine parses it and processes it and turns it into a bunch of connected logic gates. And each one of those logic gates then goes in a tap leaf of a Merkle tree in a taproot address. And by having this deconstructed program, it allows you to actually check every step of the execution of that program. You could say, okay, in step A, it has to go through this logic gate, one. You can check every step and say, did the prover accurately and incorrectly execute each step of the program? You can check that in a Bitcoin transaction or in a Bitcoin address. And if they do, if they do execute everything correctly, then well and good, the prover gets to take some sort of payment for doing that service for you. But if they messed up or if they tried to cheat or if they equivocated, you can detect that because you have every detect that and then say here’s the proof where they tried to cheat, here’s the proof where they equivocated, here’s where they ran the program incorrectly. And then you can take the prover’s money. So that’s kind of another, at the heart of this is like deconstructing a program and turning it into all these tiny little steps that Bitcoin can actually understand. Stephan (20:18.696)\ And as you pointed out, this is something that was uniquely enabled by Taproot because of this, the structure of Taproot. And so the, I guess one of the questions or criticisms I’ve seen is this idea that you would be creating these massive, massive tap leaves or tap trees, right? And so could you just elaborate a little bit about that aspect of this that, you know, I guess what we’re getting at here is the initial setup time. Because let’s say we’re setting up a, you know, we’re setting up some kind of bit VM structure. There’s going to be a lot of talking back and forth, a lot of computation required in order to make this work. Robin Linus (21:02.345)\ Yeah, like you have to set up that circle once and you have to express it in a taproot or like in multiple taproots. And real world programs can easily be like billions of gates and billions of gates would basically mean that you need billions of tap leaves. So you need to compute that huge tap tree upfront. And yeah, people were criticizing it, but I think they were mostly criticizing it because they didn’t really get how it can work out. It is right that if you would just naively take a regular program and just compile it to a circuit, then it would become gigantic and it would probably be not possible in practice or it would just take days or weeks to compute it upfront and that would be not a good user experience and it would probably not catch on. But it is not necessary to do it in that way. The thinking where these people are coming from is the regular thinking of like executing programming. If you really have to execute everything, then you need to represent every gate. That is true. But here we are not executing the computation. We are verifying a particular execution. And verifying a particular execution is a lot of magnitude easier than executing an entire computation. And we can craft circuits cleverly in a way such that we need every circuit only once. For example, let’s say we have a single circuit for SHA-256. And now we want to do a million SHA-256 calls. We don’t need to copy that circuit a million times. We need it only once because we need to execute it at most once. And exactly in that case, that the prover lied. Robin Linus (22:56.793)\ As long as the prover is making correct claims, like he’s saying the hash of this preimage is that hash, the hash of this preimage is that hash, and so on, as long as these claims are correct, we never need to really compute them. We don’t need to disprove them. We only ever have to disprove an incorrect claim. So let’s say the verifier makes a million claims about hashes, and then the million and first claim is incorrect. then we only have to verify or disprove this last claim and all the other claims. We never have to touch them because they were already correct in the first place, so there is no need to disprove them or there is no way to disprove them if they are correct. Stephan (23:35.82)\ Yeah, and so as you’ve pointed out in the paper, the cooperative case of this bitVM, a lot of this can be kept off chain, per se. And it’s only in the case where somebody is trying to cheat or somebody’s doing it wrong that you then have to actually go to chain, correct? And then I presume in this case, it’s not that this massive transaction has to hit the chain, it’s that you’re taking a component of the transaction and that’s what goes on chain, yeah? Robin Linus (23:45.233)\ Yeah, everything can be as simple as that. Robin Linus (23:54.56)\ Yes. Robin Linus (24:04.3)\ Yeah. Super Testnet (24:05.31)\ Yeah, you show where the error happened. So you take one of these logic gates, one tiny little piece of code, it’s about 10 lines of code, and you say this is where the error happened. So it’s not very much. It’s smaller than a lightning penalty transaction. Stephan (24:27.408)\ Gotcha. And I guess maybe this is a terminology thing as well, but this has been a hotly debated idea, this notion of Turing completeness. So can you guys elaborate a little bit on that idea? Well, I guess firstly, could you explain what does Turing complete mean? And maybe your view on whether that’s a good or bad thing for Bitcoin, because I think some people have said, oh, no, that’s a bad thing. Maybe if you could explain your view on that. Robin Linus (24:56.397)\ Turing complete in general means like a computer is Turing complete if it can compute everything that is computable. That’s basically the simple explanation of it. Like, there are different… Super Testnet (25:10.742)\ Yeah, there’s a certain class of programs or problems that aren’t decidable by computers. Like what’s the last digit of pi? It’s not a computable number because pi is not a rational number. And if you limit your computation to the subset of problems that computers can actually solve for us, then a Turing machine or a Turing complete computer is one that’s capable of solving all of those problems. Stephan (25:40.316)\ I see. And then any thoughts on that being good or bad for Bitcoin? I presume, obviously, you’re saying it is a good thing to have. I, you know, I’m not saying I necessarily share this criticism, but I’ve seen this criticism out there that people have this idea that it would be a bad thing for Bitcoin. Can you explain your views on that? Robin Linus (26:05.069)\ I think what these opinions are coming from is mostly that, for example, in the EVM, you have lots of complexity on the protocol level. The EVM itself is very complex and that complexity, we don’t want to have it on Bitcoin. We want to keep Bitcoin as simple as possible because if it’s simple, then we can easily reason about the… limitation of the security of the system mostly. And the way we are enabling Turing complete computation here is very different than Ethereum because we don’t increase the complexity of the base layer. The base layer still stays very simple and the operations on the base layer are very simple. Also, the amount of data that has to get written into the base layer is very limited. It’s not like in Ethereum where everybody writes their contracts into the Ethereum chain and everybody has to keep them forever. That is not the case here. Basically, everything is off-chain. In the cooperative case, you don’t even notice on the chain that somebody run a BitVM. In the cooperative case, it’s just a regular schnorz signature. It’s just… a two-party transaction that is the most simple thing you can have on Bitcoin almost. That is way better, I think, from the security point of view and from the decentralization point of view, because all the complexity is shifted off chain. It’s not on the base layer and it’s not a burden of the entire network to verify everything of everyone. It’s way big. Super Testnet (27:49.35)\ In my opinion, a Turing-complete programming environment would be bad for Bitcoin. And I’m glad that Bitcoin is limited and does not have Turing-complete capabilities. And one of the reasons for that is because computers actually can’t distinguish between a program that’s computable and one that’s not. They don’t know if a program is computable. When they first see it, they have to run it to find out. And if it is uncomputable, if there is an uncomputable function, they can get stuck. They can get stuck forever. Robin Linus (28:01.397)\ Me too. Super Testnet (28:19.124)\ the halting problem in computer science. So if we did have Turing complete programming on Bitcoin, it would be potentially really bad because someone could submit a transaction that nodes can’t actually validate. And so they would just get stuck. They’d get stuck trying to validate this transaction forever. Or at least until someone comes up with a different block that doesn’t have that transaction in it. So I think that would be bad to have on Bitcoin. And so by implementing BitVM in a context where we don’t have a Turing-complete programming language, we have to find clever ways of working around that. And the solution we came up with is to create the program outside of Bitcoin. You actually demonstrate outside of Bitcoin that the program is computable. And then you put this already complete program, Super Testnet (29:15.44)\ computable, you put that in a tap leaf or in a tap tree and that way Bitcoin can’t get stuck. It takes advantage of the fact that Bitcoin can’t solve or can’t even try to solve these uncomputable programs. You just have to prove in advance that it’s actually solvable. Stephan (29:33.152)\ Yeah. And I guess the other way to explain that is you could say, as you’re saying, there’s this halting problem. You don’t want the network to come to a halt, obviously, and there’s no centralized server here. It’s just tens of thousands, hundreds of thousands of people with their Bitcoin node running and doing this stuff. But what we could say is in a BitVM context, if let’s say you and I super enter into this kind of BitVM arrangement, if we screwed up our program, it would only screw up you and me, right? It wouldn’t screw up everybody else who’s running Bitcoin. Super Testnet (30:02.186)\ Well, it wouldn’t even screw us up because what would happen is you’d have to, you’d have to, the prover would have to create this program and solve it and then put the program on Bitcoin and show the, and show his counterparty the solution. But if he could never do that, if he could never actually solve it, you just get stuck at step one. Stephan (30:13.915)\ I see. Stephan (30:21.004)\ Right, we would never have been able to start this thing to begin with. Super Testnet (30:23.702)\ Yeah, you could create the funding transaction. You could put money into this tap tree, but the verifier would just get his money right back out because the solver could never provide a solution to the, he could never provide a valid path through a circuit that never halts. Stephan (30:42.332)\ Gotcha. Okay. And so then in terms of what kinds of possibilities this is going to enable, obviously, this is early days, right? The paper just came out yesterday. But if you could spell out for us what you think they might be. So as you mentioned, I guess maybe we can talk a little bit about this two way peg idea, Robin, could you explain a little bit of what you think that view for Bitcoin could be? Like, are you saying somebody could use BitVM? or a future version of BitVM and create some kind of trustless or quote unquote trustless two-way peg in and out and that would then enable transactions on a side chain that can then be pegged back into Bitcoin. Robin Linus (31:25.469)\ Yeah, that’s the big dream and I’m optimistic that it will work out. Super Testnet (31:30.954)\ I’d also like to point out that… Stephan (31:31.663)\ Okay. Super Testnet (31:33.578)\ Before we go into the use cases, I’d like to remind everyone that BitVM is very limited right now. Extraordinarily limited. All we have is the virtual machine itself implemented and one function. We have one single function that can actually run in this thing implemented so far. And it’s actually a useful function. It’s called a zero checking function. And we use it in Bitcoin for stuff like proof of work. But we only have this one thing. In order to build out side chains or covenants or any of the cool stuff that we have, we you know, we might be able to do with BitVM. We need a lot more tools. We need to write a lot more functions, get them running in this thing, get them optimized, and like make developer tools so the developers can actually create contracts, write them and debug them. So that’ll be, that’s a long road to hoe. You know, we’re nowhere near a situation where you can do all this fancy stuff on BitVM. It’s very bare bones implementation right now with one function. So we’re not there yet. Stephan (32:35.948)\ Yeah, totally fair to point out. And I guess the other big advantage, as you were pointing out, is that this does not require a soft fork. So this is possible to do with Bitcoin today. So I guess that’s the important point. And that, yeah. Robin Linus (32:48.205)\ That’s all. Robin Linus (32:51.693)\ It’s basically like the MAD proposal, mergulize all the things, but without a soft fork. Robin Linus (32:59.149)\ That’s the COVID. Stephan (32:59.736)\ Yep. Okay. Super Testnet (33:00.05)\ So one of the things that I’d be excited for is to find out if we can do any form of covenants with this. So covenants are a type of transaction in Bitcoin, or even a type of address, where once money goes into this address, it’s predetermined that it’s going to go into, it’s going to go from there into a predetermined whitelist of other addresses. And it’s possible, I think, that we could implement some form of this primitive using bitVM. And if we can do that, if we can, then that would open up a lot of doors. It would make Arc a lot easier to build, for example. It could help us improve lightning. So, yeah, there’d be some work to do before we could do that, before we could actually do covenants in this, if it’s even possible. So, yeah, I’m looking forward to finding out if we can do that as well. Stephan (33:52.904)\ Yeah. I see. And so as an example with Covenant, so I guess putting that in simple terms, nowadays, in terms of what’s available today, like things like Multi-Sig and so on, I guess that can sort of help you lock the input side of the transaction in terms of what can be spent. But I’m understanding some of what you can do with Covenant is sort of relating to the output side of the transaction, that you’re constraining where it can go, how much of the Bitcoin. Robin Linus (34:23.258)\ So much of it. Stephan (34:24.332)\ in that UTXO can move. So theoretically in the future you might, with the generalized idea of covenants, you might say only 50% of the coin in this UTXO can move or things like this, right? Like you could have, and I think some of this comes in with James O’Bee’s idea of OpVault, and that’s kind of a related idea. So I guess what you’re getting at here is, you’re saying we should explore this possibility of bit. Super Testnet (34:50.466)\ Currently in Biquin, you can make a transaction. where you can say like only Alice or Bob can spend this money. Those are the only two people who are allowed to spend it. They’re the only ones with keys. With covenants, you would instead say something like, I’m going to put some money in an address and 50% of it’s going to go to Alice and 50% of it’s going to go to Bob. And you sort of, some people call it like cursing the Bitcoin. Like it can’t go to anyone else. It has to go to Alice or it has to go to Bob. So that’s what covenants enable. And it’s a primitive that allows for building a bunch more stuff. And so, I’m not sure that BitVM creates the possibility of doing covenants with Bitcoin, but I think it does, or at least something similar to them. So I’d like to explore that and see if we can make that a reality. Stephan (35:39.26)\ Okay. In terms of data availability, so this is another question in the comments. The question was, will it have data availability constraints similar to a rollup? Super Testnet (35:58.41)\ It depends on the contract you’re building. If you were building a rollup with this, then you’d have the problems that come with rollups, one of which is where do you put the data for a rollup? And BitVM doesn’t offer a solution to that. It’s just a way of encoding the logic for a program so that you can execute it on, or so you can prove or validate whether it was executed correctly on Bitcoin. It doesn’t solve problems like where do you put the data in a rollup context. Robin Linus (35:58.825)\ Yeah. Super Testnet (36:26.494)\ So yeah, if you were going to do a roll up, you’d have the data availability problem. But of course, not every contract has a data availability problem. There are contract types that just, that’s not a concern. Like that don’t produce massive amounts of data. That only produce like a megabyte or so. And then you can just store that data locally on your machine. So yeah, it depends on the contract you write. Stephan (36:50.392)\ see. And in terms of… dealing with fees in a lots of disputes situation, I presume that’s just kind of like lightning or just Bitcoin in general today, right? Like if you’re, if lots of people are entering into BitVM style arrangements and they need to go to chain is no different to just the same problem that we have today with lots of people, let’s say closing lightning channels all at the same time today, yeah. Robin Linus (37:17.513)\ Yeah, that’s why sidechains would be better because in sidechains, you don’t really have that problem of a mass exit. As long as the sidechains are through and through. Stephan (37:27.331)\ I see. Super Testnet (37:27.554)\ Well, there could be a rush to the exits from a sidechain if everyone wanted to exit or peg out at once. If there were a million people on a sidechain and they all wanted to rush to the exits, that could be a problem. Robin Linus (37:39.153)\ Yeah, but it cannot fail in the sense that the sidechain stops working as long as it is permissionless, right? For a role, usually it’s the sequence that’s… Super Testnet (37:45.226)\ Yeah, it would just, it would ruin, it would bankrupt the prover. But yeah, he would, yeah, he wouldn’t be able to like not give people their money because BitVM would ensure that they always have a peg out option. That’s kind of cool. Robin Linus (38:01.516)\ Yeah. Stephan (38:03.48)\ Right, so yeah, that is closer to that idea of this so-called trustless two-way peg, as opposed to, you know, having to go through a federation as an example in that context. Robin Linus (38:19.357)\ I mean, in our model, we might have a federation too, but the difference is that the federation is not trusted anymore. Like the federation would be required to execute things and like to perform the pack actually, but if they ever stop working or if they do anything that is invalid, then you can take their deposit and then they will lose more than they gain from taking the system. Stephan (38:26.416)\ Gotcha. Super Testnet (38:40.762)\ I wouldn’t agree that… If you were in a federation with someone and you were relying on them to process blocks so they’re not trusted in any sense at all, they would be trusted for some things, but just not with your money. You wouldn’t be trusting them with your money. You’d be trusting them to like, not cause you an unnecessary expense by suddenly stopping processing blocks on the side chain, causing you to have to exit. You’d have to rely on them not to do that, or at least you’d hope they wouldn’t do that because if they proved to be an unreliable approver, it would cost you time. It wouldn’t cost you money, but it would cost you time. Stephan (39:12.62)\ Yeah, so it’s more like a griefing, yeah, so I guess at that level, it’s more like a griefing concern than a straight up theft concern. Robin Linus (39:20.373)\ Yeah. Super Testnet (39:21.814)\ Yeah, it would be that and it would also just ruin everyone’s day if everyone was relying on this side chain to keep operating and they were building businesses on it and stuff and then suddenly it stopped working. They might not lose money, but their business might not work anymore. And so they’d be like, well, I lost my income though, so, you know, there’s still a lot of trust there. Stephan (39:21.989)\ Okay. Stephan (39:42.393)\ Yeah. Robin Linus (39:42.861)\ A lot of that is like theoretical concerns, I would like to point out, because the good thing about sidechains is that once we have some way to do a Trusses two-way pack, then the sidechain coins will become valuable or like they will be, their value will be equal to BTC. And once there is some way to do the two-way pack or the pack out, then you can have like atomic swaps and perform basically instant packouts. between liquidity providers and sidechain users. Stephan (40:17.944)\ Yeah, I mean, even for me, I’m not 100% sure it would still be the same value, right? Like, even if we had a trustless two-way peg in and out of Bitcoin, would the trustless two-way peg coins, like the sidechain coins, be valued the same as Bitcoin? I don’t know. Robin Linus (40:33.309)\ Yeah, probably. I think they would because you can see it in the Ethereum world that they are pegging ETH to other chains and it is just as valuable as ETH on the main chain. Super Testnet (40:43.794)\ or within a very close percentile. Yeah, I don’t know. If you had a very reliable chain that worked very well, then it would probably be more desirable to use that. And consequently, the network would have more value, and perhaps its peg would be closer to Bitcoin. But if you have a new chain that just started up, maybe not so much. Maybe they have some kind of bootstrapping phase. Robin Linus (40:47.71)\ Yeah. Stephan (40:48.301)\ Yeah, maybe, maybe. Stephan (41:08.508)\ Yeah. One other area that I saw some discussion on was this notion that if we had, let’s say we have bit VM and we had check template verify, would that also change things or make it easier to do this kind of thing? Robin Linus (41:09.569)\ them. Robin Linus (41:23.829)\ Maybe it improves the multi-party setting. For the two-party setting, you don’t need CTV really, because you can pre-sign everything and you can perfectly emulate CTV between two parties. So that won’t be an issue. But for a multi-party setting, for the open-ended setting, where you have a single prover, but multiple verifiers, or everybody can be a verifier, in that setting, it might be interesting to have CTV. Super Testnet (41:49.954)\ There’s an interesting post on the Bitcoin developer mailing list yesterday by Anthony Towns, who did some mathematics on how large a circuit could be, or how large one of these programs could be, and still be able to validate it in a timely manner and with a small number of transactions. And by his mathematics, it looks like you could… increase the size of a possible program if you added CTV by something close to 10 or 12 times. You could get 10 or 12 times bigger. And so that’s kind of cool. But… But yeah, I think already the kind of programs we can have are pretty large. He talks about having 24 million operations in a single program. Most stuff that is interesting doesn’t need that many. So we already have pretty big programs that we could do with this right now. Robin Linus (42:44.597)\ I really want to emphasize that this talk about the space limitations, it doesn’t really fit the reality. You can build a VM with, let’s say, 10GB is all you ever need. If you’re willing to set up a circuit of 10GB, you will be able to perform more computation than anybody ever needs. Super Testnet (43:08.95)\ Right, yeah, I don’t know whatever it needs, but a lot of very realistic and useful things could be built with a small number of gates, or it’s even a large number of gates, it’s like 12 million operations in a single program. Robin Linus (43:23.785)\ Yesterday night I did a calculation and I think like with 10 gigabytes, you can run like a little like a modern CPU with like large memory and everything for about half a day or so, I think. So you could do everything you can do in like half a day. Super Testnet (43:37.194)\ Yeah, so very good. You’re not going to be finding the next digit of pi, but you might be able to do a peg out from a side chain. Robin Linus (43:48.429)\ Yeah, I just want to emphasize I think you can do any amounts of computation. You could even sync a bitcoin full node in a in a bit.vm. Stephan (43:57.728)\ That’s kind of inception based. Okay, so let’s talk a little bit about, yeah, so I guess the practicalities then, like would that mean BitPM users need to have beefy hardware in order to set this up? You know, is it something that, you know, you’re not going to be able to use, like a mobile user is not going to be able to participate in this kind of thing? Super Testnet (43:58.946)\ that would be that would be fantastic Robin Linus (43:59.625)\ Yeah. Robin Linus (44:22.693)\ Yeah, like it might be problematic to set up the circuit on a mobile phone But you could set it up on your on your desktop computer on your laptop or so and then use the same circuit on your Phone that would be possible. I think Super Testnet (44:38.026)\ Yeah, and it also, a lot of this, it depends on the circuit. Not every circuit that’s useful needs to have millions of operations in it that your phone then has to set up. If you’re just doing something that has hundreds or thousands of operations, your phone can do that. So yeah, it really depends on what contract you’re creating. Robin Linus (44:56.202)\ Yeah. Robin Linus (45:01.577)\ And it’s about intelligent circuit design because like we can design the circuit such that it’s easy to disprove it. Like we would not like usually in circuit design, you design it such that it’s easy to execute it or that you can execute it as efficiently as possible. That’s usually the design goal. But here we don’t have that design goal at all. What we want is to be able to disprove an incorrect execution of that shortcut as efficiently as possible. And that is a very different design goal and I think it will be possible to design circuits very efficiently such that probably at some point you will be able to run everything on a phone as well or to set up everything on a phone as well. Stephan (45:44.112)\ Okay, interesting. And it could also be a context where maybe, maybe I can’t think of a good example, but it might be the kind of thing where individuals don’t really use this, but it might be like business to business, and maybe they would use it. And for them, it’s not a big deal that they have high hardware requirements. Maybe that maybe there’s sort of uses of Bitcoin that would make sense like that as well. Robin Linus (46:07.273)\ Especially in the case of a two-way peg. In a two-way peg, the ideas we have been talking about, usually you have some kind of liquidity providers who are the ones who are doing the big amounts of pegs, like pegging in 10 BTC or something to the sidechain or so. That would be one entity and maybe a federation of 50 people or so who get slashed or something. bad happens or so, something along these lines. So only a very small minority of the users would actually have to run the BitVM and most users would not care about it. Stephan (46:43.184)\ Gotcha, so maybe that would be sort of analogous to Lightning today with Lightning service providers or Arc in the future potentially with Arc service providers. These are meant to be highly proficient users and well capitalized with good hardware. So maybe it’s not a big deal for them to have high requirements, as long as the end user can still do what he needs to do without necessarily having an amazing computer and high capital and all these things. Robin Linus (46:48.535)\ Yeah. Robin Linus (47:10.23)\ Yeah. Stephan (47:12.525)\ Yeah, okay. Super Testnet (47:12.99)\ Your phone just has to prove that somebody else proved that some contract was executed incorrectly. Proof-ception. Stephan (47:23.956)\ Yeah, so I guess it’s sort of difficult to explain the practical use of this today for the end user. But I guess as I’m trying to summarize it back into what is practical for the end user today, potentially in the future, this allows a two-way peg out to a side chain, or potentially there may be some way to enable covenants in Bitcoin today without a soft fork. But I guess it’s sort of a more research and more effort is required. Robin Linus (47:53.889)\ The end goal is definitely to scale, or like for me personally, the end goal is to scale Bitcoin to like a million transactions per second. That is what I’m about in general. But to make like just a couple of examples of things that people can relate to more easily is like, for example, you could play chess on a BitVM or poker or Go or stuff like that. That is something that’s maybe more easy to grasp. Stephan (48:21.948)\ Okay, but I guess for a lot of people they’re just gonna say, well, I don’t really care about playing chess on Bitcoin. Like I’d go to chess.com or, you know, Lee Chess or something to play chess, right? Robin Linus (48:31.389)\ Yeah, I’m just making these examples to show like, what would be possible to compute on Bitcoin now. Like, the point I want to make is like, you can have very complex round based computation, off-chain on Bitcoin, and it can be basically as complex as you want. That’s why I mentioned it. Super Testnet (48:51.338)\ Someone pointed out the other day that high stakes poker can’t be done online right now because you don’t trust the poker websites with $200 million. But you might trust Bitcoin with that amount of money. And so if we could build a poker game in BitVM, that might be useful for some people. They might be like, oh, now I can gamble $200 million on whether I get a pair of aces. Some people might want to do that. Not me. Hopefully not anyone reasonable. Stephan (48:51.704)\ Yeah, I see. Stephan (49:23.136)\ Yeah, possible, I guess. I think maybe there’s other concerns with that too, that, uh, you know, nowadays people are worried about bots, um, and like high level poker bots being able to beat all, but the most advanced poker player, human poker players and things like that. Um, but, uh, yeah. Robin Linus (49:30.66)\ Yeah. Robin Linus (49:37.917)\ Or just collaboration. Like in online poker, the main problem is that you can never know if all the other people on the table are collaborating against you, right? Stephan (49:47.864)\ Right, right, yeah, that’s another one where obviously there have been scandals in the poker world before in relation to that kind of thing. Okay, so I’m just trying to think about how to best summarize this. So… Let me try to, okay, I’m gonna try to summarize this. Obviously, it’s quite technical, but you tell me if I’m getting something wrong here. So the idea is you are creating this prover and verifier dynamic and a challenge response dynamic, and you’re using the fact that Taproot allows you to have these massive, massive tap trees of transactions that allows people to sort of pre-compute things in advance. and allow them to compute and then disprove if somebody’s doing something wrong. The aim being to enable more scalability or potentially more covenants in Bitcoin. Is that sort of a high level way to think about this? Robin Linus (50:52.201)\ Yes. The only thing I would add is that we also get privacy. If we have a two-way pack, we also get privacy, basically, not just scalability, but also privacy. Super Testnet (50:53.113)\ Some of that sounded right. Stephan (51:07.316)\ Yep, and Supertestnet, anything to add on that? Super Testnet (51:09.839)\ I would say it, BitVM potentially gives us a lot of scripting superpowers that have been really hard to do in Bitcoin before. And right now they’re still hard, but we have a path now to making them easier. And so that’s really cool. But what we can do with it in the future, we might be able to do covenants, we might be able to do side chains. And those are the two things that I’m currently gunning for. Hopefully, or in games as well would be a third one. But hopefully people will think of stuff that we haven’t thought of. And they’ll just be like, you know what, if we have a computer running on Bitcoin now, let’s put this on it. Maybe we’ll run, I don’t know, Doom on the blockchain. Or I mean, not on the blockchain, off the blockchain, you should say. But we’ll see, we’ll see what people come up with. Stephan (51:56.26)\ Great. Well, bitvm.org is the link. I’ll put all the links in the show notes over at stephanlivera.com. Any closing thoughts from you guys, Robin and Supertestnet. Robin Linus (52:06.933)\ Sure, if you want to fund the development, look at the Bitcoin address in the paper. Stephan (52:13.892)\ And SuperTestnet, anything else you want to mention? Super Testnet (52:17.634)\ Let’s go. Stephan (52:20.495)\ Alright, let’s go. Thank you for joining me guys. Robin Linus (52:20.822)\ Let’s go. Thanks a lot for having us. Super Testnet (52:24.334)\ Thank you, Stephan. # Ark Whiteboard Masterclass with Burak & Robin {% embed url="" %} ### Chapters: 00:00:00 Intro 00:01:20 Burak's Issues with Lightning 00:05:29 Ark is VERY Different 00:09:27 Liquidity limitations of Lighting visualized 00:18:10 What Ark can bring to Lightning 00:22:10 High-level sketch of how Ark works 00:33:49 How Ark transactions are made Atomic 00:53:39 Interactive Protocol, step by step 00:57:17 Permissioned Peg-in, Permissionless Peg-out 01:02:39 Are Bank-like things on Bitcoin a good thing? 01:04:33 Federation-owned ASPs 01:09:09 Downside #1 - Liveness requirement 01:17:23 Downside #2 - On-chain footprint 01:22:39 Coinjoin privacy 01:46:28 Pro / Con summary 01:47:56 On-chain spend out logistics 01:50:16 How should we use Ark? 01:54:26 Liveness requirement revisited 02:02:32 Implementation roadmap # BitVM Intro: Create Logic Gates and Circuits in Python {% embed url="" %} # Demo of Robin Linus's implementation of BitVM {% embed url="" %} Robin is almost finished with his cpu simulator for bitvm. Some of its features: it has a 32 bit processor 17 GB of ram It runs about 4 billion cpu cycles in a few seconds (so it runs at about 1 gigahertz) For Paul and Vicky to set up the cpu, Paul has to share about 4mb of data with Vicky He is currently adding more ASM instructions to it. It currently supports Add, Subtract, Jump, Branch if Equal, and Branch if Not Equal. For more info, see here:[ https://github.com/BitVM/BitVM/](< https://github.com/BitVM/BitVM/>) And talk about it with us in our telegram: # BitVM 8 bit CPU: Write Bitcoin programs in Assembly {% embed url="" %} Super Testnet has built an 8 bit CPU for BitVM, so programs are easier to create. I walkthrough how it works and a tool to help you write these programs. Let me know in the comments if you write any interesting programs, or share them in the BitVM Builders Telegram group! Program writing tool: [https://magical-frangipane-149aba.net...](https://magical-frangipane-149aba.netlify.app/compiler) 8 bit CPU documentation: [https://github.com/supertestnet/8bit-...](https://github.com/supertestnet/8bit-cpu-for-bitvm) 8 bit CPU implementation: [https://supertestnet.github.io/8bit-c...](https://supertestnet.github.io/8bit-cpu-for-bitvm/) BitVM Builders Telegram group: Follow Super Testnet here: @highlevelbitcoin # BitVM 8 bit CPU: Assembly Quirks {% embed url="" %} Super Testnet's 8 bit CPU for BitVM has some interesting quirks to it. Let me know in the comments if you write any interesting programs, or share them in the BitVM Builders Telegram group! Program writing tool: 8 bit CPU documentation: 8 bit CPU implementation: BitVM Builders Telegram group: Follow Super Testnet here: @highlevelbitcoin # BitVM 8 bit CPU: Write Bitcoin programs in Assembly {% embed url="" %} # How bitvm works: from logic gates to an 8bit cpu for bitcoin {% embed url="" %} In this video I outline how bitvm works and illustrate how we can use it to run programs written in Assembly on bitcoin # S15 E13: Robin Linus on BitVM & Permissionless Bitcoin Development {% embed url="" %} Robin Linus talks about BitVM, trust minimized sidechains, and everything else which enables permissionless development in Bitcoin. Thanks to BitVM, in the next couple of years we'll see many more scaling solutions such as sovereign rollups. ––––––––––––––––––––––––––––––––– ––––––––––––––––––––––––––––––––– **BitVM and the need for it (00:00:47)** Robin explains the need for BitVM in scaling Bitcoin and enabling trustless two-way pegs for sidechains and zk rollups. **Zero knowledge proofs and their importance (00:02:00)** Robin discusses the significance of zero knowledge proofs for compressing computations and solving the scalability problem in decentralized systems. **Use cases and controversy of BitVM (00:05:39)** The discussion covers the controversy and potential use cases of BitVM, including its relevance for mobile wallets and the concept of Turing completeness. **Potential use cases for BitVM (00:12:24)** The conversation explores potential use cases for BitVM, focusing on scaling payments and trustless bridging to sidechains. **Release and technical updates for BitVM (00:17:20)** The interview delves into the timing and technical requirements for the release of BitVM, including the influence of original inscriptions, Taproot, and SegWit. **Bitcoin's future and use cases for BitVM (00:22:54)** Robin discusses his vision for Bitcoin's future, emphasizing the use of BitVM for bridging Bitcoin to sidechains and enabling a free market of trustless sidechains. **Sidechains and Scaling (00:27:25)** Discussion on the potential efficiency and scalability of sidechains compared to the main layer of Bitcoin. **Consensus Mechanisms (00:28:46)** Exploration of different consensus mechanisms for sidechains, including the concept of Bitcoin-backed proof of stake algorithm. **Reactions to Proof of Stake (00:32:37)** Concerns and responses to the idea of integrating proof of stake into Bitcoin, including potential opposition from the community. **Atomic Swaps and Lightning Network (00:40:16)** The use of atomic swaps and the Lightning Network for seamless transactions and liquidity provision across different sidechains. **Scaling Solutions (00:47:31)** Discussion on the need for scaling solutions, including the limitations of current layers and the potential role of sidechains in scaling block space. **Efficiency and Optimization of Sidechains (00:48:12)** Consideration of ways to make sidechains more efficient, including the possibility of pruning data to prevent excessive bloat. **Number of Sidechains and Market Optimization (00:50:17)** Exploration of the potential number of sidechains needed for global scalability and the market's optimization of cross-chain transactions. **The need for BitVM in Bitcoin (00:53:30)** Discussion about the need for confidential transactions in Bitcoin and the potential use of Zcash's compression technology in Bitcoin. **Client-side validation and compact transactions (00:54:49)** Exploration of client-side validation, the use of digital signatures and hashing, and the concept of compact transactions. **Lamport signatures and statefulness in BitVM (01:04:05)** Explanation of the role of Lamport signatures in enabling statefulness and transporting values across different scripts in BitVM. **BitVM funding and the ethos of Bitcoin developers (01:14:04)** Discussion about the funding of BitVM through research grants and the ethos of Bitcoin developers in focusing on the work and the cause rather than financial gains. **Challenges of getting paid before work is done (01:16:26)** Exploration of the challenges and potential downsides of receiving money before work is completed, and the potential impact on the developer's mindset and work ethics. **The value of work (01:19:24)** Discussion on how the perception of one's work can affect its quality. **The Supra cycle (01:19:55)** Explanation of the "Supra cycle" theory in the context of Bitcoin's market trends. **The Toyota Supra analogy (01:20:30)** An analogy using the Toyota Supra to illustrate a linear model for Bitcoin market trends. **Creating purpose (01:22:57)** Encouragement to create purpose and make decisions rather than waiting indefinitely. # BitVM: Uma Ferramenta Para Contratos Ainda Mais Inteligentes - Super Testnet - Satsconf 2023 {% embed url="" %} # BTC生态浏览超70万次的BitVM到底是什么？ ｜ 11月8日更新了什么？ {% embed url="" %} # BitVM 在比特币上实现智能合约 PPT of the vedio: {% embed url="" %} # Bitcoin Smart Contracts and BitVM > original: > > author: Bitcoin University {% embed url="" %} Join Bitcoin University Premium: In this video, I discuss BitVM, which is a new way to bring Turing-complete computation to Bitcoin without unnecessarily burdening the base layer as Ethereum does with the EVM. Here's the good news about BitVM: BitVM does NOT require a soft fork or any protocol changes. BitVM does NOT bloat the Bitcoin blockchain. BitVM computations are NOT executed on Bitcoin, but merely verified using the Bitcoin network. BitVM is a great example of how setting constraints can foster dev creativity, while still maintaining Bitcoin's core values of security and decentralization. Not investment advice! Consult a financial advisor. # Twitter # BitVM and MATT # Script, Taproot and BitVM # Libraries * [Bitcoin compiler in C++](https://github.com/maitrebitcoin/bitcoin-bitvm-compiler) * [BitVM Toy Implementation](https://github.com/BitVM/BitVM) * [BitVM in Rust](https://github.com/BitVM/rust-bitcoin-scriptexec) * [LogicGates: Logical gates in Python for different scenarios on BitVM (Phython)](https://github.com/mcbagz/LogicGates) * [SHA256 WASM](https://github.com/BitVM/sha256) * [BLAKE3 WASM](https://github.com/BitVM/blake3) * [RIPEMD160 WASM](https://github.com/BitVM/ripemd160) * [Elftrace](https://github.com/halseth/elftrace) * [rv32i to BitVM](https://github.com/zippiehq/rv32i-to-bitvm) * [Toy BitVM RS](https://github.com/chainwayxyz/toy-bitvm-rs) * [Tapleaf Circuits](https://github.com/supertestnet/tapleaf-circuits) # Tutorial # STARK proof for BitVM circuit execution > original: {% file src="/files/qyDhfIzOGN0Edw5U8NTI" %} # BitVM and sCrypt > original: #### Invitation to Bitcoin Developers: Utilize sCrypt for Advanced BitVM Implementations **To the Bitcoin Development Community,** In light of the recent advancements in BTC's computational capabilities introduced by [BitVM](https://bitvm.org/bitvm.pdf), we are extending an open invitation to explore the integration of sCrypt as a language for developing BitVM scripts. BitVM represents a significant advancement in Bitcoin's scripting capabilities, enabling Turing-complete contracts within the existing BTC framework. **Technical Overview:** BitVM facilitates off-chain computation, essential for complex contract execution while maintaining Bitcoin's on-chain efficiency. While Assembly (ASM) scripts are so far used to express contracts for BitVM, they present certain limitations in terms of readability and broader accessibility. [sCrypt](https://scrypt.io/), a high-level language based on TypeScript tailored for Bitcoin smart contracts, offers a more efficient and streamlined approach for developers. The language's design aligns with traditional programming paradigms, enhancing understandability and maintainability of scripts. **Example of Gate Commitment in sCrypt:** ``` type HashPair = { hash0: Ripemd160 hash1: Ripemd160 } export class DemoBitVM extends SmartContract { @prop() hashPairA: HashPair @prop() hashPairB: HashPair @prop() hashPairE: HashPair constructor( hashPairA: HashPair, hashPairB: HashPair, hashPairE: HashPair, ) { super(...arguments) this.hashPairA = hashPairA this.hashPairB = hashPairB this.hashPairE = hashPairE } @method() public openGateCommit( preimageA: ByteString, preimageB: ByteString, preimageE: ByteString, ) { const bitA = this.bitValueCommit(this.hashPairA, preimageA) const bitB = this.bitValueCommit(this.hashPairB, preimageB) const bitE = this.bitValueCommit(this.hashPairE, preimageE) assert(this.nand(bitA, bitB) == bitE) } @method() bitValueCommit(hashPair: HashPair, preimage: ByteString): boolean { const h = hash160(preimage) assert (h == hashPair.hash0 || h == hashPair.hash1) return h == hashPair.hash1 } @method() nand(A: boolean, B: boolean): boolean { return !(A && B) } } ``` The code above represents a simple gate commitment for BitVM. It has a single entry point, i.e. the public function "openGateCommit", which can be unlocked by providing the apporpriate hash preimages of the commitments. The code compiles into a bitcoin script, the function of which is analogous to the script described in the BitVM whitepaper (Figure 2): ``` // Reveal Preimage of hashE0 or hashE1 OP_BITCOMMITMENT OP_TOALTSTACK // Now the bit value of "E" is on the stack // Reveal Preimage of hashB0 or hashB1 OP_BITCOMMITMENT OP_TOALTSTACK // Now the bit value of "B" is on the stack // Reveal Preimage of hashA0 or hashA1 OP_BITCOMMITMENT OP_TOALTSTACK // Now the bit value of "A" is on the stack // // Verify that "A NAND B == E" // // Read "B" from alt stack OP_FROMALTSTACK // Compute A NAND B OP_NAND // Read "E" from alt stack OP_FROMALTSTACK // Check A NAND B == E OP_EQUALVERIFY ``` The equivalent is expressed in sCrypt as: ``` const bitA = this.bitValueCommit(this.hashPairA, preimageA) const bitB = this.bitValueCommit(this.hashPairB, preimageB) const bitE = this.bitValueCommit(this.hashPairE, preimageE) assert(this.nand(bitA, bitB) == bitE) ``` For more information about sCrypt, please refer to [the official documentation](https://docs.scrypt.io/). **Invitation and Objectives:** 1. **Examination of sCrypt**: We encourage the exploration of sCrypt's features and syntax. Its alignment with conventional programming languages positions it as a viable candidate for BitVM script development. 2. **Contribution Using sCrypt**: Contributions in sCrypt to the BitVM ecosystem are highly encouraged. Such endeavors would ease the utilization of BTC's full scripting capabilities. 3. **Technical Exchange and Collaboration**: The advancement of BitVM and sCrypt requires collective efforts in knowledge exchange and technical collaboration. We welcome insights from both experienced and emerging developers in the Bitcoin community. **Sincerely,** Mihael Šinkec, sCrypt Inc. # BitVM Rust Implementation # Exploring the Landing Paths for Bitcoin Layer 2 Ecosystem > original: > > Author: @tmel0211 Source: In the midst of the frenzy surrounding the inscription FOMO, I’ve had encounters with some “true” Bitcoin developers. Surprisingly, they don’t exhibit overheated enthusiasm and talk about disrupting Ethereum with Bitcoin Layer 2, as one might expect. Instead, there seems to be a consensus: the Bitcoin ecosystem has potential, but it will be distinct from Ethereum’s DeFi Lego-like paradigm. Moving forward, based on technical reasoning, let’s delve into how the Bitcoin ecosystem should be implemented. Indeed, this new asset issuance method, like the inscription, has drawn many people back to the ICO era of 2017, igniting enthusiasm once again. This wave of inscription enthusiasm has brought new users, new application scenarios, and additional funds. To some extent, it’s justified to call this a Bitcoin bull market. Subsequently, various directions such as sidechains, the Lightning Network, Taproot Assets, RGB, BitVM, etc., are crowded with “coveters” of Bitcoin’s orthodox Layer 2. They often loudly proclaim their intention to replicate everything from Ethereum in the Bitcoin ecosystem, creating quite a stir. Just like the unsustainable nature of the ICO asset issuance boom, the inscription market also yearns to take on a brand-new Bitcoin Layer 2 trend as the FOMO tide subsides. Having such ambitions and aspirations is not wrong. However, if one wants to replicate the diverse gameplay of Ethereum’s ecosystem in Bitcoin, it’s not feasible (see the top article for details). The Bitcoin ecosystem needs to explore a landing path that aligns with its inherent characteristics. The core logic is that the native characteristics of the Bitcoin chain impose “constrained” computing and verification capabilities. Even the storage capacity in the Taproot address SegWit is subject to controversy regarding dust attacks. The limited computing power means that more complex transaction logic must be implemented off-chain. For example, bitVM envisions a Turing complete computation based on off-chain circuits and on-chain logical gates (0, 1), implemented based on the optimistic Rollup concept. While this idea is ambitious and the technical logic is reasonable, the engineering effort required is impractical. The limited verification capability makes Bitcoin more suitable for asset settlement than global state verification. The Schnorr signatures and MAST data structure features of Bitcoin nodes currently provide some verification capabilities. However, Schnorr only aggregates multiple signatures, limited to multi-signature scenarios, and MAST allows the creation of more complex scripts, but relying on the UTXO model can only perform asset settlements and cannot achieve global state verification. Building a complex light node matrix can enhance the interactivity between sidechains and the main chain, improving the security and response speed of asset settlements. The storage dispute is undeniable. Bitcoin has developed on an extremely minimalistic path, a consensus reached after the end of the previous block size war. Therefore, the idea of making significant changes to the script space based on Taproot is certainly impractical. Although it may not reach the extent of the SegWit being castrated, upgrade protocols like Atomicals, RUNE, PIPE tend to compromise and lean towards smaller block directions, such as discarding large JSON data packets and returning to optimizing and applying OP\_Return space. These limitations determine that Bitcoin’s Layer 2 expansion solutions are significantly different from Ethereum: **1.Bitcoin lacks Data Availability (DA) capabilities.** Ethereum’s DA is the computational and verification capability of the mainnet validators for layer 2 submissions. Clearly, while Bitcoin can accept a certain amount of data, the mainnet does not possess viable and efficient computing and verification capabilities. Therefore, Bitcoin’s DA is more like a “bulletin board” where raw data is stored in the Bitcoin block and can only be accounted for and verified by off-chain indexers. This will undoubtedly test the accounting and verification capabilities of indexers. If there are multiple indexers, the challenge will be further increased, leading to confusion and error issues in accounting logic. **2. Bitcoin’s interoperability is limited.** Ethereum’s layer 2 submits the state to the mainnet, and the mainnet has contracts that can coordinate with the layer 2 to implement mechanisms such as a 7-day challenge time window and a layer 2 escape hatch to ensure that the mainnet can protect the assets of layer 2 users in the premise of Sequener’s malfeasance. Obviously, Bitcoin, without the capability of smart contracts, does not have this level of security. Users can only trust that Bitcoin Layer 2 will not behave maliciously. **3. Bitcoin’s UTXO security model is limited to “payment” scenarios.** Similar to the solution of Ethereum’s Plasma layer 2, if each transaction’s corresponding nonce hash, etc., is synchronized with the mainnet in the form of UTXO by the layer 2, a secure mode can be established based on UTXO. However, just like Plasma is limited to payment scenarios, Bitcoin Layer 2 based on the UTXO model also has this limitation. Any mechanism with a complex smart contract like EVM cannot solely rely on this security mechanism unless additional consensus outside the Bitcoin chain is added. Given this technical logic and understanding, the narrative space for Bitcoin Layer 2 becomes very clear: 1.**Use Bitcoin as a settlement layer, build an independent consensus for Layer 2, and provide a comprehensive set of DA, interoperability, VM virtual machine, and various other capabilities that align with Ethereum’s ecosystem.** However, such a powerful chain is essentially recreating an Ethereum execution chain. Many people may not know that Ethereum actually has a Beacon settlement chain, and what we see as the main chain of Ethereum 2.0 can be regarded as a layer 2 of the Beacon chain. The reason why people have a weak perception of the settlement chain is that the core of the mainnet is the ability to verify interactions. If you only build a settlement chain, the chain that handles a large number of computation and verification operations will become the true “main chain.” The problem arises: If we use Bitcoin as a settlement chain, can other chains dare to call themselves the main chain? Does the Bitcoin ecosystem allow the existence of such “consensus”? 2\. Use Bitcoin for payment solutions, including the Lightning Network, Taproot assets, and client verification of RGB. Essentially, these solutions rely on the UTXO model of the Bitcoin mainnet to provide security. This naturally limits these solutions to payment scenarios. The Lightning Network provides a smooth experience for the circulation of small amounts of Bitcoin. Similarly, Taproot assets and RGB are also suitable for stablecoin payment channels. (Sponsored by NEXO. Sponsorship does not represent the views of WuBlockchain and does not constitute financial advice from WuBlockchain. Readers are requested to strictly abide by local laws and regulations.) If you want to overlay some DeFi and EVM states on state channels and client verification, it is equivalent to adding more complex verification logic on the original UTXO model. Naturally, some states that the mainnet cannot verify will be submitted to the mainnet, essentially relying on off-chain consensus. Such solutions may work, but the security level will correspondingly decrease compared to transaction scenarios controlled by a pure UTXO model. In conclusion, how can the Bitcoin ecosystem land? If the Bitcoin ecosystem empowered by pure Bitcoin security consensus points to applications and consumption scenarios such as the Lightning Network and Taproot assets, then RGB client verification and other complex application scenarios that can achieve complex Layer 2 smart contracts; If Bitcoin allows some off-chain consensus outside the main consensus, it points to complex application scenarios of RGB client verification that can achieve complex Layer 2 smart contracts; If the Bitcoin mainnet only serves as a settlement chain, relying on independent consensus outside the chain, then various solutions such as sidechains, consortium chains, index chains, etc., that can establish consensus and strictly enforce transparent asset settlement seem to be viable. If groundbreaking Bitcoin Turing computing and verification solutions like BitVM are implemented, and they are cost-effective and lower than Ethereum’s smart contract construction, then the above conclusions may be overturned. In any case, the impossible triangle problem of security, decentralization, and scalability is more pronounced on the Bitcoin mainnet. The so-called orthodox Bitcoin Layer 2 may be a pseudo-proposition. In my view, choosing orthodox consensus means accepting the “limitations” of expansion. If you want to break through these limitations, don’t wave the flag of an invincible consensus. Follow us\ Twitter: \ Telegram: # Overview
ProjectDescriptionWebsiteStage
BitLayerThe First Bitcoin security - equivalent Layer2 based on BitVMwebsite:https://www.bitlayer.org/
twitter: https://twitter.com/BitLayerLabs		testnet Released ;
Mainnet released in March 2024
ZKBaseLayer2 for Bitcoin & Ethereumwebsite:https://zkbase.org/
twitter: https://twitter.com/ZKBaseOfficial
Telegram: https://t.me/ZKSpaceOfficial		Testnet in March 2024
CitreaBitcoin's First ZK Rollup Citrea is the first rollup that enhances the capabilities of Bitcoin blockspace with zero-knowledge technology, making it possible to build everything on Bitcoin.website: https://citrea.xyz/
twitter: https://twitter.com/citrea_xyz
BitstakeA proof of stake bridge based on BitVMintroduction: https://lightco.in/2024/02/13/bitstake/
# Bitlayer > **Bitlayer** [@BitLayerLabs](https://twitter.com/BitLayerLabs) *The first Bitcoin security-equivalent Layer 2 based on BitVM;* > > original: > > author: bitlayer ## Bitlayer ### Introduction to Bitlayer Bitlayer is the first Bitcoin security-equivalent layer 2 based on BitVM. It consists an EVM compatible chain/sequencer that can map BTC ecological assets and facilitate the entry of BTC users. ### Bitlayer’s Value Propositions Due to the technical nature of Bitcoin, there exists a trade-off between "Security and Turing completeness" for Bitcoin layer2 solutions. Bitlayer aims to resolve this dilemma and realize a Bitcoin layer 2 that is equally secure as Bitcoin and Turing complete through cryptographic innovations and blockchain protocol engineering. This is intended to ultimately foster a prosperous Bitcoin ecosystem. ### Technical Features Bitlayer's core objective is to address the trade-off between security (trustless) and Turing completeness in BTC Layer 2. Based on this context, three key tasks are abstracted: 1. Trustless entry and exit of L1 assets 2. State transitions using a Turing-complete L2 virtual machine 3. L1 verification of the validity of L2 state transitions Bitlayer innovatively utilizes the DLC/LN protocol to enable trustless bidirectional flow of signals/assets. It introduces VMs (EVM, SolanaVM, MoveVM, etc.) to support a wide range of state transition expressions. ### About Us The sophisticated public blockchain development and ecosystem construction team, hailing from Huobi, Polygon, and Polkadot, boasts years of practical experience in leading public blockchains and has achieved top-notch industry results. The product research and development team possesses comprehensive experience in full-stack blockchain development and operations. They have initiated 3 EVM-compatible chains, 2 Ethereum zk-rollups, and 1 MPC+AA self-custody platform, along with various core application protocols, accumulating a total TVL (Total Value Locked) of over 14 billion and a daily transaction volume exceeding 4 million. The ecosystem construction team has rich global resources in web3 application project developers across more than 20 countries, with over 6 years of extensive experience in early-stage Polkadot and Polygon ecosystem development. They have led the integration of hundreds of ecosystem projects onto public blockchains and have experience in strategic collaborations with dozens of leading large enterprises in the blockchain space. Thanks to the rich experience and resources of the core team and early-stage investment incubators in the industry, the team possesses strong capabilities in achieving results in areas such as research and development, business operations, capital, channels, and community support. ### Interact With Us On Social Media * Website: [https://bitlayer.org](https://bitlayer.org/) * Twitter: * Medium: * Email: * GitHub: # Introduction ### Introduction to Bitlayer Bitlayer is the first Bitcoin security-equivalent layer 2 based on BitVM. It consists an EVM compatible chain/sequencer that can map BTC ecological assets and facilitate the entry of BTC users. ### Bitlayer’s Value Propositions Due to the technical nature of Bitcoin, there exists a trade-off between "Security and Turing completeness" for Bitcoin layer2 solutions. Bitlayer aims to resolve this dilemma and realize a Bitcoin layer 2 that is equally secure as Bitcoin and Turing complete through cryptographic innovations and blockchain protocol engineering. This is intended to ultimately foster a prosperous Bitcoin ecosystem. ### Technical Features Bitlayer's core objective is to address the trade-off between security (trustless) and Turing completeness in BTC Layer 2. Based on this context, three key tasks are abstracted: 1. Trustless entry and exit of L1 assets 2. State transitions using a Turing-complete L2 virtual machine 3. L1 verification of the validity of L2 state transitions Bitlayer innovatively utilizes the DLC/LN protocol to enable trustless bidirectional flow of signals/assets. It introduces VMs (EVM, SolanaVM, MoveVM, etc.) to support a wide range of state transition expressions. ### About Us The sophisticated public blockchain development and ecosystem construction team, hailing from Huobi, Polygon, and Polkadot, boasts years of practical experience in leading public blockchains and has achieved top-notch industry results. The product research and development team possesses comprehensive experience in full-stack blockchain development and operations. They have initiated 3 EVM-compatible chains, 2 Ethereum zk-rollups, and 1 MPC+AA self-custody platform, along with various core application protocols, accumulating a total TVL (Total Value Locked) of over 14 billion and a daily transaction volume exceeding 4 million. The ecosystem construction team has rich global resources in web3 application project developers across more than 20 countries, with over 6 years of extensive experience in early-stage Polkadot and Polygon ecosystem development. They have led the integration of hundreds of ecosystem projects onto public blockchains and have experience in strategic collaborations with dozens of leading large enterprises in the blockchain space. Thanks to the rich experience and resources of the core team and early-stage investment incubators in the industry, the team possesses strong capabilities in achieving results in areas such as research and development, business operations, capital, channels, and community support. ### Interact With Us On Social Media * Website: [https://bitlayer.org](https://bitlayer.org/) * Twitter: * Medium: * Email: * GitHub: # Technical Introduction ## Basic Concepts For users and developers alike, the fundamental concept of Bitlayer is outlined below: ![analog](https://docs.bitlayer.org/images/analog-btc-eth.png) Bitlayer acts as a Layer 2 solution for Bitcoin, boasting **100% EVM and Ethereum toolchain compatibility**, with BTC as native token(gas token). Users can engage with it using wallets such as **Metamask, imToken, or other Ethereum-compatible wallets**. Developers are afforded the ease of migrating smart contracts written in **Solidity, Vyper, or any other language that compiles to EVM bytecode** directly to Bitlayer, using the toolchain you are familiar with: Ethereum JSON-RPC, Hardhat, etc. ## Architecture ![arch](https://docs.bitlayer.org/images/architecture.png) Bitlayer subscribes to the typical model of an Optimistic Rollup equivalent. ## Benefits ![benefits](https://docs.bitlayer.org/images/benefits.png) ## Bridges Bitlayer will be connected by numerous bridges. ![bridges](https://docs.bitlayer.org/images/bitlayer-bridges.png) ### Bitlayer <--> Blockchains If the **source chain** is Bitcoin, it is recommended to use UniSats, Xverse, or another Bitcoin wallet as the source wallet. ### Bitlayer <--> CEXs(centralized exchanges) You can withdraw from CEXs to the bitlayer's ETH-Compatible wallet address. # Citrea Citrea [ @citrea\_xyz ](https://twitter.com/citrea_xyz) The first rollup that enhances the capabilities of Bitcoin blockspace with zero-knowledge technology. # Technical Introduction > original: > > author: citrea *Citrea is the first rollup that enhances the capabilities of Bitcoin blockspace with zero-knowledge technology, making it possible to build everything on Bitcoin. Citrea’s vision is to build scalable infrastructure that advances Bitcoin into its next phase, foundation for world's finance.*

Citrea: Seed Round 2023

We’re proud to announce that Chainway Labs, the company building Citrea, has raised $2.7 million in seed funding to develop Bitcoin’s First ZK Rollup. The round closed in 2023 and was led by Galaxy, with participation from investors including Delphi Ventures, Eric Wall, Anurag Arjun, BatuX, Igor Barinov, and James Parillo, among others. Citrea introduces a zero-knowledge powered rollup solution to address Bitcoin’s challenges in handling more transactions and supporting diverse applications without changing its consensus rules. In doing so, Citrea leverages Bitcoin not only as a digital currency but also as a base layer for securing and settling transactions. ## Characteristics Characteristics of the Citrea blockchain.\ \ In short: * Type 2 zkEVM * Sequencer with a block producing privilege, inscribing state roots on Bitcoin to finalize ordering. * Prover with a responsibility of producing batch proofs and light client proofs, both via scanning Bitcoin blockspace. * Full and light nodes are able to easily and securely verify the blockchain. * Bitcoin Settlement via BitVM. Citrea proofs are optimistically verified in Bitcoin, enabling the first universal trust-minimized bridge. ### Execution Environment The Citrea VM is a fully Ethereum Virtual Machine (EVM) equivalent VM running on Bitcoin and using $cBTC as its native token. EVMs as a concept are the most battle-tested and mature VM in the cryptocurrency ecosystem. It is a deterministic, stack-based virtual machine, renowned for its ability to efficiently execute smart contracts in a secure and isolated environment. Citrea implements its own EVM, referred to as a "zkEVM." zkEVM is a special EVM implementation that makes the full VM implementation provable. Citrea zkEVM is classified as Type 2, which means full equivalency and a scalable and trustless proof system due to being based on zk-STARKs. Citrea zkEVM is built using RISC Zero. For further compatibility, Citrea is implemented intentionally to make multiple VMs interoperable. ### Block Production
Block Production in CitreaIn Citrea, the entity responsible for producing blocks is called the "sequencer." A sequencer, unlike a validator or miner, doesn't need validations over produced blocks from other sequencers or nodes because every block produced by sequencers undergoes a zero-knowledge proving process, which acts as a natural and trustless validation mechanism over blocks.The sequencer builds blocks using its own local mempool. Anyone can a send transaction to sequencer's mempool using its RPC endpoints or a full node. In case of censorship, there is a force transaction mechanism that falls back to Bitcoin and guarantees transactions will be included in the next batch.The sequencer is only responsible for ordering and publishing blocks. It can neither steal users' funds nor freeze them thanks to ZK proofs, force transaction mechanism, and on-chain data availability. #### Pre-Confirmations The sequencer's ordering promise is only trusted until the next Bitcoin block. The merkle root of the soft blocks (batch tree) is inscribed in Bitcoin every 10 minutes. After the state root is inscribed, its validity and data availability is asserted inside the zk circuit, preventing any change in the ordering of transactions. This mechanism ensures that ordering of the transactions cannot be changed after it is inscribed in Bitcoin. With this method, Citrea ensures that ordering finality is not delayed until the batch proof while keeping the full data publishing cost as low as possible. For future work, Citrea will introduce a multi-sequencer network, which will reduce ordering trust assumptions to near-zero. #### Decentralized Sequencer Network A single sequencer operating for a rollup is sufficient for security (safety), however it imposes a limit for censorship-resistance, uptime, and fair ordering. In order to prevent any potential issues, Citrea is working towards a solution that significantly reduces risks by allowing multiple sequencers to produce and finalize blocks with sub-second timing. The consensus network between multiple sequencers minimizes the risk of censorship on the L2 level, reducing Bitcoin fallback force transaction count (thus reducing the need for users to force-transact). It also removes the need to trust the sequencer ordering, even it is for a short time, because now ordering is determined and finalized on the sequencer network with sub-second timing. A Decentralized Sequencer Network can further reduce the costs of the rollup because it allows the posting of roots and proofs to Bitcoin less often, as the ordering is guaranteed and finalized on the L2 directly. ### Proof Generation ![](https://923787869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtFU3ZD7rSzMi2uz6wz9W%2Fuploads%2Fa8VW8EC00mwIw2qJqQkz%2Fprover.png?alt=media\&token=6689a5a7-1f20-498b-bb29-5454f5557644)Proof Generation in CitreaCitrea's proof generation mechanism is specialized for Bitcoin and BitVM. Citrea is running on top of a recursion-capable STARK-based zkVM, RISC Zero, and utilizes two different types of proofs: * **Batch Proof:** Batch proofs are produced for every few Bitcoin blocks. The Citrea batch proof circuit is configured to scan Bitcoin blocks for batch root inscriptions via inclusion and soundness proofs, and if any exist, it inputs the L2 batch that results in the batch root and proves the validity of the L2 batch. The proof outputs state difference resulted by the batch, initial and latest state roots, and the blockhash of Bitcoin block scanned. The proof with outputs is inscribed in Bitcoin. * **Light Client Proof:** Light client proofs recursively validate batch proofs and provides a single proof for full rollup history, allowing trustless and instant light clients. Light client proof circuit inputs the previously generated light client proof, an array of batch proofs with their inclusion and soundness proofs, and an array of Bitcoin block headers corresponding to the inscribed batch proofs. The circuit recursively verifies every single batch proof and the light client proof, asserts latest state root of the proof N-1 is equal to initial state root of the proof N. This logic ensures that no state transition is skipped, thus the end result is the same state root with the actual rollup state root. * Light client proofs can be generated at any time by recursively verifying the previous light client proof with the batch proofs. * Light client proofs are broadcasted in the peer-to-peer network and also inscribed in Bitcoin. * Light nodes can listen to the peer-to-peer network or only track the latest Bitcoin headers, and the latest proof they find verifies the full rollup history and provides a trustless access to the state root. The Citrea circuit mainly proves two different pieces of logic; execution and blockspace. During the batch proof generation, both execution and blockspace are proven. During the light client proof generation, blockspace and verification of batch proofs are proven. * **Execution proving:** Citrea runs the state transition function of the rollup, which is slightly broader logic that includes the EVM, inside the zk circuit. The circuit inputs the pre-state of the rollup, the new batch of blocks, and outputs the state difference between the pre and post-state after applying the batch. * **Blockspace proving:** Blockspace proving is a brand new concept used in Citrea. Blockspace proving logic is a custom zk circuit that scans a Bitcoin block, extracts the state roots or Citrea batch proofs and forced transactions from it. In batch proofs it asserts the state root's accuracy and in light client proofs it verifies the batch proofs (if one exists). Bitcoin block scanning inside the circuit is being done by the inclusion and soundness proof given, and checked against the corresponding Bitcoin block header. Citrea merges execution proving and blockspace proving inside a single circuit for batch proofs. Individual batch proofs are only helpful for full nodes. In order to run a light node on batch proof only system, the light node must check every Bitcoin block one by one for proofs, which is not feasible for a light client because of the bandwidth and storage requirements involved.In Citrea, thanks to its light client proofs which apply recursion over batch proofs and blockspace proofs, users have trustless light clients. Anyone with the last few Bitcoin blocks or connection to the peer-to-peer network can extract the Citrea light client proof and be sure that it represents the only valid fork of the chain and validates every state transition since Citrea's genesis block. ### Nodes #### Full Nodes Full nodes in Citrea are the nodes that sync with the sequencer(s) as well as verify the zk proofs. Full nodes are designed for users who need instant confirmations from the sequencer or need the full history of Citrea.A sequencer that produced a block broadcasts the block over a network of full nodes. Full nodes apply the sequencer block to their local state. RPC endpoints can now serve the block data to explorers, wallets, and other applications without waiting for additional zk proving. After a batch of blocks is proven and inscribed in Bitcoin, full nodes extract and verify the proofs. According to the result of the proof they confirm, finalize, or revert the sequencer broadcasted blocks. #### Light Nodes A light node is a node that is designed to fully validate the full nodes' responses using minimal bandwidth and storage requirements. In Citrea, light nodes run next to a Bitcoin light node (SPV) or full node and only need the several latest Bitcoin block headers to trustlessly access the latest light client proof. They can also directly connect to the peer-to-peer network and retrieve the light client proof through the network.Using the state root extracted from the light client proof, Citrea light nodes can validate full node and RPC endpoint responses. With the advancements in light node technology on Bitcoin like ZeroSync header chain proofs, the proofs that verify a chain of Bitcoin block headers thus allow instant sync with Bitcoin headers allowing Citrea light nodes to sync with the rollup near-instantaneously.This improvement significantly reduces the trust on full nodes and boosts decentralization of Citrea with more verifying nodes. Such a light node can also live in another blockchain, which enables trust-minimized bridges with every other smart contract-capable blockchain ecosystem. ### Bitcoin Settlement: Trust-minimized BTC Bridge Citrea is the first Universal L2 that has a trust-minimized BTC bridge.![](https://923787869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtFU3ZD7rSzMi2uz6wz9W%2Fuploads%2Fp7YjERod1NLXJO36418x%2Ftwo-way-peg.png?alt=media\&token=c94058aa-758c-4d9a-af14-8b96df80768a)Trust-minimized two-way peg in CitreaCitrea light client proofs are natively verified in Bitcoin, thanks to BitVM. We have implemented a multi-verifier BitVM setup where an operator is responsible for peg-in and peg-out transactions and verifiers are in charge of checking invalid peg-in and peg-out transactions. Any invalid transaction can be challenged by verifiers. **As long as one verifier is honest, the peg is secure.** This is a great improvement over the existing insecure bridge constructions that mostly depend on the honest majority assumption within a closed or open federation.There are no delays on withdrawals once the proof is finalized on Bitcoin in the optimistic case. The operator does the withdrawals from its own pocket. Later, it claims the pegged-out BTC from the BitVM program with a proof showing that all the withdrawals from the canonical Citrea chain have been done on Bitcoin. If there is any fraud in the process, any verifier among set of N reacts with a fraud proof on Bitcoin, slashing prover's stake and keeping the peg secure. #### What the BitVM Contract Verifies * Recursively-merged Light Client proofs with deposit and withdrawal roots. * Bitcoin Header Chain proof showing the latest Bitcoin block header as well as a merkle tree of all the previous headers (similar to [ZeroSync](https://zerosync.org/) header chain proofs). * Bitcoin SPV proofs showing that all the withdrawals are covered by the operator from its own pocket. In order to reduce the program size committed on Bitcoin (and thus the fraud proof size), all of the above logic is enshrined in two Groth16 circuits. The BitVM program is actually a single Groth16 verifier, hardcoded with the circuit's verifying key.The operator provides the proof off-chain first. If everyone agrees its correct, the on-chain footprint is minimal - N/N signatures. If a verifier thinks there is a fraud, a challenge-response game starts between the verifier and operator. Eventually the loser's deposit gets slashed. If an operator is malicious, it will be removed from the committee and replaced by other pre-determined operator. #### Technical Limitations * Peg-in and peg-out amount is fixed and a relatively large number. * In order to keep the pre-signed tx amount manageable, Citrea will start with a fixed and large amount as peg-in/out amount. * To improve the UX, users can collectively sign PSBTs on Bitcoin to peg-in and also collectively send withdrawal requests on Citrea. * To improve the UX further, Citrea will develop a trustless atomic swap protocol between Bitcoin and Citrea to employ $BTC/$cBTC swaps. The design and architecture of the two-way peg is ready and under heavy development. The two-way peg does **not** require any network change and is trust-minimized. In order to make settlements of Citrea fully trustless, there needs to be opcode change(s). Please refer to the Future Research section for more information. #### BitVM BitVM is a computing paradigm that enables turing-complete smart contracts on Bitcoin. BitVM works using Taproot trees and fraud proofs.The current BitVM implementation is work in progress independently by the BitVM team led by Robin Linus. The Citrea trust-minimized bridge program consists of an operator and verifier software with zk circuits of the bridge. It is built on top of the BitVM implementation by the BitVM team.We acknowledge and thank all BitVM contributors for the efforts. #### Optimistic Verification BitVM is based on fraud proofs, which means it is a protocol that merely verifies the execution of a program using fraud proofs. The whole program is never being executed on-chain. If the result provided by the operator gets challenged by a verifier, the execution gets verified on-chain with a series of challenge-response transactions. If the off-chain result is correct, the on-chain footprint is minimal.Even though the BitVM paradigm is optimistic, Citrea is a ZK rollup that has optimistic settlement. As all the proofs and data are inscribed in Bitcoin, nodes accept proofs and verify them locally. The settlement only happens at checkpoints, which happens every few months. Between checkpoint times, withdrawals are fronted by an operator and later claimed during settlement. # Introducing Citrea: Bitcoin’s First ZK Rollup > original: > > author: Citrea Team Today we introduce Citrea, the first rollup that enhances the capabilities of Bitcoin blockspace with zero knowledge technology. The Bitcoin scalability landscape has long been dependent on solutions that move security and demand off-chain, off-Bitcoin. Citrea is set to change this reality by scaling Bitcoin in its entirety with zero-knowledge proofs, ensuring on-chain verifiability and data availability within the Bitcoin network. This approach makes Citrea the first scaling solution to enable more complex applications without compromising Bitcoin security and changing its consensus rules. ### The Problem with Creating New Blockspace Bitcoin has the most secure, decentralized, and censorship-resistant blockspace. Scaling proposals that create new blockspaces cannot inherit any of these properties of Bitcoin. These proposals or implementations merely offer alternative blockspaces; they do not scale the Bitcoin blockchain. Constructing sidechains with an alternative blockspace competes with Bitcoin in the long term and risks users' funds through insecure bridges and network constructions. #### Bitcoin Blockspace is in High Demand People are demanding Bitcoin for all their on-chain needs because of its security, decentralization, and censorship resistance. Over the past few months, we have observed exponential interest in Bitcoin blockspace, reflected in the fee rates. Whether it is a payment or inscription transaction, people want to get included in the blockspace and are willing to pay for it. Ensuring sustainable participation in the Bitcoin network is vital for its long-term health and security budget, but there is a trade-off: the inevitable exclusion of some transactions due to the high fees and necessary block size limit. It's imperative that Bitcoin scales to include many more complex transactions without changing its core principles. This increasing interest highlights a significant problem with existing scalability proposals: their failure to address the growing demand for inclusion in the Bitcoin blockspace. #### Existing Scalability Proposals Don't Scale Bitcoin Bitcoin has long faced the challenge of handling more transactions and enabling a wider array of applications without compromising its security or core principles. This multifaceted issue has proven difficult to address in its entirety. Some attempts have targeted scaling Bitcoin’s payment throughput, such as Lightning, while others have focused on scaling the functionality of the BTC asset, like sidechains. While the first scaling proposal fell short in bringing programmability to Bitcoin, the latter missed a critical point: the active and effective utilization of the Bitcoin blockchain itself. In the current landscape, the inherent demand for Bitcoin blockchain is being redirected to separate consensus protocols, to sidechains. This approach results in a trade-off — sacrificing Bitcoin’s security and misaligning with its incentives in exchange for lower fees and more use cases for BTC. Consequently, Bitcoin, dominated by sidechains, suffers from scaling solutions that fail to serve its long-term health and incentives in any meaningful way. These solutions, though well-intentioned, do not operate on the Bitcoin blockchain, do not contribute to Bitcoin security, and ultimately, do not scale the Bitcoin blockchain as needed. Once again, a demand for Bitcoin moved to a sidechain is not a demand for Bitcoin anymore. #### Scale the Bitcoin Blockspace Truly scaling Bitcoin requires establishing a symbiotic relationship between Bitcoin and the scaling solution. The scaling solution must actively and efficiently utilize Bitcoin blockspace to scale the demand and increase its expressivity and throughput without changing its protocol. **Scaling Bitcoin blockspace is the only way to transact with Bitcoin security.** Any other alternative cannot inherit full Bitcoin security. **The most secure and incentive-aligned way to scale Bitcoin blocks is to shard the execution with on-chain verifiability and data.** The only way to achieve easy verifiability by Bitcoin is through leveraging zero knowledge or fraud proofs. As fraud proofs require vast amounts of data to be written on Bitcoin, ZK proofs are the most efficient way to verify the validity of execution inside Bitcoin within the block size limit. ZK Rollups create an execution shard and batch multiple transactions on the shard while verifying them on-chain with a succinct mathematical proof as well as minimal essential data to reconstruct the state. This method enables ZK Rollups to utilize underlying blockspace verifiably in the most efficient manner, scaling the L1 with its full security. ### Enter Citrea: Bitcoin Security at Scale Citrea is the first rollup on Bitcoin that enables greater expressivity and increases the utility of Bitcoin blockspace without ever leaving Bitcoin. Citrea keeps the demand for Bitcoin within its network and ensures that Bitcoin Network serves as a data availability and settlement layer for Citrea transactions. Citrea requires no consensus changes to Bitcoin. Citrea represents a significant milestone for Bitcoin: **it is the only execution layer on Bitcoin that settles on Bitcoin, the first ZK proof verification, and the first universal L2 verification inside Bitcoin.** Citrea’s mission is to advance Bitcoin into its next phase, foundation for the world's financial infrastructure, where developers can build everything on Bitcoin. Citrea batches thousands of transactions, processes them in zkVM, and produces a succinct validity proof asserting the correctness of the execution as well as the output data. For the first time in Bitcoin history, Citrea validity proofs are inscribed and natively verified within the Bitcoin blockchain. Citrea comes with a native ZK proof verifier smart contract on Bitcoin L1, built in BitVM. **Unlike monolithic sidechains, Citrea creates a modular world for Bitcoin with its execution shard that keeps the settlement and data availability on-chain, on-Bitcoin.**

Citrea: A Modular Touch to Bitcoin

Citrea creates consistent fee revenue for miners through data availability, trustlessly scales BTC beyond Bitcoin with validity proofs, and allows developers to build anything on its EVM equivalent execution shard. #### Scaling Bitcoin Security Citrea is the only execution layer on Bitcoin that actually settles on Bitcoin. Every transaction occurring on Citrea is fully secured by zero-knowledge proofs and verified by Bitcoin. The execution environment of Citrea is trustless with respect to Bitcoin and is accessible to all participants of the Bitcoin Network. As a result, Citrea ensures that it satisfies Bitcoin equivalent data availability, censorship resistance, and re-org resistance guarantees. 1. **Bitcoin as App Bedrock:** Citrea's mission is to build a programmable liquidity layer on top of the most secure and decentralized blockchain, Bitcoin. We believe Bitcoin blockspace must be used to settle all kinds of financial activities efficiently such as trustlessly buying BTC, leveraging BTC, or lending BTC. Most existing meta protocols attempting to provide these features are trusted and inefficient. Citrea is the most efficient and secure platform to build applications on Bitcoin. 2. **Bitcoin Settlement and Trust-Minimized Two-Way Peg:** For the first time in Bitcoin history, a universal L2 is settled on Bitcoin, enabling the first ever universal trust-minimized two-way peg. Prior to Citrea, Layer 2 solutions relied on the honest majority assumption of a multi-signature, such as open or closed federations. With Citrea, the validity proofs are verified in Bitcoin using BitVM paradigm, as long as one network participant is honest. BitVM is based on fraud proofs, meaning that ZK proofs of Citrea are being optimistically verified on the Bitcoin network. In the future, a ZK proof verifier opcode will enable a fully trustless two-way peg mechanism. 3. **EVM Equivalence:** Building Citrea with full EVM equivalence enables all the EVM developers to build on Bitcoin, effortlessly. Citrea ships a Type 2 zkEVM, fully equivalent to EVM, built using RISC Zero. Citrea is not limited to a single VM by design, and can adopt new VMs such as WASM VM in the future thanks to its modular architecture. ### What’s Next? #### Internal Devnet is Enabled We are running Citrea Devnet with a synthetic native BTC internally for critical infrastructure integrations and tests. Trust-minimized two-way peg with BitVM is under heavy development. **We welcome infrastructure partnerships.** If you are an infrastructure provider interested in partnering with Citrea, please get in touch with us at: #### Revealing The First Trust-Minimized Two-Way Peg **Keep an eye out for the reveal of Citrea's trust-minimized peg design.** We will announce our bridge design and open-source our codebase in the coming weeks! #### Public Testnet **We are making rapid progress.** We’ve been working hard on building a robust testnet for the first rollup on Bitcoin. We’re excited to share more in the coming months. Keep an eye on our [socials](https://twitter.com/citrea_xyz?ref=blog.citrea.xyz) and [blogs](http://blog.citrea.xyz/?ref=blog.citrea.xyz). #### Build with Citrea **Our developer contact form opens today.** Citrea has been incubated by [Chainway Labs](https://twitter.com/chainway_xyz?ref=blog.citrea.xyz) for over a year, and is well-funded. If you’re interested in building with us or deploying on Citrea, please get in [touch](https://citrea.typeform.com/buildwithus?ref=blog.citrea.xyz). Check out our [documentation](https://docs.citrea.xyz/?ref=blog.citrea.xyz) to explore Citrea’s technology. ### Making Bitcoin the Foundation for World’s Finance Citrea’s vision is to build scalable infrastructure that advances Bitcoin into its next phase, the foundation for the world’s finance. To achieve this vision, we believe that Bitcoin blockspace must be enhanced to include more transactions and offer more expressivity and features without changing its consensus rules. Bitcoin, with its security, decentralization, and censorship resistance, is perfectly positioned to serve as the foundation for the world’s finance. Recognizing this potential, Citrea builds on these strengths and makes Bitcoin a base layer for a dynamic ecosystem of DeFi, gaming, NFTs, and more. Citrea will only get bigger and more advanced with its modular world anchored on Bitcoin. We are incredibly bullish on our vision and committed to working towards it. On Bitcoin, For Bitcoin. ### Get Ready Join the community and follow us on Twitter to be an early adopter. You don’t want to miss any updates from Citrea! * Join [Discord](https://discord.gg/citrea?ref=blog.citrea.xyz) * Follow [Twitter | X](https://twitter.com/citrea_xyz?ref=blog.citrea.xyz) ### Acknowledgments We would love to thank Cem Ozer, who initially pushed us towards committing to building the first rollup on Bitcoin. Since then, Citrea has evolved to a larger vision with the invention of BitVM by Robin Linus. We thank Ekram Ahmed and CJ Huntzinger for providing their invaluable expertise through the branding and marketing process. We thank Emre Tekisalp for helping us to find our way along our journey. # ZKBase **ZKBase** [@ZKBaseOfficial](https://twitter.com/ZKBaseOfficial) Layer2 for Bitcoin & Ethereum; Building innovative solutions based on ZK technology to inject new vitality into the Bitcoin and Ethereum networks. # ZKByte: A Trustless Bitcoin Layer2 Scaling Solution based on Zero Knowledge and BitVM > original: > > author: ZKBase The primary objective of this design is to establish a Layer 2 network tailored specifically for the Bitcoin blockchain. The Layer 2 network for BTC is strategically crafted to meet the surging demand for faster and more efficient transactions within the Bitcoin ecosystem. This is achieved by offloading certain transaction processing tasks from the main blockchain, aiming to alleviate congestion and substantially reduce the time and resources required for transaction confirmations. Recognizing the inherent limitations in the computing capabilities of the Bitcoin Virtual Machine (VM), our design uses BitVM, which demonstrates the potential for executing smart contracts between two parties. Leveraging a challenge and response scheme, BitVM showcases a novel approach to enhance the programmability of the Bitcoin network, overcoming traditional constraints. To enhance the security and integrity of the Layer 2 network, state verification is facilitated through the integration of Zero-Knowledge Proof technologies. These advanced cryptographic techniques allow Layer 1 to efficiently verify the states of the Layer 2 network without compromising the privacy and confidentiality of the underlying transactions. 0\. Architecture The Layer 2 blockchain adopts an account model. The entire blockchain’s status is proven through zkVM, based on the Halo2 proving system. The Layer 2 state is synchronized with the Bitcoin network, and all Layer 2 states are verified by the Zero-Knowledge Proof (ZKP) verifier implemented by BitVM. One UTXO is used to trace all Layer 2 states. Additionally, a trusted oracle is employed to ensure that only the lock/unlock scripts of input/output UTXOs follow the Layer 2 protocol.
1\. Layer 2 Committee & Trusted Oracle A selected group of users forms the Layer 2 committee responsible for monitoring the overall health of the Layer 2 network. In case of protocol issues, the committee can intervene to stop the protocol and safeguard all users’ assets. The trusted oracle is crucial for validating the correctness of input/output UTXOs and scripts 2\. Layer 1 to Layer 2 A single taproot address is created on the Bitcoin network to represent the Layer 2 protocol. When a UTXO is created and transferred to the taproot address, the corresponding UTXO is effectively ‘moved’ from Layer 1 to Layer 2. Protocol or committee accounts exclusively handle the ‘transfer’ of all ‘deposited’ UTXO assets.
3\. Blocks Syncing to Layer 1 All Layer 2 network states are synced to Layer 1 in the form of blocks. For one block, the following information should be provided: transactions in one specific block new accounts’ state with those applied transactions new UTXOs for the current block state (always ready even if protocol is broken) block information of Bitcoin network zero-knowledge proof (proving the state transition from last block to current block is correct) All those states in Layer 1 is recorded in one UTXO transaction history.
3.1 More about proof Zero-knowledge proof is employed to verify the correctness of the Layer 2. The proof tries to prove: Block Transactions of Layer 2 are signed correctly. New state of all accounts are handled correctly. All deposits until one specfic block of Layer 1 are handled correctly. For the current state, all UTXO distributions are created correctly. 3.2 Block information Challenge To ensure the correctness of specified block information in Layer 1, a challenge and response scheme is utilized. Provers can demonstrate the accuracy of block information by indicating the presence of N more blocks after a specific block within a locked time period. 3.3 ZKP Circuit and BitVM Enhancement As illustrated in BitVM paper, ZKP proof verfication can be expressed as one binary circuit, which can be challenged by two parties. With pre-signed transactions, challenges can be sent to get bit commitments of the circuit. If 0 and 1 are exposed by challenges, challenger wins. To use BitVM to verify ZKP verification, two things should be paid attention to: same binary circuit commitments should be used once. That’s to say, if same circuit comments used for many blocks, 0 and 1 of one bit commitment may be exposed. For ZKP verificaion, beside circuit satisfaction, “public input” should be checked too. To handle these two shortcomings, for each block of Layer 2, one unique binary circuit is created and the “public inputs” are fixed. Bitcoin Scripts are used to handle Public Input hashing and checking. And the correct public input bit commitments are checked by trusted oracle In terms of circuit satisfaction, any member within the committee has the ability to raise challenges.
4\. Layer 2 to Layer 1 Assets can be moved from Layer 2 to Layer 1 through two methods: withdrawal and force-withdrawal. Withdrawal transactions are triggered from Layer 2, and ZKP circuits ensure transaction handling as expected. Force-withdrawal transactions are initiated from the Bitcoin network. 4.1 Withdraw & Force-withdraw transaction Withdrawal transactions, triggered from Layer 2, are verified using ZKP circuits to ensure proper transaction handling. Force-withdraw transactions, initiated from the Bitcoin network, must be included in the next block state update. 4.2 UTXO distributions When the state of a block is updated, UTXO distribution is synchronized. In the event of a protocol stop, all UTXOs can be applied to ensure the safety of all user assets. And among those UTXOs, only withdraw or force-withdraw UTXOs are signed by protocol. 5\. Layer 2’s Exit Once ZKP proof is NOT verified, committee must halt and exit the protocol. If protocol stops, committee signed all UTXO distributions specified in latest block state from Layer 2. With the signatures, a user can exit Layer 2 without any loss.
Reference 1. BitVM: 2. Bitcoin Whitepaper: 3. Halo2 explanation: / ZKBase Team # Bitstake # Introducing Bitstake: A proof of stake bridge based on BitVM > original: > > author: [@lightcoin](https://lightco.in/) *Edit 2024-02-14: An earlier version of this post characterized the Bitstake protocol as “permissionless” to participate in as an active staker.* [*Wei Dai*](https://wdai.us/) *pointed out that because 1-of-N active stakers are needed to enforce correct state transitions, at least 1-of-N is also needed to challenge censorship of staker set updates. The post has been updated to reflect this.* In late 2023, Robin Linus published the [BitVM whitepaper](https://bitvm.org/bitvm.pdf), taking the bitcoin developer community by storm. “Compute anything on bitcoin”, the whitepaper promised. Robin and other developers in the BitVM community are now actively working on building a trust-minimized [bitcoin bridge](https://lightco.in/2020/08/02/bitcoin-pegs/) using BitVM. One of the bridge variants that has been designed so far is what I am calling a “permissioned optimistic bridge” that relies on a 1-of-N (+ [miners won’t steal](https://lightco.in/2022/06/15/miners-can-steal-2/)) trust model. In the permissioned optimistic bridge model, there is a permissioned group of N bridge participants. One participant assumes the role of “prover” aka “operator” and N-1 participants assume the role of “verifier” aka “watchtower”. The role of the operator is to process withdrawal requests from users, and the role of the watchtowers is to keep the operator honest. Every time the operator initiates a withdrawal, this starts a “challenge period” during which the withdrawal can be challenged by a watchtower. If the operator tries to make an invalid withdrawal from the bridge, then any one of the watchtowers can submit a challenge transaction on bitcoin to kick off the challenge process. If the challenge is successful, then the withdrawal is cancelled and the operator has some collateral slashed by the BitVM program. A more complete description of the permissioned optimistic bridge protocol can be found [here](https://github.com/BitVM/BitVM/blob/main/docs/sidechain_bridges.md#outline-optimistic-trust-minimized-btc-bridge-with-bitvm). This post introduces Bitstake, a variant of the permissioned optimistic bridge that uses a proof of stake protocol for bridge participant selection. The Bitstake protocol combines ideas from the [Nomic bridge](https://gist.github.com/mappum/da11e37f4e90891642a52621594d03f6#checkpoints) with the BitVM permissioned optimistic bridge. It can also be thought of as a more secure version of [StakePeg](https://lightco.in/2021/01/25/stakepeg/). The purpose of introducing proof of stake to this bridge model is to provide a way for anyone to participate in the bridging process, provided they have enough stake to meet the qualification threshold and 1-of-N active stakers is willing to challenge attempts to censor staker set updates. Here is a step by step explanation of how the protocol works: 1. The Bitstake implementer defines the core logic of the Bitstake BitVM program. This includes details about the chain that BTC is being bridged to (the “destination chain”) and the operation of the bridge itself, including the asset to be used as the staking asset for the bridge. The staking asset could be BTC or any other asset. Note: If a new purpose-specific staking asset is used (perhaps created via proof of burn, as in StakePeg) then users could socially slash the stakers if they all become malicious. 2. The initial users who want to participate in the bridge protocol (the initial “stakers”) coordinate to construct the Bitstake address using BitVM. This initializes the state on the destination chain with the stake that should be allotted to each initial staker. The stakers receive staking power proportional to the amount of the staking asset that they have deposited/received and staked. Anyone can stake, but the active staker set participating in the bridge protocol is limited to the top *N* stakers by staking power (the aforementioned “qualification threshold”). This limit is enforced by the BitVM program and set by the implementer based on their assessment of bitcoin script size limits and practical MPC e.g. [Musig2](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki) coordination limits. See how the Nomic [reserve wallet](https://gist.github.com/mappum/da11e37f4e90891642a52621594d03f6#reserve-wallet) provides canonical ordering based on voting power for an in-depth explanation. 3. With the initial stakers set up, the bridge is now ready to start accepting deposits from users. Users send BTC to the Bitstake address and are credited with an equivalent amount of BTC on the destination chain. They can then use BTC on the destination chain according to whatever logic is supported by the chain’s consensus rules. 4. From time to time, stakers will come and go and modify their stake. When this happens, the BitVM program enforces that the next time there is a transaction spending from the Bitstake address, that the new Bitstake address that the change must be sent back to must be constructed with the most up-to-date staker set according to their current staking power. If the destination chain is a rollup, this staker rotation could happen as often as every rollup block, since every rollup block requires a state update transaction on bitcoin. See how the Nomic [checkpoint transaction](https://gist.github.com/mappum/da11e37f4e90891642a52621594d03f6#checkpoints) works for an in-depth explanation. 5. Censorship of stakers (preventing them from staking or modifying their stake) can be circumvented if the destination chain supports forced inclusion. Using forced inclusion, a staker or would-be staker can confirm a transaction on bitcoin that will guarantee that the transaction gets confirmed in the next block (or some block in the near future) on the destination chain. If the transaction is still excluded, then the destination chain will halt. This makes censorship potentially very costly for the attacker. Any 1-of-N active stakers can prevent censorship of new stakers by challenging state transitions that exclude valid staker set updates. The rest of the protocol works like the 1-of-N permissioned optimistic bridge mentioned earlier. One of the stakers becomes the operator, and the rest are watchtowers. Users submit withdrawal requests to the operator, and the watchtowers keep the operator honest, etc etc. As mentioned before, the main benefit of Bitstake is that there is now a way for anyone to become a participant in the bridge protocol, changing bridge operation from a fixed operator set to a dynamic staker set that only needs 1-of-N permission from existing active stakers to join the active staker set, while also adding penalties that can be enforced by the destination chain even if all active stakers misbehave (this feature is only available if a purpose-specific staking asset managed on the destination chain is used). The staker set could also be used to provide other services to the destination chain, such as block production, validity proving, and data availability. The main risk is that by allowing anyone to participate in the bridge, it could become dominated by a well-funded attacker. If the attacker gains control of all staker slots above the qualification threshold then they could steal all funds from the bridge, and they only risk their stake being slashed if a purpose-specific staking asset is used. It follows that for maximum security, the total value of active stake should comfortably exceed the total value of BTC held in the bridge. Another risk is that, because anyone can become a staker, there is possibly a higher risk that one of the stakers may be [willing to collude](https://twitter.com/lightcoin/status/1756816481705242789) with a malicious hashpower majority to steal from the bridge. See my [previously cited post](https://lightco.in/2022/06/15/miners-can-steal-2/) for an empirical analysis of this risk. ### Proof of work variant An alternative to proof of stake is, of course, proof of work. A user who wants to be a (Bitwork?) bridge participant could submit proofs of work to a smart contract on the destination chain, and they would receive signing power in the bridge proportional to the total difficulty of the proof of work they have provided. The proof of work-based signing power would be socially slashable, like a purpose-specific staking asset, by switching the source of signing power to a different smart contract (or halting the chain altogether). The rest of the protocol would work as described above. The main tradeoff for using proof of work is that this is a sunk cost, whereas in proof of stake users may be able to sell their stake to someone else if they want to exit the protocol. ### Acknowledgements Shout outs to [Robin Linus](https://robinlinus.com/) for providing feedback on a draft of this post and for inventing BitVM, [Matt Bell](https://keybase.io/mappum) for his work on the Nomic bridge, [gnar](https://twitter.com/mitche50) for independently coming up with a similar idea at the same time. *** *Email is probably the most popular decentralized messaging protocol, and I expect it to be around for a while. Add yourself to my email contacts if you would like to stay in touch! I will never sell, rent, or share your email address.* # 2025.3.10 - 2025.3.16 2025.3.16\ BitVM Official Project Update: Removed unused code in Blake3\ 2025.3.14\ BitVM Official Project Update:\ Added CI for Code Format \ Enabled CI for running resource-intensive unit tests separately\ # 2025.3.3 - 2025.3.9 **2025.3.7** Bitlayer released its February monthly report: Bitlayer: The first BitVM, powering Bitcoin DeFi. **2025.3.6** BitVM official project update: BitVM removed old code for audit purposes. **2025.3.5** Fiamma @fiamma\_labs provides a trustless Bitcoin bridge to BOB @build\_on\_bob via BitVM2, enabling secure and trust-minimized Bitcoin deposits and withdrawals in the testnet environment. **2025.3.4** Five projects announced their integration with BitVM through Fiamma @fiamma\_labs: @babylonlabs\_io @build\_on\_bob @arbitrum @zksync @monad\_xyz **2025.3.3** Bitlayer @BitlayerLabs is bringing its trust-minimized BitVM bridge to Arbitrum (@arbitrum)! This integration will unlock Bitcoin liquidity between both Layer 2 blockchains. # 2025.2.24 - 2025.3.2 **2025.3.2** BOB @build\_on\_bob launched the BitVM Bridge on the public testnet and co-founded the BitVM Accelerator with ZeroSync, Babylon, and other organizations. **2025.3.1** Bitlayer @BitlayerLabs has formed a strategic partnership with Base, Starknet, Arbitrum, Sonic, and Plume Network to jointly drive the first real-world application of BitVM. **2025.2.28** BitVM official project update: Fq12 optimization has been merged into the main branch, with an expected optimization of Chunk count to around 400. **2025.2.26** Bitlayer has officially donated the ETH-Denver-2025-DEMO to the BitVM community (). This demo showcases the latest research and development achievements of the BitVM project and presents the first real-world use case: the complete BitVM Bridge protocol process. * Demo link: **2025.2.25** Bitlayer has donated the BitVMNet testnet to the BitVM community. This testnet is built on Signet and has non-standard transaction inclusion enabled by default. It is designed to facilitate end-to-end testing for BitVM, accelerating the deployment and refinement of the testnet. * BitVMNet link: # 2025.2.17 - 2025.2.23 ## 2025.2.18 BitVM has completed the end-to-end demo integration test, On-chain record details: ![](https://sigweb3labs.sg.larksuite.com/space/api/box/stream/download/asynccode/?code=NjI4NWY3YjJjOTI4ZTZhMmQ2N2YxNGZmYzZkNzdkYjZfYThlS0oyRUFIRTAzZVRVeFhUclVZdWVUb1BBOUh1dTRfVG9rZW46Wk9RWWJVMkYwb1pSbE14YU1qaGxlbDhIZ1VkXzE3NDA1NTI2Njk6MTc0MDU1NjI2OV9WNA)![](https://sigweb3labs.sg.larksuite.com/space/api/box/stream/download/asynccode/?code=NjY5YmFlNTcyZDViN2IyMGFjODRmNWU2ODBhMDJkYjFfOTZIekdkdktyWGx5WGRUU1JKaDRCZU9jWlFEWDVzQlZfVG9rZW46U2c1Y2J6bHU1bzRrM2J4ZmplbGxyWlF1Z1VnXzE3NDA1NTI2Nzc6MTc0MDU1NjI3N19WNA) # 2025.2.10 - 2025.16 ## 2025.2.16 Bitcoin Magazine published an article: "Bitlayer's technological breakthrough based on BitVM may bring about a second wave of revival for the Bitcoin ecosystem." Based on the BitVM protocol, Bitlayer launched the first version of the Finality Bridge testnet, marking an important step towards the revival of Bitcoin or Bitcoin "Season 2." Original text: ## 2025.2.15 Jose Storopli [@sxddnt](https://x.com/sxddnt) Post explanation of "BitVM: How to bridge using 1-of-N trust assumptions" # 2025.1.20 - 2025.2.2 ### 2025.1.30 BitVM Official Project Update: The Disprove logic, integrated by Bitlayer and ElementLabs, has been fully merged into the BitVM main branch BitVM Official Project Update: Optimized the u4-byte hash, allowing it to process messages up to 1024 bytes. This reduces script size and maximum stack usage when computing fp6 or fp12 elements. It has not yet been merged into Chunker
### 2025.1.24 BitVM Official Project Update: Optimized and cleaned up Bitcoin script macro-related branches # 2025.1.13 - 2025.1.19 ### 2025.1.17 Bitlayer @BitlayerLabs Unveiled Finality Bridge – a groundbreaking trust-minimized bridge for Bitcoin! inality Bridge empowers users to securely mint BTC into YBTC with minimal trust assumptions, enabling participation in DeFi sectors like liquidity mining, staking, and lending across the Bitlayer ecosystem and beyond. ## 2025.1.14 BitVM Official Project Update: Manish optimized the check in the G2 elliptic curve group BitVM Official Project Update: Manish's optimization of multi-scalar multiplication (MSM) using the GLV algorithm has been merged # 2025.1.6 - 2025.1.12 ## 2025.1.8 BitVM Official Project Update: Bitlayer has fixed a security issue in BitVM by using commitments to ensure the consistency of precomputed parameters.
## 2025.1.7 BitVM Official Project Update: Bitlayer has partnered with Element Labs to adapt the Chunker in the ZKP verifier to the bridged transaction graph, enabling seamless operation of the entire BitVM. This work aims to prepare for the release of the BitVM testnet.
## 2025.1.6 BitVM Official Project Update: Alpen Labs submitted a PR , aiming to reduce the number of chunks used in the existence check script for points in the G2 group. # 2024.12.30 - 2025.1.5 ### 2025.1.3 BitVM Official Project Update: Alpen labs @AlpenLabs submitted PR , which was merged to fix the consistency check of the same hint appearing in different locations.
### 2025.1.2 BitVM Official Project Update: Alpen labs @AlpenLabs submitted PR , which was merged to add checks for hint points within groups, ensuring the correctness of the hints. # 2024.12.23 - 2024.12.29 ## 2024.12.24 Manish submitted a PR to optimize MSM, reducing the number of hashes from 80 to 16. Mukesh submitted a draft PR to optimize the blake3 hash. In addition to statistics on stack usage and script size under different parameters, we look forward to future optimizations for chunks. # 2024.12.16 - 2024.12.22 ### 2024.12.21 Bitlayer @BitlayerLabs has joined the BitVM Alliance. [https://bitvm.org/![](https://sigweb3labs.sg.larksuite.com/space/api/box/stream/download/asynccode/?code=ZDNlMTZmOTEzYjU0OWM2OTg5YjIzOTkxZGY5OTY5MTlfVW42RktjV1JUVXFlcldFTFI5R25wNXNHUXF6ZXVTS1lfVG9rZW46S29oeWJibzhnb0I3WXh4WW9JcWxqRmtmZzhjXzE3MzUwNDAwNDQ6MTczNTA0MzY0NF9WNA)](https://bitvm.org/) ### 2024.12.20 BitVM Official Project Update: The BitVM repository has merged the inverse algorithm on the limited expansion domain, saving one chunk.
### 2024.12.19 BitVM Official Project Update: The Bitlayer @BitlayerLabs research team submitted a fix for the issue where non-fixed-point precomputations were inconsistent across different chunks.
### 2024.12.18 BitVM Official Project Update: The BitVM library has merged two PRs from Alpen Labs @AlpenLabs. [https://github.com/BitVM/BitVM/pull/155
](https://github.com/BitVM/BitVM/pull/155) ### 2024.12.17 Fiamma @fiamma\_labs published BBBB Blog 001: Security Analysis. The BBBB blog series will focus on security: 1. Asset Security: BTC always belongs to you. 2. PEG-IN: Trustless minting of mamaBTC on sidechains. 3. PEG-OUT: Ensuring secure withdrawals through the challenger protocol in BitVM2. \ Dive into BBBB Blog 001: Security Analysis now! # 2024.12.9- 2024.12.15 ## 2024.12.13 BitVM merged the Citrea [@citrea\_xyz](https://t.me/citrea_xyz) team's PR , modifying the alpha and bias hint values for functions like hinted\_check\_double and hinted\_check\_add to be replicated across multiple functions, eliminating the need to provide them separately. ## 2024.12.11 1 BitVM officially merged the Bitlayer [@BitlayerLabs](https://t.me/BitlayerLabs) team's PR . 2 Symbolic [@symbolicvc](https://t.me/symbolicvc) and [@nubit\_org](https://t.me/nubit_org) collaborated on a research report titled "A Deep Dive into BitVM." The research explores why BitVM represents a groundbreaking approach to execution on Bitcoin and details its future development. ## 2024.12.10 The improvement of the README documentation issue was proposed at the BitVM Alliance meeting. The Bitlayer [@BitlayerLabs](https://t.me/BitlayerLabs) team provided information about the main folders in the code repository. # 2024.12.2- 2024.12.8 ### 2024.12.6 BitVM Official Project Update: BitVM fixed an error in the off-chain checker written based on Algorithm 5 in "On Proving Pairing." Previously, when the accumulator was a cubic residue, it caused an error in the calculation of wi. This update addresses the issue.
### 2024.12.5 Bitlayer @BitlayerLabs released maintenance version v1.1.6, and all nodes are advised to upgrade promptly. Bitlayer is The First Bitcoin Layer2 based on Bitcoin finality
### 2024.12.4 Fiamma @Fiamma\_Chain completed a $4 million seed round of financing.Fiamma Bridge, the first trust-minimized Bitcoin cross-chain bridge based on BitVM2, is now live on the Alpha testnet. It achieves secure and practically trustless cross-chain interactions with Bitcoin for the first time, without relying on complex centralized intermediaries or multisig setups.
### 2024.12.3 BitVM Official Project Update: BitVM resolved the issue of the point at infinity being used as input for the affine\_add and affine\_double functions, which previously did not account for the point at infinity in affine representation. \ BitVM Official Project Update: Lukas reported an issue involving abuse of the EQUALVERIFY script in the current algorithm. A fix is in progress. [https://github.com/BitVM/BitVM/issues/143
](https://github.com/BitVM/BitVM/issues/143) ### 2024.12.2 BitVM Official Project Update: The Bitlayer research team fixed a pairing calculation error in the BitVM project, which could have allowed malicious challengers to succeed under any circumstances. # 2024.11.25 - 2024.12.1 ## 2024.11.29 \ BitVM Official Project Update: BitVM library has merged element labs' Integrate CLI and Winternitz Commit Logic to Client based on #131 + #134 #138(), integrating CLI and Winternitz Commit logic. ## 2024.11.28 \ Starkware @StarkWareLtd published a blog explaining how to build a Bitcoin bridge using the OPCAT-based sCrypt language: ## 2024.11.27 \ BitVM Official Project Update: BitVM merged BitVMX team's New Blake3 Optimization #136(), optimizing Blake3\_u4 from 75.6kb to 68.7kb, and reducing the stack size from 671 to 657. ## 2024.11.26 \ Nubit @nubit\_org, in collaboration with ZeroSync, Alpen Labs, Citrea, and other partners, launched the BitVM IDE, a tool for integrating Zero Knowledge Proofs (ZKP) development and validation on Bitcoin. \ This tool allows developers to experience the entire process of writing Zero Knowledge circuits and directly validating ZKPs on the Bitcoin network, significantly reducing the development complexity for Bitcoin and proving a viable new path for trustless, privacy-preserving application development. ## 2024.11.22 \ Fiamma Bridge Alpha Testnet launched @Fiamma\_Chain. Fiamma Bridge is a Bitcoin bridge built using the BitVM2 framework, aiming to connect diverse ecosystems to Bitcoin in a trustless and efficient manner. This allows securely minted, tokenized BTC backed directly by Bitcoin across multiple chains, including BTC Layer 2s, staking and restaking protocols, Ethereum, Solana, and more.\ # 2024.11.18 - 2024.11.24 ## 2024.11.19 **Galaxy** @willnuelle shared a post explaining the economic mechanism of **BitVM**: * The post focuses on the impact of three economic factors on user fees: transaction fees, BTC risk-free interest rates, and operator earnings. * The conclusion is that due to the challenge period, the staking yield of the operator becomes the primary factor influencing user fees. * For example, assuming a 14-day challenge period and a 10% annualized staking yield, the user fee would be approximately 0.38%. # 2024.11.11 - 2024.11.17 **2024.11.12** BitVM Official Project Update: Optimized the verification algorithm for Winternize signatures, improving the efficiency of BitCommitment. This PR has been merged. \ **2024.11.11** BitVM Official Project Update:The Bitlayer @BitlayerLabs research team has implemented the chunker component of the Groth16 verifier, marking the official availability of SNARKs in the BitVM bridge. This PR has been merged. # 2024.11.4 - 2024.11.10 ### 2024.11.7 \ [Fiamma Chain @Fiamma\_Chain](https://x.com/Fiamma_Chain/status/1854512465448681979) opens applications for Devnet Validators. As a validator, you will become the guardian of transactions and the maintainer of the PoS chain for Fiamma's verification layer, which is directly secured by the Bitcoin network via BitVM2.\ [Fiamma @Fiamma\_Chain](https://x.com/Fiamma_Chain/status/1854512465448681979) is a verification network specializing in zero-knowledge (ZK) proofs, dedicated to providing a secure, decentralized, and economically efficient solution for universal blockchain integration. ### 2024.11.6 \ **BitVM official project update:** The [Bitlayer @BitlayerLabs](https://github.com/BitVM/BitVM/pull/129) research team has implemented the chunker for the Groth16 verification program, marking the official availability of SNARKs in the BitVM Bridge.\ Bitlayer is the first Bitcoin Layer2 solution based on Bitcoin finality. ### 2024.11.5 \ **BitVM official project update:** Just-erray optimized the Winternize signature for 20-byte, 32-byte, 128-byte, and 256-byte cases. [Details here](https://github.com/BitVM/BitVM/pull/127). ### 2024.11.4 \ [Starkware @StarkWareLtd](https://x.com/StarkWareLtd/status/1853437746171478221) optimized the Bitcoin script's SHA256 algorithm, reducing the opcode count from approximately \~296K to \~211K (a \~28% reduction). # 2024.10.28 - 2024.11.3 ## 2024.11.3 BitVM Official Project Update: Merged the PR submitted by the Fiamma team @Fiamma\_Chain feat: implement the g2\_subgroup check #125[ https://github.com/BitVM/BitVM/pull/125](< https://github.com/BitVM/BitVM/pull/125>), which fixes the G2 subgroup check bug. ## 2024.10.31 YuFeng @captain8299 from Nubit @nubit\_org has completed the formal verification of the BitVM project ## 2024.10.29 BitVM Official Project Update: Merged the PR from the Bob team @build\_on\_bob feat: optimize winternitz #121, , reducing the winternitz script size from 26.9375 bytes/bit to 26.1125 bytes/bit, saving 3 opcodes per digit. \ BitVM Official Project Update: Merged the PR from the Nubit team @nubit\_org feat: Add helper functions to use signatures as witness #123, , adding functions with the suffix \_witness to use signatures as witness data. # 2024.10.21 - 2024.10.27 ## 2024.10.26 Official BitVM Project Update: Several corner cases for `u32_compress` have been fixed. ## 2024.10.22 1. Official BitVM Project Update: It has been clarified that the BitVM repository will adopt the MIT license. 2. ZeroSync @ZeroSync\_ announces the formation of the BitVM Alliance! We will work together to deliver the first BitVM bridges by the end of the year. Stay tuned!
3. Bitlayer [@BitlayerLabs](https://x.com/BitlayerLabs) In continuation of our previous research on STARK, the Bitlayer research team has conducted a deep dive on the Binius STARK proof system. Our findings are as follows: * Previous STARK systems (252, 64, 32-bit) improved the encoding process yet continued to waste space. Binius employs compact bit-level operations, potentially positioning it as the next-generation STARK. * Binius boosts efficiency with binary field arithmetic, enhanced HyperPlonk checks, and small-field polynomial commitments. * Further optimization in binary multiplication, ZeroCheck, SumCheck, and PCS may increase speed and reduce proof size. For details, see Dr. Lynndell's ([@lynndell11](https://x.com/lynndell11)) latest article. [https://blog.bitlayer.org/Binius\_STARKs\_Analysis\_and\_Its\_Optimization/](https://t.co/s5PWMqbnYg)
# 2024.10.14 - 2024.10.20 ## 2024.10.20 Bitlayer @BitlayerLabs has raised $25 million to bring Finality to the Bitcoin ecosystem. Over 300 decentralized applications (dapps) have already been deployed in the Bitlayer ecosystem, with the total value locked (TVL), transactions, developer community, and user base continuing to grow and flourish. Bitlayer is the first Bitcoin Layer 2 project based on Bitcoin Finality.
## 2024.10.19 Official BitVM project update: Blake3 code optimization, unifying the u32 and u8 versions. ## 2024.10.16 Official BitVM project update: According to the whitepaper, a disprove transaction should require pre-signing for each tapleaf in the taptree formed by the disprovescript. This is because, in addition to the logic of the disprove script, an n-of-n signature (a characteristic of BTC transactions) is also required.
In fact, by reviewing the implementation in the BitVM repo, it was found that it has actually been changed to the following structure: the n-of-n signature and the disprovescript have become two separate inputs. This way, the n-of-n signature no longer needs to account for each tapleaf in the taptree, significantly reducing the number of pre-signing operations required.
## 2024.10.14 Taproot Wizard @TaprootWizards and mempool @mempool have collaborated to launch a new version of mempool. Link: # 2024.10.7 - 2024.10.13 ## 2024.10.12 BitVM official project update: Bitlayer @BitlayerLabs researcher dylanCai9 optimized the MSM in affine coordinates based on the hint version, reducing the hint-based groth16 verifier from 1.26GB to 1.05GB ## 2024.10.11 1\. BitVM official project update: Bitlayer @BitlayerLabs researcher PayneJoe optimized the MSM in affine coordinates, reducing the groth16 verifier script size from 2.6GB to 2.3GB 2\. BitVM official project update: Bitlayer @BitlayerLabs researcher dylanCai9 fixed the midpoint check on the curve in BitVM 3\. BitVM official project update: Hakkush-07 optimized Fq2 multiplication; this PR reduced the groth16 verifier from 1.33GB to 1.26GB by using 2 lc2 tmul instead of 3 lc1 tmul # 2024.9.23 - 2024.10.6 ## 2024.10.6 sCrypt @scryptplatform supports the implementation of multiplication in Bitcoin Script ## 2024.10.5 Official BitVM project update: . Hakkush-7 submitted an optimization for `u32_add_carry`, reducing its size from 145 bytes to 90 bytes. ## 2024.10.4 Official BitVM project update: . The u32 version of blake3 has been merged, changing the blake3 input type from u8 to u32. When used in the compression function, the inputs (u32) are converted to bytes. The u32 version of blake3 is a crucial component of the chunker. ## 2024.9.30 Bitlayer has released the feature overview for V2: . Bitlayer V2 offers several core features: \- EVM-Compatible: EVM applications running on Bitlayer V1 continue to work \- Finality Bridge: a trust-minimized two-way peg BTC bridge, superseding the multi-sig one \- Bitcoin-Equivalent Security: both the bridge and EVM state transitions are verified on Bitcoin through a cutting-edge fraud-proof gadget \- Flexible Data Availability Options: users may select either Bitcoin native DA or third-party DA based on their individual preferences. ## 2024.9.24 Yona @yona\_network published a research report on BitVM: . # 2024.9.16 - 2024.9.22 ## 2024.9.21 Shielded CSV white paper release: , Twitter link: . The paper uses BitVM as a bridge for the payment system, utilizing recursive proofs to complete the transaction history proof of CSV. ## 2024.9.20 The BitVM official project has merged the PR TMUL Optimization #99 submitted by the Citrea team @citrea\_xyz (), reducing the modular multiplication operation from 73.2k to 69.3k. This, in turn, decreases the Groth16 verifier size from 1.43GB to 1.36GB, achieving an improvement of about 5%. # 2024.9.9 - 2024.9.15 ## 2024.9.13 1. The official BitVM project : The main branch has merged a PR submitted by the Fimma team: \~50% Optimization of Field Multiplication with Lookup Table, ]\(). This PR incorporates the algorithm proposed by Alpen. a. This optimization reduces the total script length by adding auxiliary variables. Although this PR has been merged, the code has not been applied to the zk verifier. 2. The Element Labs team submitted a PR: Upgrade to v3 graph, add musig2 signing, improve client #91, . ## 2024.9.11 1. The official BitVM project has merged a PR submitted by the Citrea team: G1 scalar mul optimization #88, . This PR optimizes G1 scalar multiplication, reducing the size of scalar multiplication in the Groth16 verifier from 532m bytes to 295m bytes, an improvement of approximately 45%. ## 2024.9.9 1. The Citrea @citrea\_xyz team submitted a new PR . This PR optimizes the scalar multiplication used in the Groth16 verifier from 532m bytes to 295m bytes, improving it by approximately 237m bytes (around 45%). 2. The sCrypt Hackathon @scryptplatform project has implemented a trustless cross-chain solution between sCrypt and Litecoin. # 2024.9.2 - 2024.9.8 ## 2024.9.7 sCrypt @scryptplatform posted a blog stating that the product positioning of the sCrypt language will be aligned with Solidity ## 2024.9.3 The official BitVM project has been updated with the merge of two PRs: : - Optimized Fq multiplication using hints with w-width windowed method #87 : Optimized modular multiplication using the w-window algorithm. Contributed by the Alpenlabs team. - Fq-mul bug fix #86 : Fixed a bug in modular multiplication. Contributed by the Citrea team. ## 2024.9.2 1. Starkware has completed the project "shinigami" that verifies Bitcoin Script on Cairo. The project launched on 7.2. 2. Peter Todd @peterktodd published a long article titled "Soft-Fork/Covenant Dependent Layer 2 Review" analyzing the main covenant proposals and the new Layer 2 (L2) solutions that would use them. Article link: # 2024.8.26 - 2024.9.1 ## 2024.9.1 sCrypt @scryptplatform has updated its blog on implementing Vault, which largely references a previously published blog by Bitlayer. ## 2024.8.28 Risc0 @RiscZero has open-sourced all of its circuit code and constraint compiler. ## 2024.8.26 STARKWARE @StarkWareLtd announced that it has made significant optimizations to multiplication based on OP\_CAT. Once integrated into Circle STARK, it is expected to reduce costs by half. # 2024.8.19 - 2024.8.25 ## 2024.8.23 1\. BitVM Official Project Updates: \- : \- The `pseudo::restart_if` implementation has been refactored in the `main` branch. \- A new `lucid` branch has been added, referencing the `lucid` branch of . \- : A new `lucid` branch has been added with active updates: OP\_IF check disabled, stack counting fixed, StackAnalyzer test cases introduced, and debug information for OP\_PICK and OP\_ROLL added. \ 2\. Alpen announced further optimizations to their multiplication algorithm, which are expected to reduce SNARK script size by 1.2 GB. The optimized multiplication will have precomputation costs and additional committed data. Alpen noted that this is currently just a proof of concept (PoC).
## 2024.8.20 sCrypt published a blog post titled "Efficient Multi-Input Transaction Grinding for OP\_CAT-based Bitcoin Covenants." To enable introspection using OP\_CAT, the last byte of a Schnorr signature needs to be ground. This article reduces the grinding difficulty, aiming to optimize interoperability between future Bitcoin contracts. # 2024.8.13 - 2024.8.19 ## 2024.8.19 Latest Updates on the BitVM Project: * The BitVM project has merged the `chunker` branch into the `main` branch, . * The BitVM website has updated the BitVM Bridge design documentation, . * The `master` branch of the BitVM project has added the `serialize_to_bytes` padding interface, . ## 2024.8.15 Robin [@robin\_linus](https://x.com/robin_linus) published the BitVM2 paper ,The paper further elaborates on the BitVM2 paradigm and the BitVM2 bridge. ## 2024.8.13 1. sCrypt @scryptplatform has gathered technical content related to OP\_CAT, providing an excellent resource compilation; . Resource link: . 2. Fiamma @Fiamma\_Chain claims to have implemented a more optimized method for splitting BitVM scripts, which has already been applied to split Groth16 and FFlonk. This method abandons automatic splitting in favor of manually splitting each sub-function, reportedly achieving better results. Fiamma has showcased the final split results, but the related code has not yet been open-sourced. # 2024.8.5 - 2024.8.11 ## 2024.8.11 Bitlayer co-founder Kevin He [@0xkevinhe](https://twitter.com/0xkevinhe) stated at the "FORESIGHT 2024" annual summit that there have been three conceptual shifts in Bitcoin over the past two years: Bitcoin can issue assets, Bitcoin can generate yield, and Bitcoin can verify arbitrary computations. Additionally, two major changes have occurred: the return of the Builder spirit is reassuring, and institutional Bitcoin strategies are exciting. *Bitlayer is the first Bitcoin security-equivalent Layer 2 based on BitVM.* ## 2024.8.8 BitVM Project [**https://github.com/BitVM/BitVM**](https://github.com/BitVM/BitVM) Split Script Update 1. The Groth16 verifier script has been split into a total of 1,040 chunks, with each chunk not exceeding 3MB (3,000,000B). The maximum number of stack items that need to be copied between chunks is 1,066, which likely still requires optimization. 2. The Fflonk verifier script has been split into a total of 1,041 chunks, with each chunk not exceeding 3MB (3,000,000B). The maximum number of stack items that need to be copied between chunks is 927. ## 2024.8.6 BitVM PR [https://github.com/BitVM/BitVM/pull/84 ]()reduces the multiplication from 71,757 bits to 68,328 bits. ## 2024.8.5 1\. The Alpen team uploaded a paper , claiming that by using optimized NAF multiplication, the length of BitVM scripts can be reduced. However, there is no implementation available yet. 2\. Recently, an independent team called Element has emerged, focusing on contributing to the bridge module of BitVM. This team has no relationship with ZeroSync. Team introduction: , code repository: # 2024.7.22 - 2024.7.28 ## 2024.7.28 The chunker branch refactored the structured scripts and merged the script splitting PR contributed by Bitlayer[@BitlayerLabs](https://x.com/BitlayerLabs): [https://github.com/BitVM/rust-bitcoin-script/pull/5…](https://t.co/DVAYv5oiOJ) ## 2024.7.25 [https://github.com/BitVM/BitVM/pull/79…](https://t.co/Yxrf6fOPCG) has been merged, implementing all transactions involved in disprove/burn and other aspects of BitVM2. ## 2024.7.23 Bitlayer[@BitlayerLabs](https://x.com/BitlayerLabs)completed a $11 million Series A funding round, led by Franklin Templeton and ABCDE. [https://fortune.com/crypto/2024/07/23/franklin-templeton-bitcoin-bitlayer/…](https://t.co/1mZ3v7hkfl) **Bitlayer is the first Bitcoin Layer 2 based on BitVM, dedicated to becoming Bitcoin's computing layer.**[
](https://t.co/IY7YK3efV7) # 2024.7.15 - 2024.7.21 ## 2024.7.21 The BitVM project has successfully merged a pull request () that implements the full version of Algorithm 9 from the "On Proving Pairings" paper(). This includes: 1. \- Utilizing the affine mode from section 5.2 of the paper, reducing the script size of the Groth16 verifier by approximately 600MB. 2. \- Preprocessing the constant scalar ONE in the MSM, reducing the script size of the Groth16 verifier by about 500MB. 3. \- As a result, the final script size of the Groth16 verifier has been reduced from around 4GB to approximately 2.9GB. Simultaneously, the script size of the FFLONK verifier has been reduced from around 3.2GB to approximately 3.1GB. ## 2024.7.18 Starkware has announced a collaboration with L2 Iterative to deploy the Circle Stark verifier using Bitcoin script on Signet. ## 2024.7.17 1. Bitlayer has published an article interpreting MuSig2. 2. BitVM has merged the stack analyzer contributed by Bitlayer engineer Andrew. # 2024.7.8 - 2024.7.14 ## 2024.7.14 Bitlayer has released a comprehensive article on the latest breakthrough in BitVM, clarifying the missing parts of the BitVM2 model.The article provides a detailed summary of updates within the BitVM community, including: 1. Clarifying the missing parts of the BitVM2 model (based on Bitlayer's assumptions) 2. Information from Robin Linus' interview on Bankless and updates on BitVM2 3. The integration of various ideas proposed by the BitVM Builders group ## 2024.7.12 BitVM's official repository,, has made adjustments to use Blake3 for Winternitz signatures, likely preparing for bit commitment between split scripts. ## 2024.7.11 Bitlayer contributed Bitcoin script stack analysis code to the BitVM community, which has now been merged. # 2024.7.1 - 2024.7.7 ## 2024.7.5 BitVM Official Project: Lukas is currently working on script auto-segmentation, which is expected to create a new crate including call stack analysis, chunk segmentation, and other tasks. This work is still in its early stages, with some test code written so far:. # 2024.6.24 - 2024.6.30 ## 2024.6.30 Robin discovered an interesting project on Delving Bitcoin:(Python language). * The project is positioned as: B'SST: Bitcoin-like Script Symbolic Tracer * It can symbolically execute opcodes, track the constraints imposed on values operated by opcodes, and show * conditions of script execution, possible failures, and potential data values, etc. * Supports Bitcoin script and Elements script. * Helps in analyzing and revealing potential issues in scripts. ## 2024.6.28 The official BitVM team has recently significantly optimized the compilation speed of the[rust-bitcoin-script library](https://github.com/BitVM/rust-bitcoin-script/tree/better_scripts)(better\_scripts branch) and the Script size of the Fflonk Verifier and Groth16 Verifier. * Currently, the Script size of the Groth16 Verifier has been reduced from approximately 7GB to about 4GB; the script compilation speed has been reduced from over an hour to about 70 seconds. * Currently, the Script size of the Fflonk Verifier has been reduced from approximately 5.6GB to about 3.2GB; the script compilation and execution speed has been reduced from over half an hour to about 150 seconds. ## 2024.6.27 The BitVMX team released a blog sharing their thoughts on optimizing BitVM SHA256 script size: * For various existing algorithm implementations, simply translating normal implementations is not feasible, as the cost structure of Bitcoin scripts is completely different. * Clever application of lookup tables, with dynamic loading and unloading, to optimize. * The 1000 limit of the stack is one of the biggest challenges. * Logical operations are commutative (x & y == y & x), which can save almost half of the logical table. Implemented OP\_MAX with 5 opcodes. * Currently, BitVMX can reduce SHA256 from 516K to 344K to 296K; Blake3 from 103K to 45K. * They have open-sourced the stack debugging tool:(Rust) library. # 2024.6.10 - 2024.6.16 ## 2024.6.10 The first developer meeting (Dev Call) of the BitVM project, during which the design of the BitVM2 bridge was updated.
Key Points: **1.** Robin's next focus is on developing zkCoins rather than other sidechains. zkCoins will use client-side validation and ZK proof. **2.** The original Kickoff transaction inhas been split into two transactions: Kickoff1 and Kickoff2. The purposes are: **2.1** Kickoff1 is mainly for challengers to initiate a challenge, requiring the challenger to pay 1 BTC to the challenged Operator. If there is a challenge within 2 weeks + 3 days, the connector A output will be spent, invalidating the reimbursement path on the Take1 happy path. The challenger must see the Kickoff2 transaction before deciding whether to challenge. **2.2** The Operator must initiate the Kickoff2 transaction within 2 weeks of publishing the Kickoff1 transaction, otherwise, anyone can initiate a Kickoff Timeout transaction to penalize the Operator after 2 weeks + 1 day. **2.3** Kickoff2 commits to the "consensus state SB" on the L2 chain. Robin's focus is on communication between two PoW chains. He mentioned in the official Telegram group that this will be based on the 2017 paper "Non-Interactive Proofs of Proof-of-Work (NIPoPoW)" and that a new related paper will be released. The hash value of the "consensus state SB" will be used as the y value in the Assert transaction. **2.3.1** Within 3 days, if anyone disputes the "consensus state" in the \[start\_time, start\_time + 2 weeks] period (indicating suspicion of the Operator cheating by using a forked chain) and can provide a new consensus state SB' with a higher weight, they can initiate a Disprove Chain transaction to penalize the Operator. In this case, the connector B output will be spent, invalidating the reimbursement path on the Take1 happy path. **2.3.2** If a challenge is initiated within 2 weeks + 3 days after Kickoff1, it means the connector A output is spent, invalidating the reimbursement path on the Take1 happy path. * If the Operator does not initiate the Assert transaction, it means they give up the right to reimbursement using Take2. The Operator will lose 2 - 1 = 1 BTC. \[The 2 BTC expenditure method on connector B output includes Take1, Assert, and Disprove Chain]. * If the Operator initiates the Assert transaction, it means they want to exercise the right to reimbursement using Take2: * \- If anyone finds inconsistencies in the Assert, they can initiate a Disprove transaction to penalize the Operator. In this case, the connector C output will be spent, invalidating the reimbursement path on the Take2 unhappy path. * \- If no one successfully initiates a Disprove transaction after 2 weeks, the Operator can initiate the Take2 transaction and get reimbursed successfully. **2.4** Compared to the BitVM2 version, a challenge phase for the "L2 consensus state SB" has been added — the Disprove Chain transaction. However, the incentive problem for challengers has not been solved. Challengers pay 1 BTC, and if successful, the profit still goes to miners, not the challenger themselves. **2.5** The Kickoff1 transaction uses an OP\_CLTV absolute time lock. The reason is still uncertain; it may be because NIPoPoW requires an absolute block range for proof of work and comparison? However, this design may still have issues because Kickoff1 is pre-signed, and the actual time for future reimbursement is uncertain. # 2024.6.3 - 2024.6.9 ## 2024.6.8 Risc zero0[@RiscZero](https://x.com/@RiscZero)announced their support for citrea to become a Bitcoin zkRollup. They have used the open-source BitVM Groth16 verifier, enabling developers to generate STARK proofs with RISC Zero and verify them on Bitcoin. ## 2024.6.7 Bitcoin layers[@BitcoinLayers](https://x.com/@BitcoinLayers)updated their framework for evaluating Bitcoin L2. ## 2024.6.6 * The Bitlayer team has significantly optimized the Bitcoin script verifier for FFlonk, reducing the script size by 1.8 GB.This optimization uses multipoint synchronized batch scalar multiplication, reducing the original five scalar multiplications to two batch scalar multiplications. * RISC Zero's verifier will soon be deployed on Starknet, enabling developers to perform unlimited computations. ## 2024.6.5 Citrea Public Devnet is now live for developers and users. ## 2024.6.4 Starkware announced that within six months after adopting OP\_CAT, they will develop Starknet as a common L2 for both Bitcoin and Ethereum, expanding Bitcoin TPS to over 1k.They also explained on their official blog why they are scaling Bitcoin. * Clearly and repeatedly expressing their support for OP\_CAT, they have launched a $1 million fund to support research into the pros and cons of OP\_CAT. * They mentioned the Bitcoin Wildlife Sanctuary, which aims to implement Circle Stark using OP\_CAT. * Ethereum and Bitcoin will serve as the settlement layers for Starknet, with specific plans to be released in the coming weeks. ## 2024.6.3 Anthony Towns released a script that can run on Signet, using OP\_CAT to allow anyone to use proof of work (PoW) to obtain tokens locked by the script. This can be used as a decentralized Signet Bitcoin faucet. # 2024.5.27 - 2024.6.2 ### 2024.5.31 Bob founder Alexei Zamyatin stated, "We focus on building for the present, not waiting for the future. If the future arrives, we will be ready," referring to the application of OP\_CAT. [https://twitter.com/alexeiZamyatin/status/179627791365192135](https://twitter.com/alexeiZamyatin/status/1796277913651921351) ### 2024.5.30 1.Bitlayer posted on Twitter: The Bitlayer research team announced the latest breakthrough in Bitcoin ZK proof verification - a new Bitcoin-friendly FRI. This FRI can verify conventional FRI Merkle proofs on Bitcoin without relying on OP\_CAT. 2.Zulu network submitted a PR fully implementing fflonkand groth16 2.1 This PR has a significant impact and is a milestone for bitvm. 2.2 The script has not yet been split; if each leaf script is 400k, approximately 20,000 leaf nodes are needed. Zulu network plans to continue working on script splitting. 2.3 One potential optimization is to treat some constants as witnesses only during expenditure. # 2024.5.20 - 2024.5.26 ## 2024.5.23 1. Media Interpretation: Bitlayer[@BitlayerLabs](https://x.com/@BitlayerLabs)BitLayer is the first Bitcoin security Layer2 based on BitVM. 2. Robin Linus gave a BitVM presentation at Zkproof6 ## 2024.5.22 1. The BitVM community promotes a Bitcoin script debugger that supports stack element labeling and step-by-step debugging:

# 2024.5.13 - 2024.5.19 ### 2024.5.17 New PR in BitVM:Claims to have achieved 2/3 of[On Proving Pairings](https://eprint.iacr.org/2024/640.pdf) * [On Proving Pairings](https://eprint.iacr.org/2024/640.pdf)is a paper by Alpen, mainly contributing to optimizing the pairing verification process using pre-computation methods. * The PR is currently under review. ### 2024.5.15 In the BitVM project, the Blake3 calculation script size has been optimized from 103k to 45k. The technique used is similar to the optimization of SHA256, involving a conversion from u8 representation to u4 representation. This PR has been merged: # 2024.5.6 - 2024.5.12 ### 2024.5.11 SHA256 has been further optimized to 296K per chunk, see. Currently, this PR is still under review. 1. The PR still uses u4 as the basic unit, but these optimizations are achieved by reducing unnecessary value copying or moving on the stack. 2. This PR adds around 1866 lines of code, implementing optimized u4 version of sha256, and introduces an additional library for debugging BTC scripts at. 3. The library for debugging BTC scripts is speculated to be inspired by the visual debugging of BitIDE (js) developed by QED protocol, which is worth referencing. (A demo of BitIDE implementing blake3 is available at). ### 2024.5.10 Bitlayer[@BitlayerLabs](https://twitter.com/@BitlayerLabs)has completed its first NFT minting, and the community now has over 500,000 users! NFTs can be purchased on OKX:. BitLayer is the first Bitcoin security Layer2 based on BitVM.
\ Citrea[@citrea\_xyz](https://twitter.com/@citrea_xyz)posted indicating the use of RISC0 technology to generate two types of proofs: one for Bitcoin light client and the other for batch proofs of L2 transactions.
Citrea's proof generation mechanism is specifically tailored for Bitcoin and BitVM. Citrea operates on top of a STARK-based zkVM with recursive capabilities, incorporating RISC Zero, and utilizes two different types of proofs:Batch Proofs: Batch proofs are generated periodically, typically every few Bitcoin blocks. Citrea's batch proof circuit is configured to scan batch root ciphertexts in Bitcoin blocks through inclusion and soundness proofs. If present, it inputs the L2 batch causing the batch root and proves the validity of the L2 batch. The proof output consists of the batch, initial state root, latest state root, and the state differences induced by scanning the Bitcoin block's block hash. The proof with outputs is etched onto Bitcoin.Light Client Proofs: Light client proofs recursively validate batch proofs and provide a single proof for the entire Rollup history, enabling trustless instant light clients. The light client proof circuit inputs previously generated light client proofs, a set of batch proofs containing inclusion and soundness proofs, and a set of Bitcoin block headers corresponding to the recorded batch proofs. The circuit recursively validates each batch proof and light client proof, asserting that the latest state root of proof N-1 equals the initial state root of proof N. This logic ensures no state transitions are skipped, resulting in a state root identical to the actual Rollup state root. 1. By recursively validating previous light client proofs using batch proofs, light client proofs can be generated at any time. 2. Light client proofs are broadcasted in a peer-to-peer network and etched onto Bitcoin. 3. Light nodes can listen to the peer network or only track the latest Bitcoin headers. They validate the complete Rollup history with the latest evidence they find and provide trustless access to the state root. Citrea's circuits primarily prove two distinct logics: execution and block space. During batch proof generation, both execution and block space are proven. During light client proof generation, block space and batch proof validation are proven.Execution Proof: Citrea runs the state transition function of the rollup, which is a slightly broader logic of EVM included within the zk circuit. The circuit inputs the previous state of Rollup, the blocks of the new batch, and outputs the state difference between the pre-state and post-state after applying the batch.Block Space Proof: Block space proof is a novel concept used in Citrea. The block space proof logic is a custom zk circuit that scans Bitcoin blocks, extracts state roots or Citrea batch proofs, and enforces transactions from it. In batch proofs, it asserts the accuracy of the state root, and in light client proofs, it verifies the batch proof (if present). The Bitcoin block scan within the circuit is completed by given inclusion and soundness proofs and cross-checked with corresponding Bitcoin block headers.Citrea combines execution proofs and block space proofs into a single circuit for batch proofs. Standalone batch proofs are only beneficial for full nodes. To run light nodes on a system with only batch proofs, light nodes must individually check proofs for each Bitcoin block, which is impractical for light clients due to bandwidth and storage requirements.In Citrea, due to the recursion of its light client proofs on batch proofs and block space proofs, users have trustless light clients. Anyone with the last few Bitcoin blocks or connected to the peer-to-peer network can extract Citrea light client proofs and ensure it represents the only valid fork of the chain and verifies every state transition since the Citrea genesis block. ### 2024.5.6 [@rot13maxi](https://twitter.com/@rot13maxi)explained in the Bitcoin++ talk () 1. Introduce how op\_cat can be used to implement the principle of vaults. 2. He also suggested that in the future, it might be possible to extend a finite state machine through the implementation of vaults, recommending the idea of MATT (Merkleize All The Things) discussed in Bitcoin mailing lists. More details are available at. # 2024.3.18 - 2024.3.24 > Original: If there are omissions or errors, corrections are welcome. Thank you very much! ### 2024.3.22 Weikeng Chen[@weikengchen](https://twitter.com/@weikengchen)has implemented arithmetic operation Bitcoin scripts based on the Mersenne prime M31 field. Future plans include expanding it to the Goldilocks field. Both M31 and BabyBear fields require a degree 4 extension, while Goldilocks64 only requires a degree 2 extension. Due to the inability of Bitcoin operation opcodes to handle signed 32-bit overflow issues, Goldilocks64 needs to be represented by three u32 numbers to avoid overflow and related problems. github link: ### 2024.3.21 Citrea[@citrea\_xyz](https://twitter.com/@citrea_xyz)has[announced the open-sourcing of its BitVM-based trust-minimized two-way peg program](https://twitter.com/citrea_xyz/status/1770813889447432493). For detailed documentation, please visit:, and to access the code, visit:. # 2024.3.11 - 2024.3.17 If there are omissions or errors, corrections are welcome. Thank you very much! ### 2024.3.17 1\. Twitter sent by the BeL2 team[@Be\_Layer2](https://twitter.com/@Be_Layer2)[@sash\_\_mit](https://twitter.com/@sash__mit),they will advance BitVM by passing ZKPs into EVMs, turning EVM ecosystems into Bitcoin sidechain processors, opening up a scalable world of incoming smart services.
2\. Weikeng Chen[@weikengchen](https://twitter.com/@weikengchen) from L2Iterative [@l2iterative](https://twitter.com/@l2iterative) contributed a PR for u32 mul to BitVM, It took 3705 bytes in Bitcoin script. Detail PR link: Add u32\_mul by weikengchen · Pull Request #12 · BitVM/BitVM, The PR has been merged now. PR link: ## 2024.3.14 1.[@0x\_orkun](https://twitter.com/@0x_orkun)from Citrea[@citrea\_xyz](https://twitter.com/@citrea_xyz)posted on twitter ，Described the approach to verify ZK proofs with OP: a. Represented BitVM using binary circuits, enabling the output of BitVM programs to be 1 or 0 (true or false). b. Encoded the ZK verifier into BitVM. If the output is 0, it indicates a false ZKP. The prover submits a ZKP, and the verifier initiates challenges to prove the proof is invalid. Ultimately, 40 transactions are required to determine the validity of the ZKP. 2\. Citrea [@citrea\_xyz](https://twitter.com/@citrea_xyz) posted twitter，Announced the open sourcing of its[GitHub - chainwayxyz/bitvm-zk-verifier: BitVM Groth16 Verifier Toolkit - WIP](https://github.com/chainwayxyz/bitvm-zk-verifier)，based on Risc0 prover and BitVM-based proof verification circuits, achieving the challenge verification of Groth16 proofs. The basic process is as follows: 1. Creating STARK proof from a RISC Zero guest program (written in Rust) 2. Wrapping the STARK proof into a Groth16 proof 3. Crafting its corresponding Groth16 verifier in C 4. Compiling the verifier to rv32i instruction set 5. Transpiling the verifier from rv32i to BitVM instruction set 6. Running the BitVM simulation (To be run on-chain once BitVM is ready) ### 2024.3.12 [@alexeiZamyatin](https://twitter.com/@alexeiZamyatin)from Bob[@build\_on\_bob](https://twitter.com/@build_on_bob)said their vision is to create the first hybrid rollup with multiple native bridges.
# 2024.3.4 - 2024.3.10 *If there are omissions or errors, corrections are welcome. Thank you very much!*
### **2024.3.9** Advancing Bitcoin [posted](https://twitter.com/advbitcoin/status/1766155921883815947) that Super Testnet @super\_testnet the contributor to BitVM will give a hands-on workshop on "Learn BitVM by Building Tic Tac Toe" at The [Advancing Bitcoin Conference](https://www.advancingbitcoin.com/) @advbitcoin next week 14th March. ### **2024.3.6** On March 6, 2024, Robin Linus @robin\_linus [tweeted](https://twitter.com/robin_linus/status/1765337186222686347) that Dan Boneh @danboneh introduced Winternitz signatures as a more compact alternative to Lamport signatures (also known as bit commitment). This reduces the bit commitment size by 50%, enabling a reduction of at least 50% in transaction fees for BitVM. For the relevant code implementation, refer to: . The theoretical knowledge of Winternitz signatures can be found in Section 14.3 of Dan Boneh's book at . --- [Next Page](/llms-full.txt/1)