Great Script Restoration

Hi everyone, welcome back to Stephan Livera podcast, brought to you by Swann dot com, the best place to buy Bitcoin. Rejoining me today, and it's been a while, is Rusty Russell from, now he's working at Blockstream, known for his work on the Lightning Network, both at the protocol level, and also he's joining me today to talk about the Great Great Script Restoration. So, Rusty, welcome back to the show.

Thanks, Stefan. Great, as you say, it's been a while.

Great. And so, there's been a lot of talk, off of the recent Bitcoin plus plus. Now, I did host an episode with Brandon Black, aka Red and Code, and we, we, we touched on some of this stuff there as well, but we're gonna-- for this episode, we're just gonna assume no prior know-- or little prior knowledge, and, let's sort of get into this idea of Great Script Restoration Why do we need it? Do we need it? What does it enable? All these kinds of things. But it might be a good spot for you if you could just, for the non-technical but, let's say, Bitcoin interested person, what's, you know, what is the relevant part we need to know about Bitcoin script before we sort of have this conversation?

Yeah, no, that's, that's a really good place to start. so, most people know, you know, Bitcoin is a list of, of transactions, right? and particularly important ones As we say all the time, so the unspent transaction outputs, and each of those outputs actually has a tiny little program attached called script, right? That's the name of the Bitcoin programming language. It's very simple, and most script is basically just, you know, check that has a signature that matches this key, right? so anyone who can sign can, can spend it. But there's actually a whole little language in there, more than just CHECKSIG, which is the CHECKSIG operation. You can have Other, other things in there, Satoshi actually implemented a full stack based language, and you can attach, like, this little program on the, your UTXO. It's like, "Oh, if you can make this program happy, you can feed it things to make it, make it give the thumbs up, you can spend, you can move the coins, right? Your transaction is valid." and usually that's just, you know, check sig, but it can be, it could be anything, and that was a fundament of Bitcoin, that it'd be programmable money. This

Necessarily control, you, you can put your, your pre- prerequisites. If you can meet this, you can spend the coins, and then it's out in the world, and that's enforced by the network. So that's, that's what script, Bitcoin script is, and that's kind of where you have to start from if you're looking at, you know, talking about it

Yeah. And so I suppose the next question would be, Satoshi disabled a bunch of these opcodes, I believe it was in 2010. This was a CVE, there was a vulnerability around this. It was related to, from my understanding, making scripts that can, let's say, DOS somebody's node or kind of take it down. Could you explain a little bit about that? Why did Satoshi disable all these opcodes in 2010? Why were they seen as insecure?

Yeah. So this is, originally there was the fourth language that The little kind of stack based language in, in Bitcoin was really complete. It had everything you would want, expect from a language, right? the problem is it actually had no limits on it, so you could say, "Hey, you know, take this number and shift it a billion bits to the left and make a huge number, right?" And next thing you know, you've run out of memory. You take these two things and, and join them together, well, you know, and now duplicate that and do it again and again and again, you know, increasing by a factor of two

Yes, you could take, most if not all nodes offline, just, just try a denial of service them. And of course, some of them are just slow too. You could ask it to multiply or divide huge numbers, Even if you didn't make it run out of memory, you could probably slow it to a, to a crawl. So Satoshi did what anyone would do at that point, looking at a network that's potentially, you know, one, one, one match away from exploding on fire, and just went through and just disabled fifteen opcodes. he went through and kind of went, right? you know, and, and I've been on the receiving end of, of these kind of critical vulnerabilities before. You, you know, you, you don't worry about the water damage, you just put

Struck out a whole heap of opcode so they don't, they're not valid on the network anymore, of course, as a soft fork, and, also restricted numbers. So in the original Bitcoin script, we had arbitrary length numbers, right? You could have len- you know, h-however big a number you wanted, and Satoshi went, "Look, we're gonna cut it to four bytes, which is, you know, thirty-two bits. So it's actually thirty-one bits 'cause there's a sign bit in there, " and he just kind of went through Very much that emergency response mode that you do when you've got a critical vulnerability, that could take down the network. Of course, right? and, and for very good reason. but you know, here fourteen years later, we're still kind of, we've got- The weird remnants of, of the programming language that are left, after Satoshi went through and disabled some of them, some of them it's not clear why he-- Well, I think it is clear why he disabled them. He just went, "I don't know, I, I can't immediately look at that and go, "It is not exploitable, so I'm gonna throw it out." Like left and right, the ability to truncate, you know, something on the stack. That it seems like a weird one, but Satoshi just went through anything like that and, and, and took it out. So, yeah, we've got this language now that is kind of a weird, not, not a subset anyone would have chosen, right? Not by design. We've got, a kind of a very, very weird, Cut down kind of hobbled language left. so yeah, that's what happened in twenty ten. Yeah.

And so maybe if you could just spell out, because again, some of this stuff can be a bit esoteric for developers, could you spell out what are the implications of having a, a gimped version of script? What does that mean for us?

Yeah. So, For, for most, you know, for simple Bitcoin usage where you just wanna check a signature, that's, that's, that works, that's fine. But as we, you know, a-as, as Bitcoin matures, we discover more things that we actually wanna do in Bitcoin Script. The programmable money side is starting to come to the fore, and people are thinking, "Hey, we could create some really good scaling opportunities and, and other tech on Bitcoin." Except now you're really starting to notice, right? The kind of, the, the missing parts of Script.

Of getting around that, but they're all kind of ugly, right? You can't just do the obvious thing because that's been-- the, the thing you wanted to use is, is to say, for example, multiplying two numbers or dividing two numbers are, is, is gone entirely. dealing with Satoshi amounts, right? Satoshi's can be more than thirty-one bits, that's only twenty-one odd Bitcoin, right? which, you know, look, doesn't worry me. I'd, I'd love to have that many Bitcoin, but it's a problem. But there

