Last updated
Links:
Paper: bitvm.pdf
X: @robin_linus
Super Testnet’s Tapleaf circuits: supertestnet/tapleaf-circuits
Shinobi article on BM: bitcoinmagazine
AJ Towns ML response on BitVM: BitVM: Compute Anything on Bitcoin
Sponsors:
Swan.com (code LIVERA)
CoinKite.com (code LIVERA)
Stephan Livera links:
Follow me on X @stephanlivera
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.
