Citadel Dispatch

Share on social media:

EPISODE: 64

BLOCK: 735810

PRICE: 3192 sats per dollar

TOPICS: BIP119, CTV, bitcoin development process, rusty's new covenant proposal, fungibility, consensus, timelocks, ossification, activation

https://citadeldispatch.com/cd64

@rusty_twit: https://twitter.com/rusty_twit

@brian_trollz: https://twitter.com/brian_trollz

streamed live every tuesday:

https://citadeldispatch.com

support the show: https://citadeldispatch.com/contribute

twitch: https://twitch.tv/citadeldispatch  

bitcointv: https://bitcointv.com/video-channels/citadeldispatch/videos

podcast: https://www.podpage.com/citadeldispatch  

telegram: https://t.me/citadeldispatch

stream sats to the show: https://www.fountain.fm/

join the chat: https://matrix.to/#/#citadel:bitcoin.kyoto

[00:00:01] Unknown:

I talked Bitcoin now, and I Andrew. And then I was thinking ARC.   Because if you feel bad about Bitcoin   Yeah. If you're in ARC,  

[00:00:10] Unknown:

like, let's double and tripling down on all of Ark's down 70%.  

[00:00:15] Unknown:

68% from from its high. You. Double down. Yeah. So who's not under is there anyone  

[00:00:22] Unknown:

not underwater  

[00:00:23] Unknown:

in ARC? We're gonna talk to Robert Frank later about not ARC, but ART. And art apparently is not underwater, but we're gonna  

[00:00:31] Unknown:

No. No. Well, everybody still loves Marilyn. We've talked about her a lot this week, the dress at the at the Met Galen, and and, he made 5 of those. That was smart. That's isn't that, is that a $1,000,000,000?   Well, not for him. No. But it it if you add up what it what it's sold for, it's a $1,000,000,000. If it was an NFT, maybe he'd get a piece.  

[00:00:54] Unknown:

Let's talk Bitcoin just for a second because Bitcoin prices this morning, cryptocurrency briefly dropped below 30,000   late yesterday. It's regained some ground early this morning. We're about $31,449   right now. Bitcoin, though, we should say, off about 55%   from its November peak, and 40% of holders are now   underwater on their investments. That's sequenced some new data out from Glassnode that says that, in the last month alone,   15.5%   of all Bitcoin wallets fell into unrealized  

[00:01:27] Unknown:

losses. So I thought it would be more. Again I thought it might have been more, but it doesn't because there's holders that that, I guess, that have been holding for longer than that. But 40%,   I mean, it was at 66. Right? So you would think it could even be worse in terms of the number of people that  

[00:01:44] Unknown:

that have an unrealized But that goes to the hold takes a long time to hold. Mentality. How many people do you know who who people have been owning since they've 10,000,   20000, 5000. Right? Right.  

[00:01:54] Unknown:

I don't have a single one   that I bought higher than where it is right now. So and I don't have a lot. I don't I don't have a lot. But, but I have those. I got one as low as 5, 4 49100.   StocksToWatch.  

[00:02:44] Unknown:

Happy Bitcoin Tuesday, freaks.   That clip that we just started off the show with with CNBC   now addicted to on chain analysis   as well as the rest of Bitcoin Twitter and Joe Kernan bragging about   not being underwater on his Bitcoin holdings.   Happy Bitcoin Tuesday to your all to you all. This is your boy Odell here for another Ciel Dispatch, the interactive live show about Bitcoin and FreedomTech.   Dispatch is a 100% audience funded without ads or sponsors focused purely on actionable Bitcoin discussion.   I wanna thank everyone who continues to support the show and makes that mission possible.   I really do appreciate it. The easiest way you can support the show is through podcasting 2 point o apps. My two favorites are Fountain Podcasts   and Breeze Wallet.  

You simply   download the app,   works like a regular podcast app. You load it up with sats, and you choose how many sats per minute you think dispatch is worth, and it streams those sats directly to my node.   You can also support the show,   via the BTC page server instance at sil dispatch.com   through Onchain or Lightning   as well as through my BIP 47 reusable payment code listed on the website.   Although you can obviously listen to dispatch on podcasting 2 point o apps, you can also listen to it on any other podcasting app.   My favorite is antennapod.  

You simply just search Siddle dispatch in those apps.   If you don't have stats to spare to support the show, clicking the subscribe button, leaving reviews, sharing with your friends obviously helps tremendously.   Dispatch is also broadcast on Twitch and Bitcoin TV as a video show,   with all archives on bitcointv.   Com. You can find all those links at syldispatch.com.   Dispatch also has a live audience chat. I wanna thank all the freaks who continue to join us week in, week out in the audience chat. You guys make it truly special and unique,   by participating in the discussion.  

That chat can be found at sidildispatch.com   and clicking that sidildot chat link. Now that group now is over a 1000 Bitcoiners. We have conversations all throughout the week, not just on Bitcoin Tuesdays. So consider joining us. Really high quality conversation there.   Last but not least,   a new way to support dispatch   is through the podcasting 2 point o boost feature.   I've been trying to experiment with different value for value models in terms of supporting the show without corporate sponsors,   And the boost feature basically allows you to choose how many sats you wanna send to dispatch and include a message with it,   through podcasting 2 point o apps. So that works on both Fountain Podcasts   and Breezewallet.  

And as part of that, I think what I'm gonna do going forward is that if you do a boost that's over a 100000 sats, I will read it on the following show.   I'll read your message on the following show, and if nobody has any boost above a 100,000 sats, I will read   the 2 highest paying ones, and we'll start from there and see where it goes.   A bunch of freaks actually posted comments from   2 weeks ago's,   Nostra episode,   the censorship resistant alternative to Twitter and a bunch of other things.   And some of those comments were pretty fun. One was early but interesting. Thanks for all the helpful content that came from an anonymous user.   Atbond said end of month boost for no ad podcasts, and that nostir sounds super interesting.  

Following Will's Nostra programming updates on Twitter have been good.   Vake said, hi. This is Vake. Testing fountain app's boost feature, really compelling comment from Vake.   And letter 6173   said, your show is a godsend. I wouldn't go that far, but I appreciate the sentiment regardless.   With all that said, we have a very important conversation today. We are going to be talking about the lightning and Bitcoin development process and how changes get implemented into Bitcoin.   Specifically, we will be talking about the CTV proposal that has been very controversial recently.   Potentially, we'll be talking about Bolt 12 on lightning,   and we'll be talking about Rusty's new proposal, which is an alternative to CTV   called OPTX.  

So with all that said, I wanna introduce our 2 guests. We have Rusty Russell here. How's it going, Rusty?  

[00:07:07] Unknown:

Hey. I'm good, Matt.  

[00:07:09] Unknown:

It's it's bright and early here, but, hopefully, I will stay awake for this. I've had my coffee, so we should be good to go. We appreciate you joining us so early in your day. It is it is truly grateful for that. And we have Shinobi with us. How's it going, Shinobi? Going alright. I appreciate being brought on here to voice my support for government white lists.   And we end the conversation.   So where do you guys wanna start? I was thinking more of a general overview of what the Bitcoin development process is and how changes get implemented. It seems like a lot of people are confused about how that all goes down. What do you think?  

[00:07:48] Unknown:

Yeah. We can we can certainly start there. Right?   It's supposed to be confusing as part of the answer. Right?   I think so, you know, it's it's sort of constructionist kinda anarchy.   There's, you know,   so   I think the thing to bear in mind, right, is that we are all discovering how this stuff works.   Right? And that is true   universally.   Right? What is the best way to do an upgrade to the protocol is   still an open question.   Right?   But, you know, we can talk about how it has been done in the past,   successfully or unsuccessfully   and, you know, get some inspiration   from that.  

I know, is that fair, Shinobi?  

[00:08:34] Unknown:

Yeah. I think that's a good place to start. I mean, like, the the way I I conceptualize   the whole thing is you just have an an arctic mob, and if you want to upgrade things, well,   get up there and convince the mob to do something.   I mean, I can't really think of any other way to describe it.  

[00:08:54] Unknown:

Yeah. That's that's pretty much it. I mean, I think if, you know, if everyone decides some some upgrade is gonna happen, then it happens.   The question like, you know, the messy details are in how does that actual decision process   happen and how do people know there's an upgrade going on? How do people know they're supposed to   upgrade their node and do things?   I guess the important thing with Bitcoin is it's always backwards compatible. Right? Nobody nobody goes in and breaks stuff. That's, you know, that that may not be a rule that's true forever. It's possible one day we'll do what's called a hard fork.   But usually, we're talking about a soft fork, which means that all the stuff that works will keep working. There's just sort of new things added, basically.  

Technically, it means that things   that new rules are added,   but rules are never taken away, and that makes it backwards compatible. So if you take the, you know, the 0.3   Bitcoin   version with a couple of fixes,   it will happily sync the current Bitcoin chain.   Nobody's nobody's, you know,   nobody's doing any non backwards compatible changes. And so we're talking about a soft fork here, a backwards compatible change.   And importantly, even a backwoods compatible change could be bad. Right? A backwoods compatible change could be,   you know, Block 9 coins can no longer be spent. Right? So that we've just stolen Satoshi's coins. That would be backwards compatible with the network. It would also be a really bad idea,   and probably not,   you know, but my my node would never run such software. Right? So,   you know, just because it's back as compatible doesn't mean it's a good thing to do,   but it's kind of a minimum bar. We want back compatible changes that don't break anything.  