We, there are some things we would love to do in Script, and when we look, we go, "Oh, right, okay, that's, that's gone." And so this has kind of been an increasing-- you know, it started as quite an abstract problem, but when we look at things that people are trying to do today, on Bitcoin, they're hitting this more and more, and so there's a sense of frustration, which is why we're seeing a lot of proposals to, to do more, you know, to do more things with Bitcoin. Bigger numbers so we can fit a whole number of satoshis, and operate on that. These are another thing that, that definitely, definitely people wanna do.

Great. Okay, so now, if you could explain the premise of Great Script Restoration and just talk to us a little bit about that, explain the context of it.

So, I was looking at the, there was a proposal by Ethan Heilman, and a few others to bring back OpCat, and it's like, okay, so OpCat is this really simple thing and basically says, so Bitcoin is a stack language, you've got like the stack of values and you can add numbers, add the two top numbers, put it back, right? You can pop the top numbers off, you can switch them around, you can, you know, you can do all these things, right? but one of the and it turns out that that's actually incredibly useful and let us build a whole pile of things, that many of which we didn't even know about, back in, back in twenty ten, but a lot of people have done a lot of hard thinking since then, and they would love to have it back. And Ethan's, proposal limited the size of OP_CAT to five hundred and twenty bytes, which is the limit that Satoshi put in place, when, doing this, this, this, you know, emergency action in, in twenty So you can only have up to five hundred and twenty bytes on the stack. There's nothing in script that will let you make something bigger on the stack, and that was the limit of anything you can start with. So that was a cap. and I looked at that and went, "Huh, why, why five twenty? That seems like a weird number. Why? It-- That's surely gonna, like, that, that, you know, that's gonna limit us. Why limit yourself to five twenty?" And you start looking through this, you're, "Oh, there are good reasons

You know, you can make giant things, right? you can crash the node by going, "Just give me more and more and more." So then your problem becomes, so I'm looking at this and go, "Well, is-- can we come up with a solution to this?" And if we can come up with a solution to this, it makes sense to go, "Well, let's use that same solution now to fix this problem properly, bring back the fifteen opcodes that Satoshi disabled, give us back arbitrary length, you know, no more, no more thirty-one To restrict abuse of this.

I see. And so that's the overarching idea, and in terms of what would Great Script Restoration Enable, like what kinds of things, you know, are possible. Now, of course, I understand there's also a level of-- and you've spoken about this, there's also a level of humility in terms of not knowing exactly what's gonna get built because it's programming. But if you could just sketch out some ideas of what you see Great Script Restoration enabling?

Yeah. So, yeah, to your first point, this is, this has been my entire career pretty much is building tooling for other developers to build, you know, incredible things on. And I-- that, that's been Incredibly rewarding, right? I spent thirty years, working on, you know, software that I give away, and other developers would take that and, you know, whether it be Linux or some other project, take that and build things that I couldn't even imagine, right? So, there's a lot of proposals out there to build things that, that sound amazing and incredible, some of which I even understand, but there is, some of the things that, that people are definitely eager to do are things like vaults, right, where you can specify, what, exactly how something can be spent, you know, i-in the sense that currently you can basically specify with your coins that, you know, you can have a valid signature and you can specify some time delays and things, but you can't really say, okay, you can spend this to this one place, that's, you know, you, you can control the destination and things like that. doing that properly gives you, These vaults where basically you can force on-chain actions so that you have a chance to claw money back if you lose your keys or something like that. Now, I'm not a huge fan of vaults personally, 'cause I don't think, you know, for me it would just, you know, it, it slows things down, it means you've got to keep two keys instead of one, all those things. But if you're a, you know, if you're a custodian, and I don't think custodians are going away, I would absolutely want you to use something like this So that's, that's one thing that I think is really promising. But there are a whole pile of other things that people have come up with which are much more abstract, and these address what is going to be, I think, the story of Bitcoin in the next decade, which is Scaling, right? We c- not everyone can afford to have UTXO. What, you know, technical methods can we use so that as many people as possible can have as much? Self custody is possible, right? So to some extent, if you can't have a UTXO, you can't have full self custody, but what does that mean? There's a whole pile of trade-offs there, right? If, if you can set things up so that a custodian can't steal your money, but Perhaps they can, you know, the, the, that, you know, you can set things up so that at, at absolute worst, you know, they can burn your money, right? but there's, there's no benefit for them in doing so, and it will be expensive for them to do so, right? If you can penalize them in some way, even if the amount on chain never makes sense for you. So if you don't have enough Sats to ever pay fees Right? You're never gonna get a UTXO, or if you did, the UTXO is useless because it would cost more than itself to spend, right? We are headed into a world where this is gonna be the case for a huge number of people. so there are a lot of really interesting designs on- Having, having this, this compromise method, right? What's the second best thing to being able to enforce your rights, and that is being able to either enforce them as a group, so some subset of you can band together and you can take, you know, take your sats that way, or, you know, if, if there is some entity, who has control, you can stop them from ever spending them, even if you can't get them yourself, right? So These, these kind of constructions are really interesting, and they require fairly complicated, on script, dances. and as far as we can tell, they aren't quite possible with script today. pe-people are really clever and they're coming up with, with great ways of doing some things that are, that are unexpected, even with the limitations we have. But certainly they're made a lot more complicated and perhaps sometimes infeasible by, by the limits that we have. and just, just from a, a meta point of view, right? Doing something and workarounds and stuff, that's always inferior to just being able to say what you want, right? If you can write a little program that says exactly what you want, that's obviously better. It's better for you as a person who can verify it and go, "Great, that, I know that does what I want. I'm not using some strange zero knowledge bit VM." You know, there are, there are layers of tricks up here, that people have come up with. But it's also important because even if you don't use them, if

The five little opcodes that they wanna use, they have this, you know, five hundred opcode monster that they put on chain. that costs them more, of course, but it also reduces the space for things that you wanna do And I think, you know, there's definitely a strong efficiency argument, even if some of these things are still technically possible, with Bitcoin Script as it is today.

