Amir

BitVM: The 24 hour update. After thousands of Twitter posts and hours of spaces and discussions, we know much more about BitVM than we did yesterday. Here’s a quick update: Excitement 1. BitVM is a new computing paradigm that leverages the universal gate NAND (along with other gates) within Taproot leaves with pre-signed transactions in optimistic rollup prover/verifier/challenger fashion to theoretically enable any computation on Bitcoin itself. I say “theoretically” because there are many caveats right now. If this doesn’t make sense to you, search how you can build an entire computer with just NAND gates. Now do it using Bitcoin Script, and that’s BitVM in a nutshell. 2. The best way to think about BitVM is like a very early *limited* version of the EVM, meaning you can think about it like a limited smart contract platform directly on Bitcoin. No additional trust assumptions. No points of centralization. This is essentially a hybrid paradigm that mixes direct Bitcoin script smart contracts and an L2 like the Lightning Network. 3. BitVM is an amazing breakthrough because while there are many gaping holes right now in the BitVM, they are mostly solvable. Over the next few months I expect many of these holes to get filled in, at which point we will have more capable Bitcoin script without a Bitcoin upgrade. 4. This is a new paradigm of computing on Bitcoin that will likely never go away. With every new BIP, you will now have to interpret the proposed Bitcoin upgrade in the presence of BitVM. This future is very exciting. Challenges 5. BitVM is in its VERY early stages. In the EVM you have the full power of Solidity. In the BitVM we have a single function that can check whether a string is all 0’s or not. That’s it. A single function (h/t Super Testnet!). Obviously many brilliant devs are working on additional functionality, but for now, we basically just have a white paper and a single function. 6. When you build a virtual machine using NAND gates (or even using more optimized gates leveraging other op_codes) you end up with massive data requirements. Potentially hundreds of MB for a reasonably complex program. Billions of taptree leaves. This can come down over time as things get optimized, but currently this is very large. 7. There is currently a two party limitation. There are many discussions right now about how to allow for 1 to N or N to N setups - like literally right now in a Telegram chat brilliant people are talking about a new mechanism that starts as regular federated but transitions to single-honest-party federation over time (h/t Super Testnet). So this has not been solved yet, but it seems there are some interesting paths forward. 8. Because of these limitations, it is still worth considering improvements to Bitcoin itself. The BitVM would be dramatically improved with an additional op_code (e.g., BIP-119). So BitVM doesn’t mean we can just sit back and wait for brilliant wizard devs to solve programmability on Bitcoin. It is likely that we’ll still need a Bitcoin upgrade to get to where we want to go. (this point is controversial, but a Bitcoin upgrade would definitely improve BitVM) Bob's Take The thing that I am most excited about is being able to implement a ZK verifier in the BitVM. We still don’t know how, where, when, or if this will happen, but if you could implement a ZK verifier in the BitVM then you would unlock the full power of L2s directly on Bitcoin. Trustless bridging, more throughput, more privacy, cheaper transactions, unlimited programmability, more scale, etc. And all without a Bitcoin upgrade! (technically this is unlikely to happen without a Bitcoin upgrade, but at least there is a chance…).