And, you know, all the changes we're talking about as well are things that   pretty much if you don't use them, they don't hurt you. Right? That's also kind of a minimum bar I think that people have. Right? Is is there often changes?  

[00:10:47] Unknown:

Yeah. I mean, I I also think, like, another important aspect of that to consider is the   actual coordination   of a change. Because, you know, there there is this conception   that's pretty widely held   amongst a lot of nontechnical users that, like, a soft fork   magically means there is no possibility of a chain split, but with a hard fork, there is. And the the reality is   if the coordination   of activating something, you know, goes wrong or is not complete or starts in the wrong place, like, there absolutely is the risk of chain splits even though an upgrade is being done through a soft work.  

[00:11:27] Unknown:

Yeah. Absolutely. So,   okay. So let's let's talk about, let's let's kinda come down to brass tacks with being very abstract. Right? So,   let's look at op CTV. So this proposal takes   op no op 4, which is basically,   you know, something that does nothing at the moment,   in Bitcoin. If you put that in your little Bitcoin script, hey, in order to, you know, every every so every Bitcoin script,   well, okay. Let's we should probably just talk about what it is. Right?   Every output in Bitcoin, every coin   has a list of conditions that say who can spend it.   Right? So how you need to spend it. And usually that's, you know, hey, if you have this,   if you can produce a signature for this public key, it's yours. Take it. Right? That's the simplest script. It's it's, you know,   it's got abbreviations. It's so common. That's the most normal use of script. But you can have other things. You have a little program in there. So so you have to you have to basically make this program work.  

So this would take up not 4, which currently does nothing, and makes it do something. Right? In this case,   it it   checks that the top thing on the stack matches the thing that, you know, it produces produced by, not for the the template verify thing. So it adds a new rule.   Right? Now,   if all the, you know, if all the nodes were to start enforcing this rule and your node didn't   and somebody used opt not for the old way just as as a junk opcode,   all the upgraded nodes would go, no. No. No. That means a special thing now, and and and this doesn't work anymore.   You don't meet the conditions.  

We did that opt not 4, which is now CTV. And, no, your program doesn't work anymore. You can't spend those coins. Then you'd have a chain split, right? Your node would go to whatever. I'm ignoring that. That's fine. Everyone else would go no, no, no, that doesn't work. You can't spend that coin   by definition then. Right?   You'd have a split. Now in order for you to actually get a split, you'd have to have a miner,   that is gonna mine a block that contains that transaction and that treats it the old way and ignores the stuff.   But it could certainly happen. That's why we try to get Eberron to kind of upgrade at once. We don't want to have gratuitous chain splits and everything else. In particular, if all the miners upgrade,   then no one's going to produce an invalid block. You're not going to get a chain split. Even if you haven't upgraded, you're probably pretty good. So there is definitely some staging in how we like to do our upgrades so it's not too messy.  



[00:13:46] Unknown:

And I I mean, I feel like we skipped a step here, at least in the explanation process of why we don't have   auto updates   for Bitcoin,  

[00:13:57] Unknown:

which is Well, because then developers would just be in charge of everything, and and that's  

[00:14:03] Unknown:

because then it's a vulnerability, basically. It's a vulnerability that whoever is in charge there can push through unwanted changes. Right? Yeah. Why not just have the developers decide who gets all the coins?  

[00:14:14] Unknown:

Yeah. No. No. There's no there's no auto update. As a general rule, for Bitcoin Core, there's no auto update. I mean, other software can   or that, you know, other developers are gonna go rogue and still order your coins.   Now there well, there's never been an auto update. There was this alert key,   feature in Bitcoin early on, right, that allowed you to basically send a message out to all the notes and say, hey, you know,   do something. It was signed by this magic key that some of the developers had.   That was ripped out,   quite a while ago. But that was kind of a nod towards this idea that there might be some, oh, crap moment where   early   on, you know, you might have had to tell everyone, oh, crap, can you upgrade because we found this horrific bug or something.  

But, yeah, I think we're,   hopefully I know we can never be sure with software, but, hopefully, we're past those days.   And either way, the alert key is long gone.   So so no, there's no auto upgrade. Everyone's got to kind of in theory, everyone like looks at the software and goes, yes, I like it. Okay. We're all good to go. And they tell their friends and we all kind of upgrade around the same time, and we don't end up with any chain forks and stuff like that. And that's generally worked pretty well, but it is pretty chaotic.  

[00:15:35] Unknown:

Yeah. And, you know, I I think a a huge,   like, aspect of the whole coordination process for softworks,   despite his minor's involvement.   Like, a lot of the   the problems and nonsense   from,   say, 7 years ago or so   was around   the dynamic of miners   upgrading first and the importance of that.   And, like, the the entire original reason for that was   not giving minors some disproportionate   vote or influence or anything like that. It was solely   to prevent the risk of a chain split because you have to have miners   mining invalid transactions according to the old rules   or the the new rules New rules. In order to have that chain split occur. And so the the entire reason of miners signaling and miners, like,   taking that role in the activation process was solely,   a kind of defense,   against that risk with a soft fork. Like, no,   like, kind of giving disproportionate controller influence to them. It was simply,   a safety mechanism to try to reduce the risk of a chain split as much as possible.  



[00:16:51] Unknown:

Yep. Yeah. And to some extent, you know, if you if if, like, you know, the classic 51% attack. 51% of the miners go rogue,   in theory, they can start   unpicking old blocks and and create a new chain. So, you know, there's already some level of responsibility there. And so going, okay. Cool. Well, you know, we'll we'll just get them to upgrade to some extent makes makes makes a deal of sense. On the other hand, it doesn't matter what miners do. If  

[00:17:26] Unknown:

Did we lose Rusty?  

[00:17:28] Unknown:

I think we did.   I was I always thought maybe it was my side.   The miner censored   him. Uh-oh.   Well, hopefully, he jumps back in.   In the meantime,   Shinobi, there was there was the term vote was just thrown around.   The way I kinda look   at implementing Bitcoin changes and, like, this loose Bitcoin governance process is that there are multiple stakeholders.   You got you have miners, you have devs,   and then maybe you have users that aren't devs or miners.   I kind of look at it like all of those people all have a Vido.   Do you think that's, like, a good way of looking at it, or is that a   I mean, I I don't a good perspective   or veto rather than vote. Veto or vote  

[00:18:24] Unknown:

is really,   like, a a accurate way to represent it. Like, I I just always come back   to the idea of a a mob   that just happens to all be doing the same thing, moving in the same direction, and the process of changing being trying to convince them to do something different.   But I I I don't see things so much as a vote or a veto   just as,   like,   people are free to do whatever they want. Like, you can always break off and form your own mob. Like, there is nothing that keeps you a part of this one.   And ultimately, it just comes down to,   like,   how   willing are people to do that   and how long will they stick that out if they do that   in order to see, you know, whether people will follow them or stick with the mob that they broke off from. So it's it's not so much,   I think, a veto or a vote as it is just, like,   how much value do you see   in being part of the biggest mob and, like, how Right. How far will you take that game of chicken   in terms of, like, threatening or actually breaking off from that?  



[00:19:39] Unknown:

That makes sense to me. That's a pretty good perspective. I guess where I got the veto from is,   like, if I'm running if I'm using my own node and I don't update it,   I am basically   individually saying I am not going with whatever change is being made. Right?  

[00:19:58] Unknown:

Yeah. But I mean, in in the case of a soft work, obviously, though, as long as   minors choose to not disrupt things, then you are still going to,   you know, stay part of the larger mob. But you are kind of choosing,   like, consciously if you're paying attention at least,   to open yourself up to the possibility   that you could be broken off into, like, another mob by some other actor inside of it.  

[00:20:27] Unknown:

I like that perspective. It's a good framing.   And, Rusty, you're back.   And   he is not.  

[00:20:38] Unknown:

He is back. He is back. You you got 51%   attack.  

[00:20:42] Unknown:

You're just about to talk about the miners, and they cut you off. Those stealthy miners. Yeah. Actually, I do not know. I could still hear you. You could not hear me. I don't know why.   Anyway,   hopefully, I'm back now.   Yeah. Miners. So,   so so to some extent, you know, there there's there's a reason to to go through the miners, but it doesn't matter because your node checks everything. And so if the miners start producing what your node considers to be crap, it will just drop those blocks on the floor. So   at the end of the day, you know,   you you have control over what your software does. Now that may not help you if everyone else goes the other way and you're the only one running you're a particular weird variant of Bitcoin and no one's mining it. Sure. But,   that is, you know, that is the ultimate control. Right? Is is the economic control. Right? If the vast majority of people who use and have Bitcoin   believe the rules are a certain way and their software enforces that, then that's what Bitcoin is. I'm sorry. You know, like it or not,   that that's there there's definitely an economic majority argument. It doesn't really matter what the miners do. And importantly, in a meta sense, the miners will follow those people because those people have the money. Right?  