Interesting, yeah. So what I'm reading from you there is a multi-prong thing. It's functionality, things are being enabled that aren't possible today, and even in the case of functionality There's efficiency gains as well, and so if we're talking about, okay, there's only gonna be two hundred and ten thousand blocks a year, and you, in order to realistically participate in Bitcoin, you need to be able to get your transaction confirmed into the chain, and the efficiency win Is gonna enable more people to be able to self-custody Bitcoin, hopefully, right? Even if it's not eight billion, at least we're gonna, we can sort of raise that number and make it at least better than what it was, is, I guess, the idea. and so in terms of functionality, you were spelling out some different ideas there that relate to, now, there's different ideas today that what that might look like. So coin pools, some kind of arc, some kind of maybe in Lightning, maybe like some kind of multi-party Lightning channel, sort of- Construct. There's different ideas on what that might look like, but I guess to your point is that's where these-- the increased scripting ability is required to sort of manage the complexity of all these people Sharing a UTXO. Now, there are some people who would say that's, that's already, you know, Lightning is already super complex. Is it even feasible to go beyond that and even do UTXO sharing?

Well, it's really interesting actually. one of the, the software Rosetta has been around for quite a long time is this idea of any prevout or, see cash no input, as it was called before then, which is a very simple change to Bitcoin, where basically, the signature when you do a check, say, can say, okay, yeah, but I don't, I, I will, I'm not gonna commit to exactly what, you know, ex-exactly what transaction I'm attached to. it's a fairly simple change, and it's very, very useful for Lightning because it actually makes Lightning simpler, not more complicated, and also then opens the ability for us to do multi-party channels

On there, but the idea of multiple people sharing a UTXO is going to be one of the ways in which we're going to scale. And, you know, I, I, I would love, I would love to make lightning simpler, by having a soft fork like that, but, you know, that's just one of the ideas, that people have, and there are multiple ways of doing that, certainly, enabling, you know, and, and, and, and this is the thing, there's a broad number of proposals that would

You would want in here, a couple of trivial things that you would also want to add, that aren't just taking script back to the way it is, or the way it was. there are a couple of other things that, you know, script has moved, we have, we have Taproot and things like that. There are a couple of other things that Satoshi probably would have put in if we'd had Tapscript, and Taproot trees, in the beginning. So there's a couple of trivial things that I think are fairly non-controversial. To add, and then this is where, as an example,

great script restoration also includes TX hash, right? As an example.

So I see great script restoration as a foundation, right? Let's, let's just get script back to a full programming language, and then we look around and go, right, now what do we actually want to top of this? Because what great script restoration, in particular, restoring OP_CAT does for us is allows you to do things like TX hash, just incredibly ugly, right? it's now technically possible, right, to do it. but, and that, and it's, it's one of those, you know, so very clever, but you'd never wanna see this in the wild, right? So there, there are ways to use OpCat to, to basically do introspection, for example That, that's great, and if we had that today, I imagine there would be people using it, but probably not for serious things because it is just so, horrifically ugly, and not only ugly, but costs a lot on chain to do, right? very expensive. So if we're gonna enable this anyway, then we can have a really mature conversation about, "Well, what's the cleanest way of doing it?" Now we have a clean foundation of script, we can do these things. is there a clean way to ask about the transaction you're in? and I think that seems like pretty straightforward. Now we can deal with it, because previously, even if we'd added that, we'd have the problem of, oh, well, we can't deal with the amounts 'cause they're bigger than thirty-one bits, right? the numbers are the wrong format, and version's the wrong, you know, there's, there's a whole pile of problems if you haven't fixed script in the first place when you look at this, So, you know, doing, doing, doing arithmetic on amounts, that makes perfect sense. You wanna say, "Cool, I want you to spend one percent of it over here." Well, you can't divide. So, and you can't multiply, right? you can still do it, you know? Almost. yeah. I think like

hack workaround way of- Yeah, you could do enough

ads, you could do like a hundred ads, you can actually do more than, you know, yeah, you could, you could do, you can do stuff, but really it's, it's, it's too ugly to live. Just, just give us back multiply an ad and then suddenly it's, oh, okay, well that's, you can say exactly what you want, right? So this is one of those examples where- It, it clarifies our thinking, right, over, of what other changes we would want, 'cause we go, "Okay, well, now we've got full script back, what else makes sense?" And some of the hacks that were involved in these modifications go away, right? Because you now have a system where you can go, "Cool, well, we can hash arbitrary data, we can do all these things sanely and cleanly." We don't need to extend the, the particular, change that you're proposing to try to handle those cases that we can't.

Yeah. And so another question people might have is, would Great Script Restoration break any existing scripts that are in use today in, say, Lightning or some other thing?

No, absolutely not. Firstly, because it'll be a new tap, tap script version at the very least, right? so there'll be a new tap script version that we'll use in unlimited numbers and, and, and have, have other limits, on it, and we'll remove a number of limits that already exist, re-enable all the opcodes. So that, that's, that The idea with, with limits is to set them such that you can never really hit them, and we have one like this already, with, SigOps limit, in TapScript. Yeah. Could you

just explain the SigOps limit? I was about to go there, yeah. Yeah. Yeah.

