Last updated
Was this helpful?
Posted on 16 January 2024
Robin Linus joined Brink engineers to discuss his BitVM proposal and associated projects.
In his presentation and Q&A we discussed:
Stateful Bitcoin scripts
BitVM architecture
The Tree++ language
BitVM Bridges, peg-ins, and peg-outs
Limitations and future plans
A PDF copy of Robin’s slides is available for download and a recording of the presentation provided below.
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..