So the miners really are relying on that block reward. Right? That's that's why they're mining, presumably.   At least most of them are doing it for profit motive.   And if they mine something else with their machines and no one accepts those blocks, they don't get paid,   at least not in any meaningful sense. Right? If there's only, you know, 3 people in the world who accept that weird Bitcoin fork, that's not gonna pay the bills. And so they are incredibly economically sensitive   to what your node does if, you know, if if the vast majority of nodes are going the same way.   So there is definitely a a, kind of,   standoff here where, you know, the miners are you know, the miners kind of seem to have some signaling control, but   they definitely are having to follow the economic majority in the end. So it is actually really important that people run their own nodes and and check their own stuff and and look after their own things, and the miners will have to follow.  



[00:22:46] Unknown:

Mhmm. And, you know, I I I kind of,   learned that lesson,   I will not learn, but had it reinforced,   last year during,   Taproot activation.   I I was being a cheeky smart ass   and patched my node to start enforcing Taproot from the genesis block.   And then Wing Chung and f two pool   decided to sweep some,   Taproot   outputs that developers created while testing before enforcement started. And so my node,   is still sitting quietly in the corner waiting for everyone else to come back to the real Bitcoin.   Yeah.  

[00:23:30] Unknown:

Yeah. Yeah. Absolutely. And, you know, this this is this is kind of important. I mean, to some extent, like, this is,   this is true of any money, right?   If no one else accepts your money,   that's   good for you, but it's, you know, you're always economically reliant   on this,   this at least somewhat that there would be another group of people who recognize the same money as you. Otherwise, it's not really money,   because trading with yourself generally isn't quite interesting. Right?   So,   so so so, you know, this it's kind of fundamental to the problem. So the fact that Bitcoin has this issue that you need to all agree on it is actually   just a question of degree. All monies have this issue. Anything you treat as money, you kind of need   to have another group of people who agree. Doesn't have to be everyone, but it has to be enough. So it's not like Bitcoin   created a new problem here. It's just that that's just how it is. And that's it in life. Right? If if no one else,   you know, agrees with you about the rules,   you're going to have a hard time.  



[00:24:33] Unknown:

Mhmm.  

[00:24:35] Unknown:

And,   yeah, I I think now might be a   a good time to kinda shift towards covenants   Yep. Just to, like, actually be able to get into that deeply.   Let's do it. I I do wanna say though before, you you get into that as the expert here, Rusty, that   yeah. I actually, for for a long time, and I'm kind of just   coming around to the counter arguments against this,   I was one of those people   that was,   like, concerned   with the fungibility   implications   of covenants   and the potential to kind of create   UTXOs   that could be perpetually   locked into some more restrictive condition,   in perpetuity.  

And, yeah, I'm I'm I'm kinda I'm seeing, like,   the arguments for why,   like, that doesn't fundamentally   change the fact that you can do   that type of thing with other mechanisms that already exist.   But I'm I'm still   kind of on the fence   of just opening the door of a covenant that does not require   precomputing   what it's committing to ahead of time,   just because when it comes to things like   second layers on Bitcoin,   I am really   hesitant to kind of just open the floodgates of things that could potentially   interact with minor incentives,   specifically, like, things like side chains,   that have a direct involvement with minors.  

And so, like, I I see   the fungibility concerns are kind of just arguing, like,   why do we want to enable something that you can already do?   But I I'm still   kind of skeptical   and a little cautious around the idea of just opening the floodgates of   not requiring that pre computation because that's really what opens the door to just general,   like,   constructs that can do whatever you want.  

[00:26:43] Unknown:

Okay. You you you kinda jumped right to the end there, but that's that's that's a good sketch. Right? So,   let's let's let's talk about fungibility.   Right? So,   so fungibility is basically every coin can be treated as every  

[00:26:59] Unknown:

other coin. And it's really important to address a misunderstanding  

[00:27:01] Unknown:

here. Covenants are something you opt into.   I can't covenant your coins. Right? You can covenant your coins. I can covenant my coins. Right? You can't.   And   this is an important misunderstanding. Right? So   the way Bitcoin works is you have control over your coins. You have a certain number of outputs, technically,   on the blockchain that you can spend   because you have the secret key that that that lets you sign for them. Right? And they have little rules that say that, you know, you need you need the key to this thing in order to in order to spend this coin. Right? And that's all Bitcoin is, like a list of outputs, list of rules.   And so   very simple. And everything else, you you don't have control over. Right? For better or worse. Other people have those secret keys or they've lost them or they sent them to bogus addresses like the 1 Bitcoin eater address and stuff, and there's no known,   secret key for it, and they're gone.  

So   step 1 in Bitcoin is always to accept that the vast majority of Bitcoin are not under your control, and you just have to kinda live with that.   You know, they're they're controlled by sovereigns. You may not know in many cases who controls them, but they're gone. So you can't control what other people do with their Bitcoin already. Right? And they can do insane things, and they have.   And you hope that the again, this whole money argument. Right? You hope the vast majority of them don't do things that you consider ridiculous because that will,   you know, not directly affect your you'll still have your control of your Bitcoin, but they could totally, you know if everyone else decides tomorrow that it's all worthless, then your economic value goes to 0.  



[00:28:39] Unknown:

And so it doesn't really matter that you technically control your Bitcoin. It's good for you. Right? Or they decide, you know, on some weird hard fork or soft fork, whatever happens. Right? So It's the existential crisis of Bitcoin. Like, if tomorrow every other Bitcoiner just decided that they're going to lock their coins and do a 2 of 2 multisig where the government controls the keys   and refuse to accept anything else. Like,   you can't do anything about that. Like, that's   just possible.  

[00:29:06] Unknown:

Everyone decides tomorrow gold is worthless and the price goes to 0. Right? So,   yeah, these Yeah. It is this existential   crisis that you can't do anything about. So,   can you make it technically more difficult for people to do this?   Yes, you can, but that boat already sailed. With Taproot, it is not even more expensive to make something a 2 of 2. Right? So   if everyone decided they wanted to have this this okay. We're gonna hand our coins over to some control entity that that is gonna cosign every transaction that we have. You're totally allowed to do that, And it used to be before Taproot. That would be a bit more expensive for you to spend your coins because you'd have to have 2 signatures, not 1. And, you know Well,   it's about technically melting.  



[00:29:44] Unknown:

Technically, with ECDSA   multiparty   computation, you could even have done it before Taproot. It's just a lot more complicated to coordinate.   Exactly. Exactly.  

[00:29:56] Unknown:

So, you know, but but definitely, we we open the door to that, and it's like, okay. Great. So so now you can have a single thing that's combined these two signatures. You could do it today. Go go nuts. And and to be fair, it's not just theoretical. Right? We have this   on Blockstream, who, disclaimer, I work for. We have our liquid side chain. And if you're if you're dealing with registered securities on the liquid side chain,   we cosign everything. It's called AMP, asset,   something something acronym. Anyway Management platform.   Thank you. Yeah. And it's basically it's a cosigning for all the things. Right? That's how we control. We go, cool. Is this person allowed to have a transfer? Yes. They are. Great. So so we can transfer that. So it's not like a theoretical technology. This already exists. It's totally the way you would do an evil coin control thing. Right? So   the idea that covenants introduces this is is actually forced. That's not how you would do,   how you would do your evil coin.  

You would not want to give up control. Covenants   fundamentally   let you control   how your coins are spent. Now, you already can control how your coins are spent. Right? You can say, hey, you need this   public you need to have this secret key and make a signature for me, or you need to have these 2 keys, or you need to get this evil government corporation   or government organization to sign off on your thing. Whatever it is, you can already set those for your stuff. That's fine.   It's just a question of degree. Now, what's really interesting here   is bitcoin could have just been released with   say single signature, right? The most common use is like, hey, you got to have a signature for this key and you're done. Bitcoin could have just had that ability from day 1 and it did,   but it did it in a very weird   way. Right?  

It did it in its gin by having this generic little program attached to every output.   And Satoshi   originally claimed that basically if he didn't put it in at the beginning, then it would never be put in later.   And this was the programmable money thing, and it is   weird because you're already talking about a revolution in this this kind of, you know, this money thing. Why would you add this feature as well? It seems like a real go out in a limb   stretch thing, right?   It makes the system much more complicated.   It makes them not fungible. Instead of every spend being the same, you just add a signature and you go. Now, you've got this thing has this weird encumberment that everyone can see, and so that coin looks nothing like any other coin.  

And the language used was   not ridiculously powerful, but reasonably powerful. It's like this 4th based language with all these different instructions like add 1 and add these two numbers together and subtract this and compare with this. All this stuff that you can do.   And it's generally you know, the 99% of transactions do not use this at all.   But it was very   foresighted. Right? It turns out that some of the stuff that we didn't even know that we wanted to do really,   like the lightning protocol stuff,   uses a small fraction, to be honest, of this scripting capability.  

And in fact, we have enhanced it since then, and this is the trick. Right?   Satoshi actually had some powerful stuff in there that he pulled out because   he was concerned that the implementations   were probably vulnerable to various denial of services. So he just kind of ripped off a bunch of fairly powerful opcodes out for technical reasons.   And we are perhaps very slowly experimenting with kind of putting stuff back, and doing things in a better way.   But the idea that there's these weird non fungible, like, different coins out there, If that boat has already sailed, Bitcoin is already there. We have this weird script capability that we don't use very much.   And we're looking at, you know, hey. How do we enhance it? And we, over the years, have enhanced it in little ways.  