so, so originally, part of, I think the, the twenty ten CBE, Satoshi went, "Oh, crap, well, we've got signatures, right? They can take a long time to check. What if you fill a script, you know, or you fill a block with all these, you know, all these checks, right? " and so he went, "Okay, Twenty thousand, he goes, "You can, you can only have twenty thousand checkseeds in a block." now that's painful actually, because if somebody puts nineteen thousand nine hundred ninety-nine checkseeds in one transaction, and you're a miner You have to be really careful building the block, 'cause you've only got one left, right? So you're not only just trying to optimize for fees, you're also trying to optimize for how many check sigs they can use. now we changed that for the exactly that reason, to a much Cleaner scheme, in Taproot, where basically for every fifty bytes you get one jekseck. So bigger transactions get more, small transactions get less, and you can never violate that rule, Stefan, because, A signature is sixty-four bytes, right? So you've always got fifty bytes, unless you're checking the same signature over and over, in which case, you know, what the hell are you doing, right? That starts to look a lot like a DOS, right? So, The, the SigOps limit is a perfect example of a, of a great limit that prevents denial of service, but doesn't actually prevent you from doing anything that you would want to do. And the idea of great script restoration is to introduce a limit that prevents you from, from denial of servicing the network and you know, running people out of memory and all those things. But doesn't prevent anything reasonable that you would do, right? Obviously, you can hit the limit if you try hard enough, but anything you actually might write, script, and certainly anything in miniscript or something like that, wouldn't really even have to worry about the limits because they're so high, because computers are actually really fast, right? but if your model is correct, they're so high that you never have to worry about them, unless you're doing something really strange. In fact, you mentioned Ryden Code, on an interview previously, A version of RSA in Script using restored Script, and RSA involves, you know, five hundred and twelve bit numbers, you know, really big, big numbers. but the ability now to add them, and, and even, and multiply them and divide them is something that's enabled in, again, in Script. And even he couldn't hit, did, did not hit the draft limits that we had for the, the, the, the restored Script. So I'm fairly confident, I mean, we, we, we still haven't finalized the exact numbers that'll be Really high, and that the vast majority of people will never even know there is a limit to hit.

I see, yeah. And so if you could also explain now, as I understood from your talk, you were talking about this idea of this concept of VAR OPS, right? So it's kind of like you were contrasting with SIG OPS historically, and at least currently, that's what we have as a limit, as you said, I think it's at the block level, and so would-- could you explain a bit about VAR OPS? Does it apply at a transaction

What is Virops?

So Taproot changed Sigops to a per input level, right? with- Oh, right. Okay. Yeah. Sorry, it used to be a block level, and then we're like, "Oh, actually, it makes more sense to be a, you know, an input level." VarOps is probably a transaction level thing, we'll get to why in a sec, but it's the same kind of idea. Basically, you get a budget, and every operation you do, reduces your budget, and if you hit zero, you're, you're out of luck. Okay? the budget initially depends on your size, you know, you've got, you know, you're pay-- but effectively, you're paying more for your, your transaction, you're filling more of the block, I'm prepared to spend more CPU time evaluating you. So you look through all the different things that you can do, because, if you look currently, because you can only have five hundred and twenty bytes on the stack, the most expensive thing you can do is actually hash that, but it's very small. It, it fits in your cache really nicely on your, your machine. It, it, it's very hard to make your machine work up a sweat other than for signature operations, using Bitcoin script today. If we take those limits off and we start going, "Well, you can put much bigger things on the stack,"

You hash it, you know, you duplicate again, you keep hashing it. How much, you know, how much time could you, you consume? And so it turns out that the critical amount for every op code that we have, and our op codes tend to be pretty simple, is the size of the, the operands they're operating on, right? If you're doing small numbers like you, like you were previously, you know, that's actually really, really cheap. If your numbers are really big, if you want to multiply a few thousand digit, numbers, well, now it You know, start, start hitting these limits. so it's a fairly simple exercise to have a model that takes into account how much memory you're using, right? Well, this one's got to read these two things off the stack and write one back, okay? Well, that's, you know, you can figure out what the worst case for that is, and you go through all that, and then you do a cold pile of benchmarking across a broad variety of different machines, and you say, okay Here's how slow you could be doing a block today. Let's not make that any worse, right? Because remember, you could do eighty thousand check sigs in a block today. So how long does it take you to do that? Okay. That's our upper limit, right? We don't wanna make it worse than that. Okay, so that, and, and knowing how fast your machine does things, we can go, okay, well, that means for you, this would be the number, and we can look across a broad variety of machines. And, and come up with a, with a really good answer for what the actual costings should be. But the model's pretty simple, and it's basically how much memory you touch, because in-- when you deal with large objects, that tends to be the restriction, other than hashing, and of course, signatures is a different thing, other than hashing. We don't actually, the CPU things that, that script can do are pretty simple, like they're adding stuff, multiply and divide are probably the most complicated, but most things are like, and these two, you know, combine these two numbers together, concatenate them, they're very simple operations, so it all comes down to the speed of memory. That means that we can build a pretty simple model that says, okay, this is, this is how many bytes you're touching, therefore this is the cost. And that seems to work reasonably well. we need some more benchmarking. In fact, I'm writing a little tool now to distribute for people to benchmark on a huge number of different machines so that we can see, you know, what the range is and see that that model does actually make sense, not just on my laptop, which it works really well on. Yeah. So this, this is kind of where we're at. We need this variable limit, and then we can remove a whole lot of other limits because we've got this limit in place. In particular, the five hundred and twenty byte limit that we have on the amount of data you can put on the stack starts to look pretty cozy if you're dealing with things like OP_CAT and doing other complicated things where you, you can actually- Once you unleash script, you can do some amazing things, so you don't wanna start bumping into these other problems that, you know, you've left this other limit in place. obviously, you know, the block size limit stays and all those other things stay, But, you know, we, we can remove a number of limits that we have and rely on this one barop limit to constrain everything, and the evidence at the moment seems to be that it's gonna be so high that I don't foresee anyone actually running into it unless they're trying.

