 So thank you for the kind introduction. My name is Clemens, I'm co-founder and CEO of yours and I'm, like was said, gonna talk about Turing completeness in Bitcoin today. And so a few comments up front. I'm not gonna present here that Bitcoin script is Turing complete because it's not, right? So it's limited in size, doesn't have loops, so you cannot do arbitrary computations in Bitcoin script. And I'm also not showing that everything that can be done in Ethereum can be done in Bitcoin today. But what I am showing is that many things that people think are today like impossible to do in Bitcoin can actually be done. And so examples would be like voting or auction, stuff like that. And so I'm presenting this here to inspire you guys to build cool stuff on top of this. Quick overview of what I'm gonna talk about. So first I'm gonna give you sort of the basic idea from 10,000 feet why this isn't like an audaciously crazy claim, okay? And then so I don't have time to present an actual proof but I'm gonna present an application that just shows all the main techniques that are used in the proof and that will show you guys how we can sort of use this technique. Finally I'm gonna talk a little bit about related work and discussion, okay? So the basic observation is that Bitcoin can be thought as a replicated state machine, okay? So what does that mean? So a replicated state machine is shown here on the slide, consists of a bunch of nodes that represent states that are like the little green dots there. And then transitions between the states. So think of like a database application where the state is the content of your current database, okay, and then you can update something for example into the tuple and transition to a new state, right? Or you can delete stuff, you can have loops. And so this is just a very abstract way of describing every computational system that there is really much. So how does this relate to Bitcoin? How does this map to Bitcoin, okay? So in Bitcoin, I mean we know that in Bitcoin the entire state is stored in the blockchain, okay? And in particular the unspent output set contains the amount of data that can be changed, okay? So we can encode data in unspent outputs, okay? So how can we change that data? Obviously there's only one choice in Bitcoin transactions, right? So Bitcoin transactions spend unspent outputs and like destroy them pretty much and create new unspent outputs. So if you want to do like database update, you know you just sort of destroy the output that contains the old tuple, create a new one that contains a new tuple, right? And then finally you need something that sort of resembles the clock in a computer that just drives the computation forwards. And so in Bitcoin what we need is we need someone to just broadcast these transactions to update the state continuously, okay? And the way this naturally works in Bitcoin is that you just incentivize users, you know, to broadcast transactions because if they do they're gonna make money, right? And then if you just wanna make, you know, since people like money, they're gonna continue sort of broadcasting these transactions and like thereby drive the computation forwards. Okay, so the application that I'm presenting here today is imagine there's Alice, okay? And Alice is interested in a function F and particularly Alice wants to have some X, you know, that makes the function value to true, okay? And Alice can figure out this X herself but Bob can, okay? And so essentially what Alice wants to do is she wants to buy that secret X from Bob, okay? But since, you know, in a trustless setting they don't trust each other, you know, they want some guarantees. So kind of the risk is here, you know, if Bob sends the secret to Alice first like in that picture there, then Alice has no reason and Alice has what she wants, right? She has no reason to give Bob that one Bitcoin, right? And sort of in the, if you flip the two arrows, if, you know, Alice were to pay first, right? Then Bob's happy after getting the one Bitcoin and he has no reason to reveal, you know, that secret X. So what I'm showing here is how such a trustless exchange can be built on top of Bitcoin, okay? So how does this work? So first consider the case where F is just a very simple function, right? So a function that can be encoded directly in Bitcoin script, okay? So that's a very easy case, okay? In that case, what Alice just does is she broadcasts a transaction with an output script encoding that function F, okay? So recall that output scripts essentially encode functions, okay, and then input scripts plug parameters into this function. And you can spend an output of the parameters that the input sort of provides to the function evaluates the true, okay? So Alice is just gonna go ahead and broadcast that one transaction, okay? Now Bob finds that output. Like this, all right. I just hold it, all right. All right, okay, cool, no problem. Okay, so Alice has just broadcast this transaction that encodes F and say it spends one Bitcoin, okay? Now Bob knows that secret X, okay? And since Bob wants the one Bitcoin, he's gonna want to spend that output, okay? So all that Bob now does is he broadcasts the second transaction, yeah? That's sort of where the input script encodes sort of the secret value X, okay? That gets plugged into the output script created by Alice, okay? Makes sort of the output script evaluative true, and Bob can now spend that one Bitcoin. So Bob's happy, he gets the one Bitcoin, and but also at the same time, since Alice can look up sort of the encoding of X on the blockchain, she learns about the X, right? So that's a way to do trustless exchange if F is a very simple function, okay? And so I can introduce a little bit of visual notation here where like these boxes, you're gonna see lots of them. They sort of represent Bitcoin transactions, okay? And the top part will always be like the input scripts. This is gonna be the output scripts, and the little arrow here kind of indicates that like this input spends that output there, okay? Okay, so what can Alice do if F is like a more complicated function that sort of cannot be encoded in Bitcoin script right now? So in general, there are three problems, right? So the computation might require too many steps, okay? Computation on a computer can run for a long time, Bitcoin script, sort of the number of steps that can execute as bounded by the length, and since the size of a transaction is bounded, you can only do a bounded number of steps, okay? And the second problem is that like the computation might require just too much space, you have to store lots of stuff, okay? And you also cannot do that in a single Bitcoin script. And finally there's a problem. So the input X that Bob provides might even be too long to just fit into a single transaction input, right? So he's gonna have to split these up into several transactions somehow. Okay, so how can we solve this problem if F is like a more complicated function, okay? And so the way this can be done is, Alice gives Bob a couple of transactions that encode this function F, okay? And I'm gonna be talking a lot about this set of transactions that Bob gets from Alice. Let's leave that for later, just to give you an overview of how this works. Okay, so this set of transactions kind of guarantees to Bob that if he provides an X that makes that function evaluate to true, he's guaranteed to get paid, okay? So at this point, Bob is kind of happy to reveal sort of that secret X, okay? And the way he does it is he encodes the X in a series of outputs, okay? And like since X might be just a very long word that doesn't fit in one single output, you might have to just split it up into several outputs, okay, so it's four in the example, could be one, could be a thousand, whatever you like, okay? And then at this point, Alice can look up sort of the encoding of X on the blockchain and can learn about X, okay? But now Bob sort of wants his money and what he can do is he's gonna take those transactions that he just obtained up here from Alice, okay? And he's gonna start spending these outputs that Bob himself created, okay? And sort of he's sort of gonna chain together a bunch of transactions, okay? Now, if you just intuitively think about it, if you change together transaction, you can change as many as you like, right? So you can do computation of arbitrary lengths and sort of since you kind of have like, you know, kind of things in parallel a little bit, you can also just encode lots of data if you want to, okay? So that's what Bob does, is he takes the transactions obtained from Alice and sort of derives a new special output, that little green thing down there called sort of the reward output, okay? And the set of transactions that he obtains from Alice as the important property that Bob can only produce that reward output if and only if sort of his encoding, in fact makes that function evaluate to true, okay? That's very important because otherwise, you know, one of them too could kind of cheat or steal money or stuff like that, okay? But in this example, you know, X was in the language, so Bob can produce the reward output. Now Bob is gonna use a second transaction he obtained from Alice that spends one other output that Alice paid for containing one Bitcoin, okay? And the reward output and he sort of creates a new transaction that spends these two outputs here and now this output spends to Bob, okay? So at this point, Bob earns the one Bitcoin, okay? Like there's no trust required there at all, okay? Now in the rest of the talk, I'm just pretty much gonna zoom into this picture here and I'm sort of gonna explain exactly sort of the crucial part is like how does the set of transactions look up there, okay? And then since we're assuming this is like a complicated function, in general, I can just assume it's sort of encoded by a Turing machine, okay? You can encode like any computer function by the Turing machine. And so we assume that just Alice has this Turing machine that encodes F, okay? So quick reminder, what a Turing machine is, it's very simple. It's like, it's just a very abstract way of looking at a computer, yeah? It consists of hardware and software. So the hardware consists of a tape, okay? That tape corresponds to sort of the hardware drive on your computer, okay? So it can be very big, what people say is unbounded, okay, it's not infinite because there's no hard drive with infinite space. It's not finite because that's too restricted but sort of the idea is whenever a computation needs more space, it can add just a little extra cell to that tape, okay? And sort of that corresponds to the notion if you have like a computer, you run out of hard drive space to run a computation, you just get a bigger hard drive pretty much, okay? And so in addition to the tape, the computer has a little read write head, okay? And that read write head corresponds to sort of the read write head on a hard drive. So it's always looking at one cell on tape and what it can do is it can read the content of the tape and modify the state, okay? And then sort of the final component in the hardware part of a Turing machine is this little state Q1 up there. I know states are always called Q for some reason. And so you can think of this internal state like the registers of your CPU maybe, right? You have like a very small finite amount of stuff that you can store directly on the CPU. Everything that's large, you store on your hard drive or the tape. So that's the hardware part of the Turing machine. So how do we program these machines, okay? So a program of the Turing machine is this kind of transition relation. And what it tells you is the way to read this is like if you're in states, so I'm reading the first line, if you're in state Q1 and your head is currently reading a zero, what you're supposed to do is, you know, write a one and move one position to the left and change your states to state Q2, okay? So let's just run through this example real quick. So we're in state Q1 and we're reading one. So the second line applies here, okay? And now this sort of this transition relation or sort of the Turing machine program tells us, okay, replace that one that you're currently reading by a zero, move one step to the left, but stay in state Q1, okay? So that's what happens. And you know, the head moves one position to the left. Updates, you know that cell that used to be a zero, a one to a zero, okay? And then you just completely mechanically, you know, keep looking at, you know, what's my state, what's currently on the tape, look into the transition relation and that's what the Turing machine is gonna do, okay? So, I mean, you can refer to this if you want. Okay, and so the basic idea of how we can encode a function that's like represented by Turing machine in Bitcoin is as follows, okay? We want to sort of encode the entire state of the Turing machine in, you know, Bitcoin transactions and more specifically in unspent outputs, okay? So, you know, what Bob is gonna do is, so you can think of this lineup here, this is sort of the input word to the computation, okay? And then sort of the Turing machine runs and at the end you saw was a green state there, so it's an accepting run. So, and what we're gonna do is we're gonna sort of encode everything that the Turing machine does in unspent transaction outputs, okay? So the first output he creates is this one here and what this kind of means is sort of the output encodes position number zero of the tape contains the hash symbol, okay? Then he encodes sort of a second output that encodes the first position contains a zero symbol, okay? Third, like, okay, what? Second position contains a zero symbol if you start counting in zero, okay? That's fairly obvious. And then, you know, at this point we have to encode this position here where the head is currently headed, sort of the position that contains the head. And what Bob is gonna do in this case is he's just gonna sort of add that to the encoding, right? So this little red output there means that like, you know, position four contains a symbol one also contains the head which is currently instead one, okay? And then the last one is here again, okay? And so what we're gonna do now is we're gonna maintain an invariant that sort of the set of unspent outputs that we're interested in always corresponds exactly to the current configuration of the Turing machine, okay? So if we look at what the Turing machine did in the next step, it moved one position to the left and wrote a zero and moved to state Q1, okay? So we see that two cells have been modified here, right? So the red one, what's currently red doesn't contain the head anymore and it also contains a zero. So we have to like, spend that output and replace it by an output that encodes sort of the new configuration. And in addition, the second cell that has changed is sort of this one that's under an output label 3.1 here, okay? And since there's only like two positions of the tape that change in every computation step, you can do this exactly in a Bitcoin transaction, right? And the idea is you spend these two outputs that you want to kind of destroy and create two new ones that reflect sort of your new configuration, right? So now what's happening is like, Bob broadcasts a transaction that does exactly that. Like it spends these outputs that are sort of outdated now and creates new ones that corresponds to the new configuration of the tape, okay? So Bob just continues doing that and continuously like spends these outputs. And what you can see is we always maintain this invariant. Okay, so that like, if you look at the unspent output sets here, zero contains it. So this guy is supposed to correspond to this line. Okay, position zero is the hash, position one is the zero. Position two is now zero and the state Q1 which is exactly like there. And so if you just follow the thing, the unspent output set always corresponds to the configuration of the Turing machine. Okay, so this is basically the idea of sort of simulating a run in a Turing machine in Bitcoin transactions pretty much, yeah? And just for context, sort of the, thank you. This top line there, that were the outputs. And this is the encoding of the value X. Those are the ones that Bob produces. And all these bigger squares down there. Those are transactions that Bob obtained from Alice. Those are the ones that encode this function F. Okay, so now everybody's probably wondering, what's this guy talking about? What does this mean in output encodes to one? Okay, so now what I'm doing is I'm just gonna zoom into these, this little square up there. Okay, these two transactions and explain you exactly how this encoding works. So if we zoom into this picture, I just copied top left thing, these four squares and the big picture is kind of zooming in what that actually means, okay? And so what are these output scripts? And it's actually surprisingly simple, right? So the input scripts are just signatures of Alice and Bob, okay? And then the output scripts do something really weird, okay? They just push exactly these numbers that are sort of this output script corresponds to the red square at the bottom left up there, okay? All that it's doing is it just pushes this encoding onto the stack, drops them immediately after again, okay? Sounds weird, but I mean, it works, okay? And then the rest of the script is just a standard, you know, a two of two multi-six script, okay? And the idea is that Alice builds these transactions, okay, signs them, sends them to Bob, okay? And sort of by signing them, she can control exactly which outputs Bob can produce and so that Alice can make sure that Bob can produce that reward output if and only if, you know, the function actually evaluates the true or next, okay? So essentially sort of the main lemma of the proof says that like my Turing machine will go from one configuration to the next configuration if and only if Bob can create such a transaction that updates sort of the encoding correctly, okay? So if and only if always means, you know, assume this and show that this is true and the other directions, you know, assume sort of this and show that this is true, okay? So first we're kind of gonna assume our Turing machine goes from this configuration to this configuration, okay? Then since Alice has sent these transactions to Bob, she, Bob can just use one of these transactions, broadcast them and sort of update sort of the state that's reflected on the blockchain according to the configuration. And like the other directions a little bit more scary, right? So because you have to worry about, okay, so Bob gets like some transactions from Alice, maybe can like rearrange stuff and do bad things to produce that reward output despite the fact that, you know, that he didn't sort of provide the correct input value, okay? But that's where sort of our signatures come to the rescue. So if you think about what these signatures actually do, okay, so this signature in green up there, what that signs is all the output scripts but also the input script that's getting spent and sort of these little errors here are essentially sort of the transaction hashes that are also in the transaction, okay? So sort of since, and so you can think of this as like, Alice by signing the transaction, she kind of protects what Bob can do. So she said, okay, Bob, you can broadcast transaction whatever you like, but you can only, if you wanna use my transactions, you have to spend that specific output, right? And that specific output sort of, you know, encodes the precondition and this encodes the postcondition. Okay, so this is gonna be, this is hard to parse in a talk, I'm sorry, but yeah, so that's kind of the basic idea. The signatures of Alice restrict Bob so that he cannot do bad things, okay? And then the second signature on the right here sort of protects sort of the other half, okay? When I was doing this, I was always afraid that something might go wrong, but weirdly it's almost like if this construction wouldn't work, then Bitcoin would be insecure, right? Because then someone else could do something bad too. So, I mean, I'm pretty confident it works, okay? Yep, okay, so related work, so this has been conjectured a long time ago by Craig Wright, okay? And so actually in 2015, Craig Wright was the first to claim that Bitcoin is still incomplete, okay? So needless to say it wasn't received very well back then, okay? But it turns out that, I mean, I think he's completely right on this one, okay? So, and then Craig Wright has done a bunch of more interesting work on this kind of stuff. So he, I mean, he conjectured this in 2015, is at least, so I talked with Craig about this a bit, or actually a lot. And so he showed me like several of proof, there's different ways to prove this. And Craig has different versions of this proof. And also very interestingly, Craig has some work on what happens if we remove the restrictions on the lengths of the script, okay? And what that does is it really simplifies the construction a lot. I don't wanna talk about that. But if you wanna hear, ask me, okay? So just to wrap it up a little bit, we have shown that the spending condition in Bitcoin can be arbitrarily complex, okay? I can say I will pay you if and only if, certain condition is true. The condition can be as complicated as anything that can be computed in any computer with Java, JavaScript, any high-level programming language. However, and that's kind of the weird thing because in computational theory, is like, during competence captures like a notion of everything that can be computed. So at first, you think, okay, now we can do everything that we can do in Ethereum, but actually we can't. And so specifically something that we cannot do right now is mostly tokens, right? And to do tokens, we have to add something to Bitcoin, which has been discussed a lot here. There's different ways of doing it. There's OP Group and there's Bitcoin Covenants. And so I think like midterm, we should figure out how to add this kind of stuff, but we also have to figure out how to do this in like the nicest possible way pretty much, okay? And sort of the idea of all these things, OP Group and Bitcoin Covenants is really what you want to control is sort of future outputs like that spend your output, okay? So if I like encode a token, I must prevent the situation that like, some person owns a token for him to just create a Bitcoin transaction with two outputs. Now he's turned one token into two, okay? So that's not a good token because anybody can create as many tokens as they like. So if you wanted to do tokens, what you need is, you need some way to control future outputs of future transactions and it must be done sort of indefinitely, okay? I must say like any future transaction that spends my output, I must be able to like control how they work pretty much, okay? I think this wraps it up. Thank you very much. Woo! Yeah. Hard core. Yeah. All right. Okay, this is history being made here, all right? This is the first presentation of Turing completeness in Bitcoin and Bitcoin Script. Can we give this guy a second round of applause? Woo! Not ready. I am not ready for this hotness. Okay, we have questions. All right. So my question is, I just lost my notes, it's okay, I remember, my question is and I'm sure you would agree that there is a difference between something that's theoretically Turing complete and something that's practically Turing complete. So my question is, what is practically possible here? So if I were to use an example, would it be possible to create DAOS over Bitcoin? Like as an example? Okay, so I'm not going to be able to answer that question like live on stage because I haven't thought about it, but just coming back to your point, so you make it an important point. There's like, you know, like there's this theoretical result, okay, and then it's like what is convenient in practice, right? And what I'm presenting here is not necessarily a very, you know, convenient way to, you know, program Bitcoin. There's several things to think about, like, so we have, you know, some smart contracts, you know, like, you know, HDL season, you know, payment channels and stuff like that, and they all use very, very short scripts. So for many, many things, you're actually not going to ever need to like, actually use a while loop, okay? And then sort of for, to make sort of programming shorter computations more convenient, it's very important that we like activate opt codes and just sort of develop a nice programming language, okay? So in the long term, probably to make this, this kind of approach more practical, what we need is we want people to write smart contracts in an extremely well-defined, higher level language, okay? And then we're going to use compilers that kind of compile this higher level language that people understand into a construction like this, okay? So in a sense, it's very, it's not some more work to be done on this, but this is, I think, the direction, like, on the one hand, make like programming scripts small scripts, more convenient by adding more opt codes, and also then, you know, in the midterm, start thinking about how can we actually build compilers where, for example, you can think of, you know, just, you know, your higher level language could just be, you know, a bit conscript and you add a loop and construct to it, right? And then you have a compiler that, you know, takes that higher level thing and compiles it into this, you know, mechanism that keeps broadcasting the transactions while you enroll them. Thank you. Thank you for your talk. What are the security implications of having Turing-complete Nets in Bitcoin Cash? Because potentially you could do nasty things, right? If it's Turing-complete. Yeah, great question. So essentially one way to phrase this, I mean, can this be used to sort of create DDoS attacks, right? And so in theorem, you know, family has, you know, Turing-complete scripting language and they need this outside mechanism of gas, right? To control, you know, if your computation takes very long, you know, you have to just pay the miners more fees pretty much, okay? And like the nice thing kind of is, is that is like almost built into Bitcoin already here, okay? So if you see this picture, I'm sorry, too many things, okay? Every, you know, broadcasting one transaction is like, you know, doing one step on the computation, right? And for every step in the computation, you have to pay one mining fee. So if, you know, your computation takes very long, you know, Bob's gonna have to pay, you know, a high mining fee pretty much, yeah? And the same thing is true if you wanna encode like large amounts of data. So the nice thing is in sort of Bitcoin doesn't need this extra complexity that's in Ethereum, right? It just sort of naturally has like a beautiful cost model just built in, which is actually kind of cool property. And then like just in terms of like systems design, I always think like if you want to like optimize things and scale things, it's good to have like an extremely, you know, simple base system because simple systems are just easier sort of to optimize, right? And so that's why I'm of the opinion it will be easier to scale Bitcoin than Ethereum just because you're working with a much, much simpler model pretty much, yeah? So this actually kind of a nice property here. God damn, we don't need gas. Woo! I'm telling you people, I love this. Okay, who's next? Patrick. Thank you. So yeah, everybody's addressed the sort of the downsides of data bloat and you know, we're assuming we'll get infinite or unbounded block scaling and it won't be an issue and that's fine. So I'm gonna try to be a little more constructive. I'm imagining how operaturn codes could be part of this soup of state and how those operaturn codes in a balances base system could give you tokens and it can also give you all kinds of contingent logic that could be built into the client or perhaps we could come up with a more modular system and you know, what you're dealing with here is you know, if you were to write it in a basic high level language, you'd want to keep it to like 10 lines of code, you know, a few simple logic things, right? Or otherwise you're gonna get into this kind of recombinative explosion of UXTOs and fees associated. But I think there's an opportunity here to integrate with a lot more complexity for things that are kind of you know, templated, tried and true. Here's the code, here's the TX format for the opt code that references it. And then combining it with these contingent logics, there's a lot of variability there. So I guess my question would be, have you considered that side of things in this exploration? Okay, so I'm not 100% understanding the question, but so maybe the question is about like, what kind of opt codes do we need to do this kind of thing, right? Do we need to add more opt codes to you know, to make Turing-complete as possible and actually we don't. And the surprising thing is we actually like, Bitcoin remains Turing-complete if we just have a very small amount of opt codes, right? So I'm claiming here you can do any computation with just you know, check multi-sig addresses and pushing stuff onto the stack, right? So you can do everything with an extremely, I mean you could technically restrict Bitcoin script very much, you know, remove lots of these things. I'm still gonna be Turing-complete. But the thing is kind of goes back to what I said earlier, right, just because something's like Turing-complete in like an awkward, complicated way. It doesn't mean that like people wanna write these kinds of programs. So to kind of write convenient programs we wanna like have you know, beautiful expressive based language pretty much. Awesome. Next question. Gentlemen, you're looking at me so earnestly. Hey, thanks for the insight and the presentation. I was wondering how it would be tackled if it's unsure if a mathematical formula I express and I would be ready to pay someone a Bitcoin if he solves it. What is the approach? If it's an unsolvable problem. Is it just if else with a check sequence verifier is there like a nicer option maybe? Okay, so if it's like an uncomputable problem we can't do it in Bitcoin or Bitcoin script. I would lock the Bitcoin in that output but since it's unsolvable there would never be a solution provided. Yeah, okay, okay, so maybe this question, like what happens to computations that do not terminate ever, right? And so in this thing, so this really actually kind of neatly corresponds to just normal computations, right? So you see on the left here you have just your normal computation. Like this is just an example of a computation that terminates and in an accepting state too. Okay, so this is as soon as I didn't really mention that but as soon as the Turing machine hits this accepting state computation ends and it just accepts. Of course Turing machines can also just loop forever like we all know, right? So you can do three things that can accept, reject an input or loop forever. Okay, so what happens if like the Turing machine just loops forever? And then like this, you know, Bob would have to like continuously broadcast these transactions forever, you know, which would be no expensive and stupid, right? And then assuming that Bob is not stupid, what Bob would do is he would like, you know, cheaply running computations on your computers way, way cheap compared to running stuff on the Bitcoin, right, on the blockchain. So what he's gonna do is he's just gonna run this computation on the particular input on his own computer, figure out, oh, whoa, you know, this doesn't terminate, right? So then, you know, Bob's not gonna be very motivated actually ever bought us something. But what's the process then of recovering that Bitcoin that I was ready to pay someone? Okay, so this is this thing here. So Bob can eventually sort of, sort of the construction makes sure that like, Bob can only produce this reward output if the computation terminates and in an accepting state, okay? So if the computation doesn't ever terminate, Bob can never produce this reward output and he can just never claim the reward, right? So maybe the answer to your question is like, if the computation either rejects or never terminates, then Bob gets nothing, right? So Bob really only gets paid if like the, like the people would say the word is in the language, right? Or like the computation is finite and ends in an accepting state. I just mean that Alice wouldn't get the Bitcoin back then either, right? That is true, yeah. So Alice should better make sure to only be interested in the- So I was thinking if you wrap that in the, if else with a timeout like a check sequence verify it then you could like say, that's if you managed to solve this in a year, then I don't know if that if else could be chained through all those transactions and how that would influence the size. Thank you for giving the answer that I didn't give. That's exactly right, okay? So what Alice could just do, you know, if eventually there's some sort of timeout and like in here or something like after months. So this output could just say, okay, I give Bob three months to produce this reward output if Bob doesn't come, you know, doesn't do it after three months. You know, I just, I just spend it to myself. One last question. Thank you very much. If I can just distill what essentially what you're saying is that you've proven that it's possible to do smart contracts and all the implications of that on the Bitcoin cash blockchain. Yes, it was one caveat. I mean, weirdly, we cannot do all smart contracts, right? So in particular tokens is something we cannot do. So I think like auctions and voting is something we can do with a similar technique like this, but tokens we cannot do, right? It's the whole concept of machine-to-machine communication or machine-to-machine communications or a machine producing something in the event of receiving something else from another machine. This is all possible to be done on the Bitcoin cash blockchain, if I understand correctly. Well, so maybe this is the question but like how can we external data into the blockchain? Is that what it's about? I'm just saying that essential use case of this touring completeness as opposed to is it not essentially not just being just the form of currency, but actually a form of machine-to-machine communication or independent machine-to-machine communication. Yes, yes. I mean, so I think you can just pretty much just think of, you know, Alice and Bob instead of being humans just being like computers, right? And then one computer, Alice, could send transactions to Bob and allow him to do things, right? And then actually you can build really, really complicated things here. So I'm always trying to make the most simple case. I'm trying to like almost control the complexity that's in Bitcoin, right? You can come up with much more complicated settings where it's like multiple actors, multiple computers that send data to one another, get worded for certain data and stuff like that. So I think there's like some progress in that direction maybe. Okay, thank you Clemens. Awesome presentation. Thank you.