The if we look at, like, check sequence verify and check time lock verify, these were 2 soft forks that basically let you say,   you can spend this but your transaction   has to be time locked after a certain point   basically. So you can only spend this in the future. So you could lock   an output and say, hey, you can only spend this in 6 months' time or whatever.   Right?   Mhmm. And that is a kind of covenant.  

[00:34:01] Unknown:

Yeah. And that that was also an optimization   from,   like, something Satoshi built that was not as functional. Like, you only had the unlock time, so you could only do that previously with pre signed transactions. You couldn't actually time lock the script,   which Yep. Was a huge extension of what Satoshi did. Yep. He did it as it's it's a covenant. Right? It says your transaction must look like this.  

[00:34:26] Unknown:

In this case, your end lock time must be greater than or equal to some value. Right?   It is exactly a covenant. It's a very limited covenant, but, you know, it's been very powerful.  

[00:34:36] Unknown:

Yep. I mean, I I I would I would argue the semantics there a little bit   and that it doesn't   limit the destination   of of the transaction, which I which I think is I I at least think of that as, like, the the defining characteristic of a covenant. It's, like, actually limiting where it can be spent. Okay. That's the Rubicon for you. Fair enough. I I accept that.  

[00:35:01] Unknown:

You But it was it was certainly the first you know, you you look at the transaction itself to see whether or not you can spend it rather than it just satisfies the script and you're good to go.   So, you know, but but Satosh definitely threw this kind of, you know look. Here's here's a generic kind of forth like language that we'll put on the in the scripting language,   with a kind of   an idea that we wanted this programmable money. Now, why do we want this programmable money? It's an interesting question. Right? Why didn't we just why didn't Satosh just go, no, you just have multi signatures and you can have 2 things sign off. You can have this you know, other entity that that that will sign off for you and that can enforce all these rules. We don't even need this complication. We don't need it. Why do we have it? And When you think about it, the only reason you have this is because multi party stuff.   You don't need to encumber your own coins. Like, you presumably trust yourself to sign it or not sign it, right?  

But thinking one step ahead, you want   the Bitcoin system to enforce these rules. The only reason you'd want that is because there's multiple people involved.   Right? So even while other people were still wrap grappling with the idea of of of   Bitcoin and how we would send money to each other and all this stuff, this is already one step ahead in talking about how will multiple people construct   these   financial instruments together   and create these transactions together in a way that they don't have to trust each other or things like that.   So,   scripting is all about multiple parties interacting,   and not having to have yet another thing that they trust. They can do it all in Bitcoin. So, I don't think there's   no clear line for me between the scripting system we have today   and any slightly more powerful system that that lets you control how you can spend stuff because we're already kind of there.  

Now   we do we talk people talk about recursive versus nonrecursive covenants. Right?   A nonrecursive covenant says, basically,   your outputs must look exactly like this.   And   a recursive covenant can say, and, you know, they must look and the outputs of the next one must also look like that. So you can basically encumber coins forever.   But this isn't a really useful   distinction   because   you can effectively encumber coins forever because you can say your output must look like this,   and one of those outputs   says that the next one must look like this. I mean, you've got to step through it, but computers are really fast, and I can encumber the next, like, 1,000,000 spends of a coin,   in probably under a second.  

Right? So,   I can make that chain as long as I want. So the fact that it's not technically infinite,   but especially with check lock time verify, I can say, well, you can only do one spend every hour and I've incumbent it for the next, you know, 100000000 hours.   It's forever.   So  

[00:37:44] Unknown:

Oh, we're I I would just like to   for people listening,   kind of make a little finer point there.   Although I I do agree   that in the grand scheme of things,   the important issue is having to precompute versus not precompute everything. Yes. But I I do think it's not really   practical   to kind of create that long chain of locks in the way that people think it is with things like CTV.   Because let let's say   that the whole thing you're worried about is receiving these coins   where you can only spend them   at, like, preapproved   merchants or whatever.  

In the case of CTV,   like, it's not just a simple linear   commitment to, like, one path of where those coins get spent because you don't know,   like, how much money somebody is going to spend,   where they're going to spend it. And so when you look at trying to use CTV for that type of thing, you're talking about an infinite,   like, forking   recursion where you have to go down to the single satoshi   and look at the value of that output   and So while it's totally possible to take, like, a single line   and precompute that, if you're talking about, like, something that would be usable in general commerce, like, that that's just not   practical or scalable.  



[00:39:23] Unknown:

Oh, absolutely.   Absolutely.   And this is where your distinction is exactly on point. Right? The difference is,   is it partial or full specification?   Do you specify exactly what the transaction looks like, or do you specify some part of it?   And this is really interesting because the OpsCTV   already steps over that and says, actually, we're going to specify some parts of the transaction. In particular, it doesn't specify all the inputs.   Right? So the simplest covenant would be   optxd   verify,   right? Which would be literally,   this is the transaction ID   of the thing spending this output.  

And based on saying the only transaction that can ever spend this is this one.   Right? That would be the simplest covenant form that we could come up with. Right?   And and op check template verify is not that.   It does not just do that, and that that would be really simple. And the re one of the reasons is there's a couple of reasons.   But one of the reasons is that you often want to add fees later. Right?   You don't know what fees are going to be in the future, so locking yourself into a particular transaction may look really, really foolish. It should fees spike, and you're suddenly like, oh, crap. I can't actually spend this now.   Now you can use child pays for parent perhaps, but it depends on whether your outputs are time lock encumbered and all those things. So,   we've already crossed that point from fully specified to partially specified,   but it does fully specify all the outputs which makes it restricted,   right?  

Now I guess I come back to first principles here, like as if you get well, should we allow generic covenants and I'm like well Satoshi never disabled anything because he said, oh, wow. This is too powerful for humans to handle or any crap like that. Right? It was always you know, otherwise he would have gone away and done something else and not invented Bitcoin. Right? So the idea that, wow, this thing is too powerful, perhaps we shouldn't enable it, is not an argument I find convincing   at all. I think we should   as long as it is neat and technically feasible and will allow cool things in the future,   I think we should probably look seriously at how do we do this technically the best? Right? What's not the technical, you know,   design things that we can make the best possible   thing that we can do.  

And then if we want to introduce it slowly, I think it's worth looking at what would the generic thing look like. Okay,   this is what a whole   covenant system would look like and they go, cool, but let's soft fork it in slowly,   but not randomly, right?   If we want to have some limited ability to start with, that's fine,   but don't keep adding more and more different warts to the system. So you've got this   check template verify. And then we go, oh, we want   check template verify 2 and then   check template verify 3 and all these things.   Because remember, in Bitcoin, we can only ever add new rules. We can't really take them away. So once we put something in,   we are stuck with it forever,   and the code has to handle it forever.  

So we tend to be really cautious,   not only about the changes that we make, but,   what what that means technically from the point of view of, you know, every every   everyone has got to check this stuff forever and we need to maintain that forever.   So, that's one of the reasons that there's so much debate and nuance around the different proposals,   because we're going to be stuck with this. Our children are gonna be stuck with the decisions we make here today.  

[00:42:53] Unknown:

Mhmm.  

[00:42:53] Unknown:

And, you know, that's, you   know, like I said when we started this topic,   like, I I don't really see   fungibility   arguments as, like, a valid counterargument   anymore, but   I am I'm still   kind of skeptical about just jumping into full blown covenants,   especially after   zmns,   c p x j on the the mailing list, I think, like,   2 months ago now, maybe a month and a half,   got into a a long thread   with,   Paul Stork   Yep. And kind of just spelled out how with a fully recursive covenant,   you could just implement something like a a drive chain pack.   And   I I just I do not like the idea   of enabling   the the ability to make,   peg systems like that for other layers   that directly   interact with mining incentives.  

I mean, I think there is worry   potentially if if Bitcoin actually does become a global money that everything's running on for that to potentially   destabilize   the mining incentives   altogether   If you literally have entire nation's economies running on that and you have coins encumbered where miners could just steal them,   I think that's the type of thing where you might just see a permanent   fork of Bitcoin that never resolves itself.   And,   like, that   is kind of damaging to the whole idea of building a a single   system around a single network effect.  

And I'm also   really concerned about   how the economic incentives play out there in terms of   the the validation   cost for miners   and how centralized that could make dependence on, like,   central entities like mining pools. Because once you   kind of activate the ability to make a two way peg like that involving miners,   like, you've just opened the door. Like, there there's no guarantee   that a a side chain somebody makes is just going to be some sane, like, small, easy to validate block size. Like, you could just hitch   something like BSV   and just go full retard   onto Bitcoin's   miners.  

And   I I'm I think one of the biggest vulnerabilities of Bitcoin right now going forward for the next 10 years, 20 years   is   the miner's,   kind of exposure   to regulatory or government interference or or capture.   And so, like, turning on something like a fully generalized covenant, which just completely opens that door to never be closed again   to all of these types of incentive   distortions   really worries me. And, you know, to to just get be blatantly honest about this, like,   any   kind of half opens that door as well with things like Ruben Thompson's,   space chain design. And, Jeremy Rubin just dropped   an idea for also doing a drive chain type design using APO.  