Back to the show in a moment. The lead sponsor of this show is Swan dot com, and Swan has a mission to onboard millions of people into Bitcoin. I also work at Swan, helping on some educational content for the team. Now, the team have also put out a new version of the Swan Bitcoin application, which is available on your smartphone, whether it's Apple or Android. Now, this app has a really fast onboarding experience. It's now just a few minutes Minutes to go from zero to Bitcoin. So if you are standing there with your family or friends and you might have been having trouble trying to get them onboarded, well, try this now. Recommend Swan Bitcoin, and you can do this while you're standing next to them, they can click through, and most of them will be able to set up and do this in just a few minutes. Also, the team at Swan have rolled out a new promotion, there are zero fees on your first ten thousand dollars of Bitcoin buys. So this is a great way to go from zero to Bitcoin and in a guided and managed So reminder, go to your app store or Play Store and search Swan Bitcoin to get onboarded with Bitcoin today. This show also brought to you by Mempool dot space, the leading Bitcoin and blockchain visualizer. I use it all the time when I'm checking transaction fees and trying to understand what is the state of Bitcoin's mempool. You can search transactions, historical as well as unconfirmed ones, and also see a great way to visualize things across the Lightning Network, Liquid, mining, and so much more. Also, for those of you with an enterprise, they offer a mempool dot space enterprise program. So for those of you as part of that enterprise program, you might wanna get increased API limits, and you might wanna have increased access to the team in terms of feature requests. You might wanna have special branding in terms of how your custom instance of mempool dot space looks. So to sign up for that, go to mempool dot space slash enterprise. This show brought to you by coinkite dot com, the creators of the best Bitcoin hardware security devices such as the Coldcard Mark IV and the new Coldcard Q. Now, we use Bitcoin hardware security devices to keep our keys offline, our private keys offline. Now, the way these work is you can do that setup, write down your twelve or twenty-four words on those, the seed word cards, and keep that secure. Now, you can use this device to interact with the Bitcoin network using software such as Sparrow Wallet, Electrum, or Bep20 Desktop or Nunchuck as a few examples. Now, you have a range of security features that you can use with these devices, such as passphrase, you can use seed x or, or my favorite is multi-signature. Now, if you're starting in a basic way, just start with the device and the USB-C cable, plug it directly to the computer and use it that way, and then later improve your setup. But I believe these devices are great at helping secure your coins, especially as you start to migrate up into multi-signature security. But don't Be disheartened or don't be, scared away. They are accessible, and I think you actually do learn about Bitcoin in the process. So to get yours, go to coinkite dot com, use code Livera to get a discount on your cold card. Interesting. Okay, so, yeah, just summarizing, the idea is we're gonna-- we would hypothetically move to this concept of VRROPS, which is like a global level limit, and the-- I, I think the key point from what you were saying as well is to look at what's possible today and say, okay, we're gonna make it no worse than that, right? So if you're okay-- if you're already okay with what we have today, then theoretically you should be okay with this concept of the VRROPS budget, such that we've tuned it to the right level Even if somebody's trying to be malicious, those transactions will go outside the VRF budget and then therefore be, you know, declined, etc. Exactly. And so the concern as well is that, you know, and, and this is what you're trying to address, is this idea that- You wanna make it so that nodes can stay in consensus, like stay on the network, and of course, mining centralization. We're trying to make sure it's mining, you know, mining stays decentralized and that you don't need to be running a supercomputer in order to be a miner, right? Because obviously, we want it to be kind of Decentralized and the every man, like let's say the average retail individual can run a Bitcoin node and run his own Bitcoin mining rig, mining machines at home and not need to-- and this is kind of the concern that people bring up with, let's say MEV or let's say MEV, as Matt Corallo would call it, or centralizing MEV, as Red and Code would call it, that we wanna make sure we're not enabling that kind of thing. Oh,

absolutely. block, so in particular, it's the miners you're worried about, because miners attacking That are really, really slow to validate is definitely a concern, and you've got to have limits such that, that, that, that is not something you're opening. On the other hand, you've got to make sure that valid transactions don't start to have to worry about this, right? You don't wanna have to think about, "Oh, what are my op limits?" when you're writing a transaction. That, that's just silly, right? You wanna be able to write, you know, any normal like BIP script based or, you know, normal transaction, and then it just, Like there should be, like you should be able to have a high enough limit that you're never gonna bang your head on it, but low enough that it doesn't DOS the network, and it certainly seems, seems like that is the case.

I see. Now I'm not, let's say tech-technical enough to sort of understand, but I understand there were some who were maybe raising a question on how feasible it would be to create this Vairaops budget. Like, I've, I've seen some other developers who commented on this. I'm curious if you have any reactions to what they were saying.

Yeah, so Greg Sanders basically said, "Wow, this sounds like a lot of work." I have patches, it's not actually that much work. There are, in total, when you add all of it up, there are fifty-one different opcodes that touch things on the stack, because most of them, pretty much, because they look at things on the stack. and, but they break down to a handful of ways that they look at things on the stack, so you just kind of add a VAR OPS in there, and at the bottom of the opcode, you go, "Hey, did you go over the budget? If so, right, you're out." Which we already do for stack size, you know, if 'cause I don't, no one's asked for more than a thousand on the stack, so we'll stop there, right? Why change that? and we check that every-- after the opcode, we go, "Oh, you went over. If you've got a thousand one things on the stack now, you're out." 'cause the same way, you know, we, we run it. The only exception is add and-- sorry, multiply and divide, because they can actually, you wanna check the, you wanna check the costing before, because they can be Anything else you check afterwards, 'cause they're pretty quick individually. So that, that part of the code was, was really straightforward. I, so, you know, but that's a matter of looking at the code and going, "How, how bad is this?" the changing dealing with numbers is also pretty clean. so, you know, I mean, Greg was speculating and I've actually written the code, so I'm reasonably happy with, with what we've got. and I look forward to the getting to the state where we're actually reviewing patches. you know, I think the main, the main issue is then going to be what else do people want in with this at the same time? Once we've got this foundation, what else do we build? And I think there's gonna be a lot of backsheding over that. But the, the fundament of, of VarOps is basically the same as we do for SigOps. Pretty much, and so, I just-- there, there's no-- and, and this is the whole point about the great script restoration. This isn't a complicated proposal. It's, it's engineering work, and of course, you know, we have to be thorough and look through every possibility and make sure that we're, we're incredibly rigorous with it. But this isn't new cryptography, this isn't adding Merkle trees. You know, we've done far more ambitious things in the past in Bitcoin, and we've got far more ambitious proposals that people have made, and they

Engineering approach to, hey, let's, let's get the things back that, that we were originally supposed to have.