And so,   like, I that I think is is really   my main reason now for wanting to start very simply   with something like CTV or or the proposal that you just dropped today, which looks like it would be much simpler to upgrade slowly over time   rather than just right out of the gate, just below everything open into fully generalized covenants.  

[00:46:38] Unknown:

Yeah. So I think I think okay. So there's a couple of interesting points here. The first is,   the the minor incentive thing is is that's really hard. Right?   Meta miner incentives are, you know,   threatened by a whole whole whole pile of things, many of which are already outside our our control. Somebody starts a successful fork of Bitcoin and the miners go and mine that, right? We're all screwed.   Somebody starts using Bitcoin blocks for like a lottery that actually becomes more valuable   than like, so they use the blockhash as like a random thing for their lottery, right? And cool, you win the lottery if you, you know, guess the hash or whatever, right,   of the next block. And the problem with that is that if that lottery becomes big enough, it biases miners to like, you know, to to to suppress blocks and crap like that because they're trying to get the winning lottery numbers.  

Any system that builds on Bitcoin that is bigger than Bitcoin itself has, I think, these properties that it can screw with the incentives.  

[00:47:31] Unknown:

Mhmm.  

[00:47:32] Unknown:

And and and you can't stop people from building on.   So I think to some extent,   you're in the, Hey, not your coins, not your control. You're   gonna have to chill about that. People are gonna do stupid stuff with their coins all the time. And if enough people do stupid stuff, you're in trouble.   But that's   the fundament. Right? We already came back to that. If everyone decides to go to go east and you're going west,   it's gonna be very lonely. And, you know, now there's a question of degrees,   but I think people will figure out a way   to   do these things. People are going to figure out, Shinobi, they're going to figure out ways to do stupid stuff without our help. That, I think, is a universally true thing. So I find it hard to look at some technical thing unless it's obviously stupid   to go, we shouldn't do it for that reason,   Particularly when there are valid things that people want to do with these things, right? So if no one could come up with a reasonable use for it and be like well, I'm not going to waste my time on it. But there are also reasonable things that you would wanna do with covenants. Right? There are   decent same things that I might wanna do.  

You know, the idea of this, like, the cold storage vaults and stuff like that is is kinda cool where you could basically go, cool. You can spend this, but you can only spend it this particular way unless you have this super, super secret key, in which case you can pull it out.   You know, that that kind of covenant   design   is is is kinda interesting to me.   So, you know, if you've got   you've got kind of nebulous worries on one hand, but you've got a concrete   way of act you know, of of real use on the other. Now your point, there is, of course, a technical point right here where,   if we were to do something really foolish   and have some opcode that   was really   hard to validate, that took like a whole heap. We could wipe out a whole heap You can no longer validate with a Raspberry Pi. Right? If we did something   technically stupid,   then we could obviously create an opcode that would be centralizing and things like that. And that's I'm assuming here that,   technically, we don't make script significantly harder to validate or, you know, buggy or all these things that that that bar is passed. We're just talking about, like, meta incentives.  

And, yeah, I think it's an argument for going slowly. I don't find it a convincing argument.   I also don't find it an illuminating argument for which which bits like where the line is. Right? So we've got all these things we could look at in a transaction. We're looking at covenants, you know, we talked about whether you can, you know, control the outputs or not.   You   know, it's not illuminating   for me to go, cool. Well, where where do we go? Other than, you know,   you can have at the moment,   CTV says you have to specify exactly what all the outputs look like, which makes it infeasible to do, as you say,   an arbitrary control structure because you don't know how much they're going to spend and stuff like that.  

So   that's one line,   but   I don't know where the other lines are, and and which you know, so so if we go beyond the OPCTV,   which is the interesting thing for me because I think you need to rethink really long term when you're designing Bitcoin stuff, because we're gonna be stuck with it. What what would the next step be? Right? What would the next thing be? Cool. Okay. Now you can start writing   transactions that have to inspect this other thing.   And I don't know what that is other than you should just allow all of it.   So, you know,   but I I think I've got to thank Jeremy Rubin here for really making a lot of noise on this topic and bringing it to the fore.  

Because a lot of people considered,   you know, covenant design kind of a too hard basket. Right?   It wasn't clear what the right things were and what the trade offs were and, you know,   and most people just kinda push it in the corner and he's been really agitating for this kind of CTV   kind of mid level   covenant design I would say, not the simplest thing you could do but not the full covenant design,   and kind of like, cool. This is where I draw the line,   and we should do this. And he has been very loud and vocal,   and certainly   forced at least me to seriously look at covenants in a way I had no intention of doing this year. So,   yeah, I don't know.  

I think your points are fair. I disagree with them. I think, you know, there's there's always a fear of unknown. And I think if Satoshi may think that way, he would have just gone, no. We're not putting any scripting in. There's   it's it's opening a huge can of worms. We don't know what people will do with this, which is fundamentally the argument. Right? We don't know what people will do with this. They could do stupid shit. It could destabilize the whole thing. Maybe we shouldn't give them this power.  

[00:52:07] Unknown:

The concerns are like the edge cases, right? Like the things we can't think about, the things that we can't consider right now. But they're also the cool things, right? Lightning  

[00:52:16] Unknown:

was the thing I mean, so Satoshi had an idea of doing payment channels,   but full on Lightning, like he put a scripting system in because of the stuff he didn't know, which is also stuff to fear, yes,   but it is also the opportunity of people doing awesome things.   And I guess,   I'm I'm an optimist kind of person,   and I naturally go to,   yeah, look, if we can give people the tools to do awesome stuff,   some of them will do terrible things. But I think some of them will do cool stuff.  

[00:52:46] Unknown:

I think, you know, now might be   a good time to kinda break down your proposal, Rusty, because I'm I'm not gonna lie. Like, all of the alternative   designs that have been pushed out in the last 6 months,   I have been   very skeptical of either just because   I think it's too generalized   of a place to start   or they were just too   narrow in terms of designing for a specific use case. But I I   think, honestly, your proposal is the first one   that I might prefer over CTV,   like, with what I   kind of thought about since I glanced at it before we started.  

[00:53:29] Unknown:

Yep.   Okay. So so CTV, as I've said before, takes up not 4 and turns into this thing that basically hashes these certain parts of the transaction,   not covering all the inputs, but, you know, the current input and the number of inputs,   all the outputs and a few other things.   And just makes a hash of that and goes cool. Now the thing you've got sitting on top of the stack right now has to be exactly the same as that. Otherwise, you fail.   And it's done that way for complicated back compatibility reasons. So that's the only way you can extend old school script.   Now in in in Taproot, so so version 1,   Segwit,   we got   we do we do we do things in a different way. So in the old school way, it used to be if you don't understand something like that, all these things are just no ops, you just ignore them.  

In Taproot v 1, Anthony Towns, I believe, came up with this. It's brilliant.   If you see, an undefined opcode, so you don't do you just it's success. The answer is yes. All good. You can spend the coins. Go for that.   And that makes it much more upgradeable.   It means that in the future, opcodes can do   all kinds of things. Alright?   With the op not idea, the only thing an opcode can do basically is fail at that point.   So   so we take advantage of this thing that that was invented for for Tapscript v one and we go, cool. So in Tapscript v one, we will have a new opcode called optx   and it will take   a series of like 32 bits that basically say, here, take these parts of the transaction   and do stuff with them. And you can say, do you want the inputs? Do you want, you know, particular parts of the input? Do you want the version number? Do you want all these things? Right?  

And there are other bits that say, hey. Do you want me to hash them all together? Do you want me to just like put them all in a row? Do you want me to push them on the stack as separate bits?   And,   you know, and so it's a very, very generic   here, look at I wanna look at the transaction that's spending. Right? That's that's basically OPTX. It's what's a very generic name.   And you say what what thing, what person to look at, and, you know, and and it it does that. Now this is incredibly generic. Right?   But the trick here is that   to start with, we say,   you have to set exactly the bits that are equivalent to object template verify.  

Right? So you're only allowed to look at the things that   template verify would let you look at,   and you have to hash them together and put that on the stack   and any other bits of success. So we can define them in future, but for the moment, you're very restricted. So it's a very generic   design   that lets you do all these cool things in future. But right now, we only enable a part that   basically gives you off check template verify, so CTV.   The cool thing about this is that it gives us a way forward. We don't have to do an op CTV 2 and be stuck with, Oh, everyone uses CTV 2 these days, but we've got to support old op CTV because we promised, and promises are forever in Bitcoin.   Right? So it's it's basically the same thing, only it is basically has a road clear road forward   rather than,   rather than being this, okay, comp technical compromise   that some people feel that if we want to go further, we're going to be stuck with and it's going to be ugly, which is my concern with Ops TV.  

Not not that I think it's a bad place to draw the line and go, oh, let's start with these ones. It's that I think pretty clearly we're gonna want some other things   and that was always going to make CTV ugly   and so in future generations we're going to look back and go, oh man,   that was a pain,   Right? So this is it's a generic thing but then it's soft worked back down to   this minimal thing. So I've tried to kind of square the circle here   but it does have some disadvantages.   You cannot use this   in,   in in,   either   v zero,   SegWit or pre SegWit   outputs. It has to be in in in in a Tapscript,   because that's the only thing it has is ops success.  

Now if we discover after, you know, people use this and do all these things that there really is   a subset that's far more common than anything else, we go, Cool. Actually, almost all the time, you want off CTV. You want those particular bits, and that's the right thing to do, and it's this really common use case.   And, hey, this opcode is like 5 bytes long. It'd be really nice if we had, you know,   really nice if we had, like, a shortcut version for the really common case.   Then we could totally do OPNOT 4 or OPNOT 3, you know, take one of those opcodes and turn it into just that specialization later on. And to be fair, we already do this in Bitcoin for the public key case, right?   The standard, I just want to spend this. If you've got this signature by this key, you can spend it. Right? We already have a shortcut, for those because it's such a common case. You don't have to spell it out in script.  

You can, but the standard things don't.   So, yeah, we can totally put in a shortcut later,   but doing it today is doing it backwards. It's a premature optimization   to take an opcode and and give it for some special case when we don't even really know that that's gonna be the most common thing that we do.  

[00:58:31] Unknown:

Mhmm. So it's it's kind of just approaching   things the same way SegWit did. Like, SegWit redefined an OPNOP,   but set it up so that you could version that   and just keep iterating how that single   newly defined opcode   is validated   instead of having to eat up a new one each time because we only have so many before we run out of them and can't Yep. Add new bare op codes.  

[00:58:59] Unknown:

Yeah. And this is this is part of what I kinda came back to at the beginning. Right? Is that we are still learning how to do this. The ops success thing is, in retrospect obvious.   But as Andrew Polster said, even the idea of a soft fork versus a hard fork Bitcoin upgrade   really only came about in 2012. So it took us a few years to really realize   the right way to upgrade Bitcoin. You know? And it was only really with Tapscript that we realized the right way to upgrade script   was to define everything as ops success and   then take those away later on. So   this is all part of that that that learning experience, and I think that's   that's natural because this stuff is hard and and and weird,   and this gives me sympathy for the the CTV crowd going, actually,   we wanna have it out there so people can play with it, so we can learn stuff, so we know what we want next.  

There are people who are like, no, no, let's go full covenants because we know we want them. And I'm like, I think we want them to,   but   I   my experience at Bitcoin has led me to go that we're not as smart as we think we are. And there is real benefit in having something out there that people can play with because   people will come up with cool new things, and that will set our priorities for what we would turn on next. Right?  

[01:00:12] Unknown:

Yeah. Like, you know, we   like, nobody sees everything a 100% clearly. And I I think,   like, a good example of that is the making one of the point variables   in Schnorr pub keys implicit.   When   the whole proposal for tap, leave, update, verify,   was dropped,   that created a whole big problem because   now you have to make sure that when you add or subtract subtract a key from a Schnorr multisig that   what you wind up with is a valid key. Otherwise,   you could wind up just burning coins.   And that adds a lot of client side, you know, work that has to be crunched and computed   anytime that is   used to make sure that   you don't wind up with some combination of somebody wanting to leave, like, a multisig output where   everybody else's coins wind up getting burned because it's not a valid pubkey according to the TAPR rules.  



[01:01:13] Unknown:

Yep.   Yeah.   Yeah. We we,   we we do learn things. And then importantly, right, so I guess,   there was a   a really dumb,   soft work in Bitcoin's history,   that predates me.  

[01:01:30] Unknown:

P two s h?  

[01:01:32] Unknown:

No. No. That that that looked k.   No. P2sh was good because it made room for to do it properly with with Segwit. Right? But,   no. The the the dumber one I was thinking of was was basically the the forcing the block high in the Coinbase.  

[01:01:51] Unknown:

Oh. Mhmm. Right?  

[01:01:53] Unknown:

The the correct way of doing that was to set the end lock time   on the coinbase   It's clean. It's already 32 bit field. It's designed to put a block height in there. Why the hell do you put it in the beginning of the,   the script pub key for that's like just that doesn't even make sense, right? So, there was a smarter way of doing it, but we're stuck with those old rules because that was, you know, it was early on. It was all a little bit more free and loose   and nobody   why?   There there there's several things going on. 1 is like not enough eyeballs, just not enough serious developers looking at it. 2, it wasn't important enough at the time. It was early days. Nobody cared. It was a little bit of experiment. And 3, nobody really understood that they were gonna be stuck with these decisions forever.   So, we're now aware of that and so there's a lot more eyeballs, there's a lot more thought, there's a lot more care going on about any upgrade.  

But there's also there's almost a counterpoint here, there's like a clock ticking. We know at some point   the protocol is going to ossify, right? We're not going to be able to upgrade anymore.   And we've talked about this anarchic upgrade process   and   I'm not sure that that works when your nation states are at play.   When there's so much on the line   that you can no longer have this   bonhomie of, like,   developers all getting around trying to mutually find out the best thing. But people start game playing and,   you know,   trying to sneak stuff in and   dishonest motives   start appearing.  

And that's inevitable,   and it happens with any   doing, you know, nasty gameplay to try to get their patented technology and all this kind of crap that occurs. Now, not universally, but at some point when things get big and important,   particularly when you get this generational shift of the original people move on,   we see this. Right? It no longer becomes an attempt to produce the technical produce technical excellence and becomes an opportunity to to to aim for your particular angle.   So   being aware of this, I suspect Bitcoin may be particularly vulnerable to this idea that   there will be   a huge amount of disinformation, and it will be increasingly difficult   to to to be confident that a change is good.  

And so at some point,   most reasonable people will go, no. Bitcoin cannot be changed anymore. I don't care how good your excuse is. It's not. Unless, you know, unless  

[01:04:31] Unknown:

the whole thing is imploding, we are absolutely not going to change it anymore. I mean, if if it doesn't play out that way, then this was always gonna be a failed experiment.   Like, it's it's one or the other, in my opinion. How close do you guys think we are to that?  

[01:04:47] Unknown:

Are we already there?  

[01:04:49] Unknown:

We're gonna find out every   every every time. Yeah. There's so much stuff to do. But every every time we have this debate, we wonder, is this the time that we're gonna just stall, right? Every time there's a software proposal you're always thinking in the back of your mind is this the one where people go no, no, it's not worth the risk.   It's not worth the risk to the system   to make this change that I don't think benefits me enough. And you should be thinking that. That is a totally fair and reasonable thing to think, right? Is this worthwhile?   People want to change this? Is it worth it, right? No change is free.  

And, you know,   how conservative do you need to be? That's an individual choice. You've really got you know, assess things. I don't think we're I don't think we're there yet. I'm pretty sure we're not there yet.   But I would suspect that we're we're we're going to get there at some point.   And, yeah, it I don't know.  

[01:05:47] Unknown:

Above my pay grade to figure that out. I mean but it it's kind of interesting. Right? Because,   I mean, we had Taproot, which I think a lot of us thought was gonna be more difficult to actually activate it, you know, implement and activate,   but that kinda just flew through   with the speedy trial activation.   And then   Jeremy tried to propose this with the speedy trial activation,   and everyone   flipped fucking shits. And I'm not saying that maybe maybe that's the right move to flip shits with that.   But,   like, how do you activate going forward? What's like, do you guys think speedy trial is a good   No.  

Method?  

[01:06:29] Unknown:

No. Nobody likes speedy trial. So so,   Taproot so so Taproot was just so unanimously,   obviously   great,   and opt in, so you didn't have to use it. It didn't take anything away.   It was, you know,   it had been really well studied, really well thought out. It had been a lot of time had passed.   We were pretty sure there was nothing better coming down the horizon. There were no big question you know, It it had all the things, including   a lot of time to bake and a lot of broad discussion, a lot of, you know,   you know, it it it had been done in the right way, and everyone was pretty comfortable with it. So I said at the time a blind monkey could activate,   Taproot and yeah. Sure. Speedy trial. We could have chosen any method. We could have chosen throw darts at the board and it would have activated. Right? So,   you know, it both wasn't a fair thing for speedy trial because it was so easy to activate.  

And also, you know, we're also at a unique time   where   nobody really has an interest in Bitcoin OsoFine, not any significant players.   And the miners were   a little bit cowed from their previous experience with, you know, forking.   And so,   you know, in in in view of all that consensus, it was gonna be really hard for,   for anyone to, like, push back on it. So it was almost optimal conditions for a fork.   I don't think we'll see that again. It will only get harder from here in.  

[01:07:57] Unknown:

I mean, I have a really controversial   attitude of how   I think fork should get turned on going forward.   I don't think miners or developers should have anything to do with it.   They actually half of the reason that I did that troll patch of my node last year to just enforce   Taproot from Genesys was,   me me and a buddy of mine have been talking for a while, and I think, actually, Rusty, in the next core release, this is something   developers are doing now.   But   just   I think everything should be a UASF.   I do not think that minors or developers   should really be deeply involved with the activation of anything.  