And while we're on the topic of, let's say, comparing different ideas, if this idea is to, as you said, do the, do the engineering work to make this safe and feasible, and it's, you know, it's kind of a, It, it could be seen as a big, or, or I guess that's also debatable, but would it be seen as kind of in the category of competition with some ideas like Simplicity or something like that?

So that's actually a really good question. I, I think the answer is no, because simplicity stands on its own merits of, of verifiability and provability even without Hobbled Script, right? It doesn't need Script to fail for simplicity to succeed. I think simplicity has a lot of promise as far as its analyzability and everything else that we're not really ever gonna get from Script now that said, I don't think it's an excuse to leave script in a broken state so that we can, so, so that, you know, oh, we're gonna have simplicity. I think there are a number of proposals, you know, people haven't simply been waiting for simplicity, and obviously, simplicity is, is, is fairly ambitious. It is a, real rethink of the fundamentals of how you should do script. And this is much more humble. Rusty Russell is, is, is brilliant, and I would never, you know, I mean, What we had. And I don't think the two are in conflict. I think it's more than possible that, you know, we will get improved script and we will still want more, right? that we will still go, "Huh, actually..." We really do want this, this, you know, much more capable scripting system. Even, even when script is brought back to its, its full potential, I think then we'll be able to do a really fair comparison and say, no, Simplicity is simply better. And that's, you know, to be honest, I've, my understanding of Simplicity is fairly, rudimentary. and I know there's a lot of really interesting tooling work that's going on at the moment to really make it approachable. So It may well be that, you know, we end up going, "Well, let's jump straight to simplicity," but I still think this is a worthwhile avenue to explore.

Yeah. And on the other topic of- Let's say smaller proposals, like hypothetically, right? And I know you're a big, you know, obviously you're a big Lightning guy. Hypothetically, if people were like, "Oh, let's get APO" or "Let's get LN Hanz." Would you also be in favor of those and still use those in the interim before we get Great Script Restoration?

I think that's interesting. I think, Great Script Restoration has given me a lens for like, let's look at the end goal. What, what do we want script to be? And so then I go, "Well, is this a stepping stone on the way to that, or is this a diversion? Right? Are we gonna have this weird thing that, oh, we had this because we didn't have, we couldn't do that properly in script, and now we can, and so now we've got this awkward thing?" some proposals, Have that property that they're trying to work around, you know, brokenness in script already, and some, some of them are quite clean themselves. So I think it's, it's given me a different way of thinking about These proposals going, "Huh? " and frankly, if a proposal doesn't mean you can't do in script, I'm like, "Why don't we fix script to do that? " That's, that's my natural like, "Well, hold on, you may not be the only one who wants to do this, this fancy thing. Why don't we make script do that? " And so, but certainly, I mean, APO is, is something that you can, you can do with checking from Stack and a number of other things if you combine them So yeah, you know, it's interesting. So, when we look at LN hats, for example, you know, Brandon came at this the other way, where he basically said, "Went, we've got several proposals, they're more powerful if we put them together. Let's kind of, you know, combine them and see if we can come up with a coherent proposal." And I came from much more of the other way, going, "Well, let's..." Let's fix script and then look at what proposals are left. And so, I think we were kind of slowly converging on a very similar effective result, and I've been having-- I had some, I met him for the first time, at, Bitcoin Plus Plus in Austin, and was, was very impressed. And so I think, you know, there's, there's gonna be a really interesting question of what, improvements intersect really cleanly with great script, great script restoration. And he's also been talking, with Stephan Russ doing the Hash work, because now we have the ability to hash arbitrary data, I really want something like OptiX hash to have a mode where I can just literally pull the values from the transaction that I want, because it, it makes sense. Now we've got the ability to handle it. So, you know, it, it has- thrown a little bit in the mix for some of these proposals, but they're all still very strong and I, you know, and, and have very clear use cases. So, you know, my principle is that which of these now still makes sense in a world where script is, is at full force?

Yeah, I see. so I-- Okay. And so, one other area you were touching on, it would be good just to explain that as well, introspection, right? If you could just explain, like, what is this thing? W-Why do we want it?

Yeah. So there's a sort of a fundament of Bitcoin and programmable money is that if you have a UTXO that you control, you get to dictate the circumstances, the context under which it gets spent, right? you know, classically that means you, you hold your, you know, you hold your key secret, and you're the only one who can sign for it, but- Script gives you the ability to do other things, and one of the things that, that you would love to be able to do in many cases is do,

Restrict the ways in which it can be spent, so not just if you have a signature, you can, you can, you can do anything. Now you can do some of this, we have a very limited, subset of this that was implemented with Check Sequence Verify and, Check Time Lock Verify for, Basically to, to make Lightning work well. But you can't arbitrarily say, hey, you know, if, if the, you know, if you wanna spend this output, you must send, you know, one sat here or, you know, one bitcoin here or half of it here or, you know, you can only spend to this address or you have to insert a delay of a week before you spend it and things like this. There's no way in script, despite it being, even restored script, once it's quite powerful, there's no inherent way to look at things. Now Is a really clever way of doing it because the signature obviously covers the whole transaction, so you can say, "Right, you must match this signature." you can't quite do that in Script today, because there's-- you, you have a problem of you have to commit to the signature and the signature has to commit, you know, it creates this loop, and you can't actually put a signature in Script, but with OpCat you can, and there's a great, Post by Andrew Polstra on Schnorr signature tricks, where he uses OP_CAT, to, to basically put arbitrary restrictions on using, using a signature. Hey, you must match this signature. And it's, it's really clever, it's, it's incredibly ugly, but it, it is possible. so there are methods of intru- so, so there are effective ways of, of limiting what the, the script can do. But the most obvious way is to have a something, a way of asking, "Hey, what, you know, what does this transaction look like? How many outputs does it have? Give me the amount going out, give me the address output one's going to, give me the amount going to output one." Literally having opcodes to ask these questions makes it much, much clearer, right? It's a fairly obvious addition to have, whereas the fact that we can technically do this by using signature tricks is, you know, People will do it if that's all they're given, but I do believe that I think, you know, it empowering people to, to control their U-T-U-T-X-Os however they want is kind of a key, Bitcoin ethos question, I think.