And I think that that is really the only way going forward to really   create a consistent   solidified dynamic where we maintain   this mob   and that dynamic where you don't just have   that devolve into figureheads that are perpetually followed and listened to. And I think that either   a feature done and turned on that way will gain the critical mass of support to successfully activate without too much disruption, or it will just be a bunch of goofballs like me with my single node getting attacked, while everybody runs away from the one true Bitcoin.   And,   you know, after that point, developers can just go back   and just   flip a rule on from   Genesis. Like, you wait and let   other clients or other groups actually get something turned on. And if it's successful,   then just flip it on in the next release. Like, I I feel that developers should kind of just step back   from the entire activation mechanic   and just implement the validation logic of something. And if it's if they people want it and it gets turned on, then just flip that activation   for, validation on in the next release.  



[01:10:03] Unknown:

But won't it always come down to FiguArts no matter what? Like, there's Yeah.   The the overwhelming majority of people do not understand  

[01:10:11] Unknown:

We should incentivize   as many of those as possible instead of just let things devolve to fewer and fewer of them. Fair enough.  

[01:10:21] Unknown:

I I think I think, you know, I have some sympathy with your approach. It's nice to have someone out there on the edge. Good luck to you.   There are real shelling points, Right? There are real points that make things a lot easier to deal with.   And having the developers go, cool. This is what we think is the best thing is a perfectly reasonable thing for them to do.   I do believe that it is very important that, you know, so so just just mechanically, there is a reason that you want to upgrade Bitcoin Core because, you know, there are CVEs or other things, you know, vulnerabilities in previous releases and other other reasons and speed improvements, you know. So   there's a danger in tying   upgrades to,   support for a particular,   fork. Right? I think just that's  

[01:11:13] Unknown:

That's the interesting thing though.   If if things were done my way Yep. Everything,   all those clients can be transitory.   Like, you you use it to turn something on and then switch back to court. Yeah. I mean How do you know if you hit the critical mass in your  

[01:11:30] Unknown:

in your situation?  

[01:11:32] Unknown:

We have a chain split or we don't have a chain split or we have a chain split and no one notices because it's me just yelling at Wang Chung on Twitter.  

[01:11:41] Unknown:

So so you end up having to sponsor, basically pay miners try to split the chain to find out people enforcing it. The true test of enforcement is when somebody produces an invalid block and it gets rejected and does not get built upon.   Now statistically, that can happen sometimes. So you've got to produce a few of them. Like, it's a really expensive test to run, but it is the only true way to test whether or not people are enforcing the rules is to break them. So you, like, pay the miner out of band or something? You literally have to pay a bunch of miners out of band to produce what are now invalid blocks to see if anyone follows them. Right?   It's really tempting   to to do. Fortunately, miners screw up all the time and so sometimes they accidentally do this experiment.  

But that that you'd have to have some litmus test there where where they and and they have to be stealth, right? So you can't just go, oh, well, all miners are blocking things from this pool because they know that pool is trying to produce invalid blocks and they haven't actually upgraded. They're just blocking. So, there are tricky mechanics in here,   and it could be producing a valid block and they, oh, hey, no miners built on that. Yeah, Yeah, but it happened to be produced at the same time as this other block and maybe they stole the other block. So you've got to, you know, there are problems with this approach. But   fundamentally that would be the test. Now before that everyone's nervous to use a new feature because they're not sure if it's enforced or not. So   the   minor signaling gives you a shelling point to go cool. Well, I'm pretty sure that everyone else is following that. My node has has activated is now enforcing that rule because it's sort of the minor signal. And I know everyone else will have seen the minor signal, So I'm assuming that all of us have moved forward together   and we are all enforcing the rules. So now I have some degree   of assurance.  

One, that the miners can't go back and stop enforcing the rules   because all the nodes are already switched on and they're enforcing the rules so the miner's block will be rejected.   Secondly, I can start using this feature pretty sure that everyone's got my back. Right? There are real shelling points here, and the developer's role as setting shelling points   for for for ways we coordinate things should not be confused with their endorsement   of a particular   fork or not. I mean, obviously,   they they have responsibility to do things that they think are technically correct. As individual developers are like, I really like the software. I think it's good for Bitcoin. Go ahead.   But I have always believed that there should be an option well documented to say no,   I do not want to support this fork. I want all the other good things, but no, I do not want this software to go ahead   with full knowledge and documentation that that means that you may be on your own. You may fork yourself off the Bitcoin network.  

But I think fundamentally that responsibility   no, fundamentally that responsibility is in an end user's hands,   so we should make it clear that it is in their end users' hands, right?   At the end of the day, the nodes get to decide what the network is and so we really need to make that   like putting gratuitous road bumps in like, oh, yeah, you could do it, but you've got to run this patch software from this weird place and everything else   is putting a hurdle in the way of them actually exercising that sovereignty.   And so I would argue that the developer should probably just give them all the pieces, you know, maybe set the defaults and say, cool, by default it will do this, but you can totally turn it off   and just embrace the fact that some people will do dumb shit and they may well fork themselves off the network. And,   I'm sorry. At the end of the day,   whether you like it or not, these people actually do have responsibility   and control   and so you might as well recognize it. I think trying to suppress it is dangerous. So what you're referring to is like a toggle in the the user interface? Like, there's you just switch it on or off? You've gotta be able to switch it on or off. Right?  

And I've already been  

[01:15:22] Unknown:

should try forking themselves off the network at least once. It's a invigorating experience.  

[01:15:27] Unknown:

Historically, there's been a ton of pushback on that as a concept. Right? Yep. Absolutely.  

[01:15:33] Unknown:

And I think there is, you know,   developers, it's natural to kind of go, well, we know the system best and we should decide. And the current crop of developers are fantastic and everything else, but I do worry about this generational change. Right? I do worry about, you know, I trust the existing developers. That may I trust all developers in the future? No. I have worked in open source software for 25 years. I have had developers   do stupid shit. I've had them go insane.   I have had them   sorry, I'm not qualified to make that diagnosis but I've had them do things that   take your breath away,   Things that you would not believe   that no normal   just things that you would consider to be extreme   irrational behavior. I've seen that. Breakdowns,   you know,   self, you know, self destructive behavior, all these kind of things. Anything that you can say considered human done, do,   I've seen developers do it. It's their own projects and everything else. Right? So while generally, I think open source developers are these godlike figures who strut across the world and bring peace and happiness and all those things that we do,   you know, I my experience has led me to believe that, you know,   while I love them, I don't want to trust them   and, you know, and things can go wrong. Right? So,   I think the more software developers would like to get rid of this. Any perception of this having this power,   over the network.  

You know, and I think some of the younger developers don't don't feel the same,   don't feel the same   urge   to to to withdraw themselves. Right? I I think that's something that comes with time and experience.   And I worry that, you know, the next generation developers will will feel that they're the logical masters of the network, and I think that's dangerous.  

[01:17:25] Unknown:

Hear hear.   Yeah. I mean, we we we actually, I think there should be a historical   course   for new developers   on the likes of,   Gavin Andresen and Mike Hearn.  

[01:17:41] Unknown:

I'm I imagine, like, most people listening to the show right now don't even know who those people are. Right?  

[01:17:48] Unknown:

Very, very possible.   I I am constantly   these days just   randomly thinking, like, half of the Bitcoiners who got here since 2017   don't even know who Greg is.  

[01:18:03] Unknown:

Kids these days. Kids these days.   Look,   you know, look, you're not a Bitcoin OG unless you're in Bitcoin before me. Right? That's always everyone's definition of Bitcoin OG.   So unless you had, you know, unless you're on the IRC channel, Bitcoin OTC,   trying to get Bitcoin and using your GPG address to, like, you know,   to do that, then you're not a real OG Bitcoiner. Sorry.   So   yeah.   Yeah.   I I think   I don't know. I   inevitably,   you know, some knowledge will get lost and and people will will come in with different viewpoints. And as we go more mainstream, this is inevitable. But I do like the idea that,   we have a whole heap of,   you know, I think it is important for Bitcoiners to realize and I believe that they do, that they have a responsibility,   at the end of the day. If you're a sovereign individual,   then you are going to have a lot of responsibility over your own your own coins. Right? Just running your own node, it's it's it's having your own stuff and it means upgrades   are, for better or worse, are gonna be your concern.  

They're gonna affect you to some extent, or at least you should make sure that you're happy that they don't affect you.   Right?   But, yeah, I don't know. Maybe that doesn't scale.  

[01:19:24] Unknown:

I mean, even if we don't have ossification,   like, pure ossification anytime soon, I think for, like, these major changes,   the safer approach   tends to just be,   to default to no.   Right? Like, I was with with this CTV conversation, I was hoping   it was just gonna kinda go away.   Didn't really wanna have the conversation or learn about it.   And, like, my hand was forced, and a lot of freaks were like, Matt, you need to have a conversation about it on sale of dispatch. I was like, I really don't wanna I don't even wanna do it. Like, I just don't wanna update, don't wanna bother with it. I mean, like, that's perfectly, like, rational. I mean, to to say no by default, to be conservative  

[01:20:08] Unknown:

to changes,   to go, I don't understand or see how this benefits me. I'm not okay with this. All of those things are   completely reasonable   and what   this system should be built on. The thing that's been driving me insane, like, the last 2 weeks   is all of these people, like, confidently asserting, like, all these things that CTV can do to be a huge risk to Bitcoin or, like, break the system. And it's just like, no.   That's factually incorrect.   Either make a reasonable argument for why,   you don't wanna do this, learn what you're talking about, or shut the fuck up.  