Yeah, and there could also be arguments around it could be safer, right? Like if it's kind of officially supported, like put, not officially, but you know what I mean, officially supported as opposed to you have to use all these hack ways and maybe there's more that can go wrong there.

That's right. And You have to feed in, rather than just something that says, "Hey, just check this, check this value is equal to this value,"

right? one other question I have is, in your mind, are you seeing great script restoration as a short term, medium term, or long term project?

Well, I don't think any soft fork is a short term project. you know, I think, yeah, fir-first you have the proposal, this, this idea of, hey, hey, we would like to do this, that, that's, I think, been attractive to people, which was a little bit disappointing for me, I was half hoping that people would thought it was a terrible idea and go back to work on Lightning full time. So I'm having to split my time now between Bitcoin Core and, and, and, and Lightning, and I'm actually trying to So, you know, I, I told my wife that next six months are gonna be hell, and the next two years are going to be a slightly lesser hell, because that's the kind of timeframe we're looking at. You know, once you've got an idea, then you've got to have a solid implementation. We have to do, you know, benchmarking, we have to make sure that we are happy with the model, that it can't be exceeded in weird ways, it has to be, you know, widely vetted. You know, we, we have to run on a broad

range You know, it's just a lot of data gathering and, and things like that. Then there's gonna be a whole pile of bike shedding over what else goes in. obviously restoring the opcodes is, is a good start, but then the fact that it enables you to do some things in really ugly ways opens the get door to saying, "Well, should we just make that easier?" And I, I have a huge amount of sympathy to that, and there'll definitely be people with proposals to go, "Hey, this, this, this merges really well," and so we'll have

you know, then, then we haven't even thought about what activation would look like if we got to that point, if it seemed like everyone was, was, was happy with it. I personally think that probably the consensus cleanup That Matt Corallo has been, you know, on about is probably my lead candidate for the next soft fork, I think it's fairly non-controversial. I, I think, you know, that, that would probably just sail through, and it would give us a, a chance to, you know, to, to kind of rehearse activation,

flex our activation muscles. Yeah, that's right,

you know? make sure we can still do it. and, and then perhaps after this we'd hit great script restoration. so, but one of the things that's really interesting for me about this is that once you have a restored script I like the idea of looking at what people are actually doing on chain and going, "Huh, okay. If we had this one op code, it would be easier. You know, they're doing this kind of convoluted thing. The script's fairly powerful, but, you know, there are definitely some things you could, you know, you could, you could turbocharge it if you wanted to. But we'll then have data because we can look at the, you know, what people are doing in Bitcoin and go, "Hm, there are a lot of people doing this. If we New feature, that would be more efficient. And at that point, you would support a soft fork even if you would never use it, because more efficient for everyone else means more room for you and the things that you wanna do. So it brings what is currently quite a nebulous debate sometimes about new opcodes down to a very clean debate over, well, how much efficiency does this gain us? What's the best way of doing that? you know, obviously if you think the usage is a flash in the pan and it's not gonna last, then you can have that debate, but if there's persistent usage of some particular way, if there's some complicated script That people are always using, perhaps to vault their coins or something like that, then it's easy to argue that that should be a first-class citizen, and we should have like an op vault that just does that, or even a new key type that expands to that, that complicated script. These are definitely rational Very, you know, number based debates that you can have once you've got a system where people can do all the things that they want to with script. And I certainly look forward to getting closer to that kind of debate than some of the debates we have today.

There has been some pushback on some of the covenant proposals because people are trying to say, "You need to prove out how efficient it's going to be." With great script restoration, is that possible? Is that plausible that you can sort of have a conversation about, okay, we're gonna have this great script restoration and it'll make us X more efficient? Can we, can we-- Is that possible or not really?

To some extent, it, it will let us do things that we probably can't do today, and some of the ones that we can do, it will make more efficient. I think what will actually happen is people will start using, you know, assuming that it goes through, we'll have people using it in, in ways we didn't expect. some of them will be stupid, right? I mean, that's always the case, right? There's always someone out there doing something dumb. you know, the, the root of all problems in the universe is people with more

The, the, but there'll also be some really clever things, and I expect then we'll go through the phase of going, right, okay, well, sh-should we, should we optimize that now because this is proving to be a lot on chain, if it turns out that, you know, everyone's using L2 and we've got a construction that allows L2, but there's, there's some case that could be made more optimal, that's definitely something that we wanna see. But the first thing is to basically enable all the, the use cases that people want,

I see. And so in terms of like testing this stuff out and kind of proving it out, do you see it, like, after you've done this kind of initial round of work, that people would play around with this in Signet and Inquisition and these kinds of things to sort of let them have their playground for great script restoration? Yeah, absolutely. I mean,

these days, Inquisition, I think, is the place to be, for, for really trying things out like this. I would definitely-- my, I have a, my plans to do a draft pull 'Cause there's some other changes that go in Inquisition that just make it, you know, not entirely trivial. so I've written all the opcode, I've changed the interpreter, which is what I needed to benchmark, but actually wiring it through and figure out, well, what does a-- what does this new pub, you know, what does this new script output look like and things like that is still very hand wavy. So That's definitely the path forward, and then people get to play with it and say, okay, well, this, this is good for this or bad for this, and we can then, you know, compare and contrast the different proposals and go, actually, it turns out, you know, CTV is really good for this use case or, you know, and, and that I think is something where we always have this problem with proposals that until the proposal seems to have traction, people don't really give it the attention it deserves. So you get sometimes feedback really late. You think,

It was gonna be, gonna go somewhere, do people actually start spending the cycles? So there's a bit of a chicken and egg problem there, but it seems like there's some momentum and people are certainly interested enough for me to take this to the next step.

Yeah. Now, on, stupid things, as you were touching on before with, shitcoins and scams. Now, this is more controversial, but many of us do view, let's say, inscriptions as spam and I view, you know, basically BRC20 and runes as creating shit The question will come, could this enable more shitcoins or spam on Bitcoin?

So more powerful script enables everyone. It enables smart people and it enables stupid people, and it enables scammers, right? It enables, enables people who are like, you know, genuinely trying to make the world better, and it enables people who are genuinely trying to make the world's worse. So yes, in some sense, yes, it will enable these people, but I don't think there's-- their limit is actually on the technical, right? I think, there are An uncountable number of ways of doing stupid or evil things, and I think that even if we would add some more ways of doing stupid or evil things, I don't think the total number of stupid or evil things being done will increase by this. But I do think the number of, of great things people do will increase because we've enabled those. So I don't actually think this is a technical solvable problem. I think there will be I think the fun-function of people doing stupid things on Bitcoin is a function of the, success of Bitcoin, right? as it becomes more popular, more people will go, "Oh, well, I should, you know, if you're the kind of person who does-- who, who tries to scam people, right?" You will, you will scam with the scammer using whatever hammer is there, and as Bitcoin becomes a more prominent hammer, more people will, will gravitate to it. you know, it, it was kind of an easy shitcoin segregation for a while where you go, well, that, that's, that's generally, I c- I can say, well, if it's, if, if it's an altcoin, I can assume that it's full of scammers, and it, it roped them off. But as they kind of die and, and Bitcoin comes to more prominence These people don't stop scamming, right? They just move. so I really think it's kind of orthogonal the question of technology. We certainly, I have a thesis. I mean, if, if there are too many stupid people in the universe, we lose. It doesn't matter, right? It really, if, if we get overwhelmed, if, if all bitcoins are stupid, it, it's, it's gonna suck, and I don't think it's gonna be very good. I think, I have to assume, and my experience has led me to

things than doing, you know, useless or, you know, outright scamming things. And as long as that's true, providing people with tools to do things better will be a net improvement in the world. and I'm- Definitely of that opinion about Bitcoin script improvements. If we make Bitcoin better, it, yeah, sure, it might lift some of the boats that we don't like, but it'll lift all the boats, and I think that will make things a better place.

I think that's a fair point, and I think, some of this is, to your point, some of this is gonna be at the social layer anyway, right? It's kind of like we're gonna have to defend the kind of true use cases of Bitcoin or the legitimate, non-scammy, non-spammy uses of Bitcoin Anyway, and I think it reminds me, there's maybe a parallel. People used to, sort of fud the CTV, idea by saying, "Oh, but the government could enable some kind of government whitelist, and therefore you could be trapped in some kind of CTV tree where only the government has the keys." But it's the same, people, and the rejoinder would be, "Well, hang on, that's already possible today with multi-signature. The reason it's not happening is because, again, it's a social layer defense to begin with."

So, but I think there's also gonna be, I have sympathy for the people who are gonna have to fight that social kind of battle or battle for ideas at least to sort of help explain to people, no, Bitcoin itself isn't a scam, it's that there are scammers using Bitcoin, just like with the US dollar, right? You, you know, there are lots of scammers who use the US dollar, right? So it doesn't make people stop using the US dollar. Yeah.

And I think actually,

This is certainly something I felt, like a lot of my, older Linux colleagues still don't get it, right? They still don't understand why I'm, like, why I, because if you look at it from a thousand-foot view of all crypto together, right? you know, and you can see that ninety-nine percent of it is scam, is scams, you're like, just eject the whole thing into space. I have a huge amount of sympathy with that view, even as a Bitcoiner, I'm like, yeah, wouldn't it really be a loss if we'd,

You know, I don't think the answer to that is to stop moving. I think the answer is to just, you know, continue plotting, like we continue with doing great things on Bitcoin, doing great things with Bitcoin, making Bitcoin great, and They will come around or they won't, and that's their problem. I think, I think, yeah, we can't spend too much time worrying about what stupid people are gonna do with their UTXOs, because in the end of the day, Bitcoin is money for enemies and I have to, I have to kind of defend their right to control their own UTXOs, even if I think it's stupid, because I don't think there's a-- I don't think it's a better world if you have an arbiter who can decide what you can do with your own outputs. I think fundamentally we should be enabling people to do as much, you know, be as expressive as possible in what they wanna do with their own money as they can be.

Yeah, I think that's a great spot to finish up. Any, any closing thoughts, Rusty?

No, no, I think it's, there'll be posts coming out, from me. I'll have a draft BIP that I will be sending through, and there'll be obviously code for people to run and, and play with, very early alpha days, but much of that is finished already, and I'll be pushing that hopefully in the next week, depending on whether, you know, something in the Lightning Network lights on fire and draws me away again. but I do wanna say I really actually enjoyed, dealing with All the developers who've come forward and given ideas and given feedback on, on all this stuff, 'cause there's definitely a hunger among developers to clean things up, and we're all trying to make Bitcoin a better thing. We're just, you know, often debating about the individual details, but we're all headed in the same direction.

Yeah, and I'll just point out, I think there's one other, I guess one more thing just kind of came to my mind as well, because I know there'll be some listeners who are thinking, "Why do we care that much about making it easy for the developers? Like, what's in it for me? Like, what are we gonna get out of it?" And right, and I think it-- to, to what you were saying, it's the functionality, it's the efficiency gain, right? So yes, developers want developer things, but it's so that they can provide functionality and It's like an LSP or an async or whoever else, it's gonna be benefits for them and maybe they can lower their costs and in turn, there's competition amongst LSPs and they have to then pass those savings on to the end user, the consumer, the end hodler and Bitcoin user out there. So I would just sort of, yeah, maybe that, that's how I would see it, and so, yeah, so listeners, I will put Rusty's talk at Bitcoin Plus Plus in the, in the show notes, and Rusty, thank Thanks, Stefan.

Always great.

I hope you enjoyed the show. If you did, make sure to give it a thumbs up and share it out there with your family and friends. Check out my website at stefanlivera dot com, and I will see you in the citadels.