[01:20:51] Unknown:

Yeah. Absolutely. And look, I'm I'm with Matt here. I was like, I don't wanna care about this.   And I have a day job, and this is not it. So,   you know, I'm I'm concentrating on lightning and all those cool things, but,   you know, it it it reaches a certain point where you're like, okay. I've gotta to weigh in, I've got to have an opinion, I've got to read the bib, I've got to think through it,   and all those things.   So I am also dragged here reluctantly.  

[01:21:16] Unknown:

It's like a critical mass thing. Right? It's like you there needs to be a certain critical mass or momentum to get any kind of real change in or get people to care about it.  

[01:21:24] Unknown:

Yeah. And classically, there's a certain amount of well,   everyone's really busy doing cool stuff and everything else. And so   almost   it needs to get to the point where people feel, Oh, crap. It's happening now, before the leaders start paying attention,   which   is too late. You really hope that everyone was paying attention the whole time. And by the time it got to the, oh, it's about to happen,   you've had all those debates, you've had all these arguments, there's broad consensus.   But in practice, it doesn't work that way. Right?   Yeah. Same with Taproot. Right?  

Everyone's happy with it. It shipped. And now people are finally starting, Oh, we better start building all the stuff that we promised. Right?   So that's human nature,   and that's  

[01:22:06] Unknown:

okay. But yeah, I'm as much a victim of it as anyone else. What was your when I invited you on the show, Rusty, your response was something like, Oh, I would love to join, but why do you have to choose that topic?  

[01:22:20] Unknown:

Yes. Yeah. But to be fair, again, like maybe get off my ass and post that off t x proposal that's been sitting in my inbox for, like, all my outbox   drafts for a while that I've been bouncing   bouncing back and forth with Anthony Towns,   who had some good feedback.   You know,   and I went okay, well I needed to post that last night, my time, or this morning, your time, because I'm like, well, I'm gonna appear on Citadel Dispatch, so I better have better bring something to the show. Right? So so that that was that was an incentive for me to finally   push that out.  

Love it. Yeah. Otherwise, we would have done this last week.  

[01:22:59] Unknown:

I I love that. I,   that's my contribution to the development process.  

[01:23:06] Unknown:

I mean, I think, like, honestly,   short, like, the people who've just been actively   spreading misinformation   instead of just being a healthy level of skeptical,   this was a really healthy thing to happen. Like, it's forced   actual information   out into the community so that people can start really understanding this. It's brought the whole   topic of covenants to, like, the wider discussion. I mean, all the   the annoyance, the nonsense, the drama, I think at the end of the day, this was a a really healthy thing to happen.  

[01:23:42] Unknown:

Yeah. And, you know, it's it's interesting because there's only a handful of people who have experienced covenants.   And, you know, that that will increase as people start playing with them more as they seem more real. And that feedback loop is gonna be interesting because I don't quite know where it'll lead.   I would look to people like Russell O'Connor, who is the the other   Russell at,   at Blockstream.   And and and you can tell us apart, by the way, because if we're having an argument over something technical, he's the one who's right   and I'm the one who's wrong. So so so, you know, I I always you know, it'll be interesting. I think that as our as our thinking matures, there'll be people come forth with with other ideas, and we will reach consensus because I feel that we haven't had that   level of, like, really rigorous oversight so far in this conversation. Because I think most people being just staying on the sidelines.  



[01:24:32] Unknown:

I mean, I I tend to agree that it it does feel like this was overwhelmingly a healthy conversation and that one that needed to be had. It kinda feels like   I mean, we should have probably had this conversation before Taproot got activated,   but at least we're having it now. Well, I mean, ironically,  

[01:24:50] Unknown:

when Taproot was still in development, Jeremy was trying to get CTV included in Tapscript   so that it could be embedded in a Taproot tree.  

[01:25:02] Unknown:

Yeah.   Same with, you know, anyprevout   was the other one that   was people were thinking, you know, hey. We we really want this in. And, you know, there's particular work around making sure that it could go in later.   And this is the same. Right? It's like, well, if it can be unbundled, it should be. And particularly, yeah, Taproot was was a pretty big big deal.   So that that, to be fair, it's gonna take us, like, 5 years to truly exploit.  

[01:25:30] Unknown:

Yeah. Speaking of,   is, is simplicity still 2 weeks away?  

[01:25:36] Unknown:

Yeah. Yeah.   Yes. Again, ask ask Russell O'Connor. I mean, you know, simplicity is one of those things that's incredibly ambitious.   And, really, for humans like me to use it, it's gonna have to be you know, there's gonna have to be, like, tooling on top that that does the thing and turns it in simplicity and and, you know, and does a lot of the great things that it does because, you know, I'm not smart enough to write raw simplicity.   Hell, I'm not smart enough to write raw Bitcoin scripts. So, you know,   tooling definitely has a long way to go on both of those.  



[01:26:05] Unknown:

Simplicity makes my head hurt.   I barely understand   any of it beyond the logic of formal   verification,   and there's definitely value I see in that. But,   yeah, I I I could not   say 2 sentences besides it would let us do more complicated things and be sure they won't explode.   Yep.  

[01:26:30] Unknown:

Yeah. Look, simplicity is a great idea. So so for those following along,   simplicity is basically a a completely different scripting system, basically, that that that Blockchain Research,   under Russell O'Connor have been developing,   particularly with an emphasis on being able to formally prove stuff about it   in in useful ways.   So it's   it's really great stuff so you can go cold. Okay. I I can prove that these coins will be spendable under these conditions and whatever else.   So,   it's it's great from that point of view, and it's called simplicity because basically the fundamental level at level, it's very, very simple, and you build everything up from that.   But simple doesn't mean easy. Right? So,   so it all comes down to, like, the tooling and and your ability to actually utilize this. And, you know, just because you can prove that something happens doesn't necessarily mean that you prove what you want it to happen. Right? You can still foot gun yourself, I'm pretty sure.  

So  

[01:27:26] Unknown:

well, anyway, guys,   this has been an absolutely fantastic conversation.   I know we're hitting the point where Rusty has some other responsibilities   to take care of.   I I really appreciate both of your time.   You know, this conversation has been very helpful to me. I often say that my favorite dispatches are the ones where I just sit quietly and listen,   and I really needed this conversation, so I hope the freaks have found it helpful as well.   I like to end the shows with final thoughts.   So with that said, final thoughts, Shinobi.  

[01:28:00] Unknown:

Well, I guess just,   you know, I would say when things like this come out of left field,   like,   no as a default answer is totally reasonable.   Like, caution   and or   skepticism and even paranoia   is totally   rational.   But,   like, you should not cross the line of actively misinforming   people   and stating things that you are not sure of or that are just hearsay to you about something being proposed   because that actively attacks and undermines   the entire process of understanding something to see whether there is or isn't consensus.   And also, Rusty,   because of the time constraint and,   us not being able to get into that, I am going to twist your arm to come back on sometime to talk lightning because this is a really fun conversation.  



[01:29:00] Unknown:

Yeah. We should totally do that. Well, thank you, Shinobi. I agree that we should have that conversation as well. And, final thoughts, Rusty.  

[01:29:08] Unknown:

Yeah. So covenants are not necessarily something to be feared. Bitcoin script is getting more powerful and, you know, there's always been good and valid questions over that.   I do think, you know, there's a meta incentive question that that is harder to answer. Like, as we make Bitcoin more powerful, are we risking people build things on top of Bitcoin that we don't like either because they do stabilize Bitcoin or because they're stupid or whatever else?   But, fundamentally, they are that on a technical level, I think, you know, there's nothing,   you know, there's nothing   evil or novel about,   Bitcoin covenants. On the other hand, I actually watched Shinobi said that, you know, caution is,   you know, as long as not gone to ridiculous lengths,   caution is very, very important to Bitcoin.  

And so we should be slowly and carefully. That means it's gonna take years, and that's okay.  

[01:29:56] Unknown:

Cheers to that. Well, I wanna thank you both again.   I look forward to having you both on dispatch in the future to have that lightning conversation and other conversations, hopefully.   And I wanna do a huge thanks to all of our listeners who continue to support the show and join us in the live chat. Cheers all. Thank you.  

[01:30:31] Unknown:

My hole you build   a wall.   City   on a hill.   Gonna build their city   teas are gonna spill.   So   until it's   done.   Don't   build that wall   the ground, searching to behold the stories that I told. My black ones to the world that was smiling when I've heard,   tell you we are the greatest. Put   my  

[01:35:28] Unknown:

Love you, freaks. I hope you found that conversation as helpful as I did.   Really do appreciate all your support watching the SAD stream in, watching the boost come in   through the podcasting 2 point o, watching the BTC pay server get hit.   It really is an honor and a privilege   to be with you guys every Bitcoin Tuesday.   It's something that I really do love doing, and I appreciate you all.   Now it's time for me to   have 20 Bitcoin over 20 Bitcoiners over and grill them some stakes.   Love you all. Stay on, BoomstackSats.   Cheers.