Breaking Down Taproot Activation Options - NADO 3

Aaron van Wirdum Live from Utrecht, this is the Van Wirdum Sjorsnado. Hello. Sjors, welcome.

Sjors Provoost Thank you. We're going to pretend that this is the first attempt at recording.

Aaron van Wirdum Nothing went wrong before this. Everything's been going fine so far. That's what we're going to act like. Yeah, okay, so for context, guys, I promised our listeners we're going to improve the audio recording every episode. We've just spent, by now, 75 minutes trying to get the audio right. I think we finally managed a workable solution. It's really unbelievable how hard it is to get this right. Either it's just hard to get the software right, and then if we finally get the software right, then I'll... Fuck something up for sure. And then we're not recording at all. But I think at this point, Sjors, we got it right. We're in a situation that it's working well enough that we can sort of continue.

Sjors Provoost It's just a matter of pushing a button and everything works.

Aaron van Wirdum Okay, let's just go. Let's go. Let's go. Technical stuff, Sjors. Here we go. What do you want to talk about? We're going to discuss Taproot. No, last week we discussed Taproot. Yep. This week we're going to discuss Taproot activation, or more generally, soft fork activation. This has become a topic again in the sort of Bitcoin debate, community, public discourse. How do we... activate soft forks because Taproot is getting to the point where it's sort of you know ready to be deployed almost I think so now the next question is okay how are we actually gonna activate this this has been an issue in the past with several soft forks And it came up in the mailing list, I think, a couple of months ago. And now it's sort of re-emerged. There's now an IRC channel where it's being debated. There's a Telegram channel. I wrote an article on it. It's back on the dev list.

Sjors Provoost yeah i read the whole irc channel no actually i started reading the irc channel i got stuck at the meta discussion about whether or not there should be a telegram channel and whether or not you need to ask permission and whether or not asking permission was off topic in the irc channel and after an hour i gave up and you spent your entire saturday i believe

Aaron van Wirdum i spent most of my saturday reading for all of the logs and sort of trying to summarize it into an article yes yeah i i didn't read past saturday so if there was any sort of big discussion or development since Saturday, I might be out of the loop a little bit, but that wasn't really my impression. I think I covered most of it, so I think we can cover most of it in the podcast as well.

Sjors Provoost So maybe we should say what a soft fork is.

Aaron van Wirdum Let's start there. What is a soft fork, Sjors?

Sjors Provoost So it's basically a tightening of the rules. An analogy I like to make is with kosher food. I've made this analogy three times.

Aaron van Wirdum Yes, this is the third time you're making the analogy because we're recording this start of the podcast for the first time, which is annoying. But let's just go on.

Sjors Provoost Basically, kosher food is a subset of regular food. So there's a few things you don't eat. So often you might not notice it. There's a lot of soft drinks that are kosher and you wouldn't know the difference. But sometimes you would know the difference and that could be a problem. But with Bitcoin, there is no such problem. Because the things that are no longer allowed after soft fork are very stupid things.

Aaron van Wirdum So hang on. The thing you're saying is that soft fork is backwards compatible in the context of Bitcoin. And the reason for that is like, let's say I go to a restaurant every day because I love the food there. and then one day they introduce kosher food and the food is still great I can still go there because I don't care if it's kosher or not. So there's tighter rules. I didn't care about whether or not it's kosher, so it's fine for me.

Sjors Provoost But you would if your favorite recipe was now kicked out of the restaurant.

Aaron van Wirdum I would care if they get bacon out of the...

Sjors Provoost Exactly. But this is not the case the way Bitcoin soft forks works. So they wouldn't remove your bacon, basically. They would remove your ability to stab yourself, basically. And so it's a nice and elegant way to make the rules more strict without suddenly freezing anybody's coins. So normal people can keep using it. They don't have to upgrade. They can keep using the old rules if they want to. An exchange can basically ignore SegWit for years, and it's perfectly fine, as far as the blockchain is concerned. I guess we can talk about some examples. So Satoshi introduced soft forks in the very beginning in a way that we wouldn't do anymore. Basically, one of the things he did was introduce a one megabyte limit. There was no limit. He realized that was bad, dangerous. So he put in the limit. And then later on, when it was already active, he said, oh, by the way, there's a limit.

Aaron van Wirdum Yeah, so that's an interesting example that I didn't mention in my article for Bitcoin Magazine, which is... So, I mean, we're going to discuss how to implement soft forks, how to upgrade the protocol. And one of the examples that Satoshi used was to basically just snuck it in there. Yeah. And, you know, only once people are running the code, they'll figure out that there's now one megabyte limit. Right. Which worked at a time, I guess. And maybe it was even a good way to do it because in his mind, he was probably fixing like an attack vector. Yeah. And in that case, it made sense because you tell people about it and that increases the chance of the attack vector being exploited.

Sjors Provoost Right. But it can also happen by accident. You accidentally add a rule to the system that you didn't know was there. So that sort of stuff could happen, but that's not what we're going to talk about. We're going to talk about a deliberate change in the rules. And so the other way that was done when there was a new rule was a flag day to say basically from this day forward, this new rule shall apply. And you announce that plenty of time in advance and then people upgrade and it's all good.

Aaron van Wirdum Yeah. So you have to say like... One year from now, so that's like July 24th, when this is being published, I think. July 24th, 2021, that's when the new rules are enacted. Right. Or you say at block height, I don't know, some block height in the future, at this point, the new rule is enacted.

Sjors Provoost Yeah. But there was still a problem there. Which is that you want to make sure that everybody's actually running the new software. And especially that miners are running the new software. Because they kind of have to enforce those new rules. I mean, it's nice if they, it's really nice if they enforce the new rules.

Aaron van Wirdum Well, everyone's enforcing the new rules. Or at least everyone who's upgraded is enforcing the new rules. But if a majority of hash power does it, that means they always reclaim the longest chain. Even for the non-upgraded nodes, like they still consider that a valid chain so then everyone old and new nodes will converge on this chain yeah that's why it's very nice if a majority hash power enforces the rules as well

Sjors Provoost exactly and for miners there's a risk if they if you know a majority of miners implement uh enforces the new rules but the minority doesn't they could accidentally mine the wrong block

Aaron van Wirdum yeah the minority could mine an invalid block and then have their block orphaned

Sjors Provoost exactly they might not even know why if they're not upgraded

Aaron van Wirdum exactly so

Sjors Provoost it's nice that miners signal that they're ready to do this upgrade so that, you know, you can get an idea, okay, most miners are clearly ready and a few miners that are not, well, hopefully they'll be fine.

Aaron van Wirdum So that's sort of the other upgrade strategy apart from just stuffing it in there without telling anyone. You have flag days and you have miner activation so signaling so the signaling works as a coordination mechanism for the network to figure out okay enough miners have upgraded now this signals to everyone the network is ready and through this signaling mechanism a date or a time or a block height is you know communicated essentially that's embedded in the code that if enough signals are included in the blockchain then we all know at block height x the new rules will go into effect.

Sjors Provoost Exactly. So usually it's every two weeks. You count the number of blocks that have the signal. And if it's above a certain threshold, for example, 95%, then you know that two weeks later, the new rule is active.

Aaron van Wirdum Yes, that was BIP9, which you're explaining now. The Bitcoin improvements proposal 9. uses this difficulty period, 95%.

Sjors Provoost So these are the three main mechanisms, right? You can just randomly do this, you can announce a date, and you can have miners signal up to a certain threshold. And now the question is, what are you going to do for taproot, and what have we done in the past? And maybe you want to combine some of these methods.

Aaron van Wirdum Yeah, well, should we mention why BIP9 is a problem?

Sjors Provoost Well, so BIP9 was used a couple of times to deploy some features, I believe. But when it was time to deploy SegWit, it took a long time. We don't know if it would have happened eventually, but at least for, I think, at least half a year or so that the code was ready, it just didn't activate. Only a small percentage of miners was signaling for it, or at least not the 95%.

Aaron van Wirdum Yes, but we have a pretty good idea why that was. I mean, at least the miners that were blocking it were telling us why they were blocking it.

Sjors Provoost Yes, exactly. I mean, it's possible that some miners were just completely not interested. Yes, that's all. There was definitely miners that were actively not signaling it.

Aaron van Wirdum Yeah, miner apathy. That was probably a factor for at least some miners. Sure.

Sjors Provoost So what happened then is a number of different things happened outside the blockchain. There was basically a group of people that said, hey, you know what? We're just going to, instead of the signaling, we're just going to go back to the old flag day approach. And that was called BIP-148. So they picked April 1st, 2017 and basically said, well, our nodes are now going to enforce these rules.

Aaron van Wirdum Yeah, but hang on. So to explain this real quick, the downside of BIP -9 was that miners were blocking the upgrade because they wanted either political leverage or they were secretly benefiting. from something that the upgrade would have fixed without telling anyone that that was the case or both like but there were bad reasons basically for the miners to block this upgrade and this made Bitcoin Core developers and other Bitcoiners realize that okay there's actually kind of a downside to BIP9 because it gives miners this leverage which they shouldn't have at all like they're treating it like a vote. And they're sort of abusing their vote in ways that's bad. While it's not even meant to be a vote, it's just meant to be a coordination mechanism.

Sjors Provoost Exactly. And also the reasons why you might want to oppose a proposal generally should be technical in nature and not political. Yes. So, I guess that.

Aaron van Wirdum Yeah, so ultimately, and this is what you were getting at, this was resolved in some way or another, and there's still debate to this day how it was resolved exactly. Right,

Sjors Provoost because two things happened at the same time, right? You had the BIP-148 UASF rules, the guys with the guns and the nodes.

Aaron van Wirdum Or with the hats. I don't think they had guns, but they had hats.

Sjors Provoost One of them had guns.

Aaron van Wirdum Oh, yeah. Yeah, that's true. I think they were like...

Sjors Provoost Defending the Bitcoin.

Aaron van Wirdum Yes, that's true. That's true. And I think Tone Vays had like a knife.

Sjors Provoost And... And so then the question is, you know, you can tell if you read all the social media and the mailing list that that obviously played a role. But if you just look at the blockchain, you can't really tell because what you see on the blockchain is all of a sudden 95% started signaling and the thing activated. Sure. Now, it's, of course, very remarkable that this activated exactly before August 1st and not some random other date that it could have happened. But there were no blocks rejected that we could still point at saying, hey, look, there was actually a fight between miners, etc. At the same time, there was an initiative from the New York Agreement Group. And they had a whole bunch of things that they were planning to do. But one thing they were doing is called BIP 91. And they would basically lower the threshold. So they said instead of having 95%, we're just going to accept 75%.

Aaron van Wirdum Yeah, well, to be a little bit more precise, what they did in the end was use 75% forced signaling. So it was like BIP-148, but it was like a soft fork to activate a soft fork.

Sjors Provoost Yeah, so basically you had to signal that you were going to act... that you were going to activate the soft fork.

Aaron van Wirdum Yes.

Sjors Provoost And then because there was more signaling, it would activate. But that, again, you cannot tell from the chain because immediately people started signaling at 95%. And so that's the nice thing about these kind of situations. You can't really tell what happened. It didn't go wrong. Nobody called each other's bluff.

Aaron van Wirdum Yes, and I think everyone agrees that it was at least sort of a tense period. It showed everyone that maybe we've got to rethink how we're actually going to do soft forks because this was very close to becoming a huge mess.

Sjors Provoost If you think through the worst case scenarios, which I guess we'll just avoid now because it'll get too confusing, but if you have chain splits, and especially if you have multiple chain splits with people... people having different opinions about what the blockchain should be that kind of defeats the purpose of a well -functioning blockchain so it's something you want to avoid

Aaron van Wirdum yes yes and let's skip the details but it would have um there was a risk of it becoming a pretty big mess i think that we we both agree on

Sjors Provoost I was worried for quite a while it would be an absolute clusterfuck. yes

Aaron van Wirdum so new ideas how are we gonna How are we going to think about soft forks and soft fork activation from now on?

Sjors Provoost Well, one thing that was done is a proposal, a revamped proposal called BIP-8. And yes, that's a lower number because the proposal was older, but now it's actually newer. So that is confusing. But generally, there were just a couple of improvements to the original mechanism. Maybe not super interesting. For example, using blocks instead of dates.

Aaron van Wirdum Well, explain what BIP8 is in the first place.

Sjors Provoost Well, BIP8 was, I think, just a flag date proposal.

Aaron van Wirdum Was it originally just a flag date?

Sjors Provoost Yeah, I think so.

Aaron van Wirdum Okay, but later it was definitely, like the idea was that it was... A combination of BIP9 and a flag date, basically.

Sjors Provoost Right, so what it is now, at least, that's probably the most useful thing to describe, is the signaling is still there with some tweaks, but there is also a built-in option to have a flag date.

Aaron van Wirdum And

Sjors Provoost now BIP is just a sort of a proposal of how you could do things. And so you could use the flag date or you could not use the flag date. But the proposal now explains, okay, if you have a flag date, this is how you do it. And it's a one -way mechanism. So you could propose a new soft fork and not set a flag date and then later on set a flag date. But you cannot propose a flag date and then unset it, basically. So if you decide on a flag date, you better go through with it.

Aaron van Wirdum Well, you can release a new client that doesn't have the flag date, of course.

Sjors Provoost Yeah, but now you have a mess.

Aaron van Wirdum Well, one of the nice things about BIP-8 is actually that it doesn't have a flag date purely. It has a force signaling deadline. So it's kind of like BIP-148 before, where... If you have the flag date on, so let's just call it the flag date for now, then it doesn't mean that it activates the soft fork itself. It means that... If near the end, any block that's not mining activation, not mining support for the soft fork, that block will be orphaned. So it forces signaling towards the end. So this means that if you have two groups of BIP8 nodes, one of them has the force signaling on and one of them has the force signaling off. But miners go along with the force signaling on. then the nodes that have forced signaling off will still accept the soft fork because they're still seeing...

Sjors Provoost They're still seeing the signaling.

Aaron van Wirdum Yes, exactly. So that's a slight change from previous BIP-8.

Sjors Provoost Yeah. And I forgot whether... I think you still need to... If you have a flag date in mind, you may still need to put it in there because you don't want different people to have different flag dates. So I guess it doesn't matter if you force signaling, but... It just becomes a mess because if you force people to signal and then they don't signal and you just decide to not accept all their blocks, if only a small number of people do that, then you still get a mess. So I don't think it's completely thought out, but it's definitely... You probably still want to have some consensus. If you decide on the flag date, you want to have a very large consensus on what that flag date is and that really everybody goes along with it.

Aaron van Wirdum but maybe i mean it depends right like if even if you don't have consensus but at least miners don't don't want to see splits or they like it they could play it safe. that's sort of how BIP 148 happens right

Sjors Provoost yeah but now imagine if you had two different like one you had the august 1 group and you had the august 15 group And maybe it didn't activate at August 1, but some major exchanges decided to join the August 1 group, and some other major exchanges decided to join the August 15 group. So it would still be a mess.

Aaron van Wirdum Yes, the assumption is that in that case, or the hope is that in that case, miners just go for the August 1 one, so they don't split the network.

Sjors Provoost That's one option. But I think at least an improvement here is that, let's say you just have miner apathy. You thought you can get 95% signaling, but there's apathy. You can have another discussion on mailing lists, and everybody says, yeah, yeah, we're fine with this upgrade, and no miners objecting to it. They're just not bothering to upgrade their software to signal. Then you can calmly agree on a date as a flag date and just calmly add it, and there's not going to be too much chaos. But you still have the problem of the miners not enforcing the rules.

Aaron van Wirdum okay so i think these are sort of the basics of BIP 8 and the next thing is that you can sort of play around with the parameters in all sorts of way so we've already mentioned with or without flag day and the flag day in turn can be an actual flag day or force signaling then you can play around with like a parameter of how long how far into the future should this flag day be yeah you can play with the parameter of how much hash power do you need so so far we've mentioned 95% but you could lower this you could say 75% is enough 50% is enough even one percent is enough you could potentially do that right yeah

Sjors Provoost that's pretty useless but you could yeah

Aaron van Wirdum i i agree but like the point is you can play around with this parameters in all sorts of ways so now you sort of have pieces of the puzzle and then you can think of ways to put these pieces together to come up with like a concrete activation strategy that we're going to use for taproot yeah but you

Sjors Provoost can also imagine that there's going to be a lot of permutations and so this could It could be a bike-shedding nightmare. Yes.

Aaron van Wirdum Yes, it could. But shall we cover some of them? Some of the sort of general ideas that are floating around?

Sjors Provoost Yeah, sure.

Aaron van Wirdum Okay, so one idea that has been proposed by Matt Corallo, a well-known core contributor, he calls it modern soft fork activation. So what he proposes is, let's use BIP-8 without forced signaling on the end or without forced activation on the end for a year. So that's more like BIP-9. That's what we used to do. See if miners activate it, just requiring a 95% hash power support threshold. Let's see if they do it or not. If they do it, great, soft fork has been activated. If they don't, then phase two of this proposal comes into play, which is six months of developer reconsideration. So developers see if there was a good reason for miners to block it. Maybe there was a problem with a proposal, in this case, Taproot, that they hadn't considered before. So developers are just going to sort of reconsider. If after six months they haven't found anything wrong with the proposal and they concluded that, okay, it's actually just miner apathy or miner— miners, you know, trying something or whatever, like no good reason, then we're going to deploy it again. This time, you know, BIP8 with... Either force signaling or...

Sjors Provoost With a flag day.

Aaron van Wirdum Flag day on the end. I think Matt's original idea was flag day on the end, but he's probably open to force signaling, I would imagine.

Sjors Provoost I mean, the question is, if you have a flag day, what do you do on the flag day? And one thing you can do with a flag day is enforce the soft fork, and the other is you can force the signaling, which then triggers the soft fork. Well, exactly. So I don't think that's more of a detail. And it's probably not controversial to force the signaling instead of forcing the soft fork.

Aaron van Wirdum Yeah, I think that wouldn't be very controversial.

Sjors Provoost It just makes it more compatible with what other people are doing.

Aaron van Wirdum Yes, exactly. So that would probably be, yeah. Okay, so that's one idea. It has, you know, the benefits of sort of taking it easy and reconsidering if there's maybe something wrong with the proposal. And if there is something wrong with the proposal, then people don't have to actually... need to upgrade their software they can just you know keep running whatever they were running yeah because um there was a timeout anyway in the software it just didn't happen and it's sort of fine there's no no sort of emergency upgrades needed at all or anything like that yeah um the downside is that if miners don't cooperate it's going to take a long time before the soft fork actually is live on network like three and a half years yeah So that means app developers have to wait three and a half years. Everyone's just sort of stuck waiting for three and a half years for basically no good reason. So that's why some people really don't like this proposal.

Sjors Provoost Yeah.

Aaron van Wirdum What do you think?

Sjors Provoost Well, you've got to think in the long run, right? So it's nice if you can have these improvements shipped very quickly. But if there is a tradition that developers decide on a soft fork and it gets activated quickly, well then... Maybe a government starts calling developers and saying, hey, we have this KYC soft fork. And since nobody really pays attention and miners run anything you want, why don't you just make that soft fork and don't worry about the review process? So you don't want to put too much power in the hands of the developers. They don't want that kind of power because it means they're going to get very unpleasant phone calls at some point. You know, it's a difficult trade-off because on the time scale of 200 years, it really doesn't matter if the soft fork takes three years longer. But we have no idea what the right time is. You know, maybe it makes no difference for this political problem. It might really just be wasting three years. Or it's really important to make sure there's no problem. So I'd like to see it deployed soon and hopefully miners are excited. But it's going to get more and more difficult to deploy these things in general because if you get, and we want that, lots and lots of very small individual mining pools, well, trying to get 95% even just to communicate to them is going to be harder. And that's a good thing, but it could slow things down very.

Aaron van Wirdum Sure. So another idea is BIP-8. um let's say with like a year deadline at which time force signaling happens almost kind of like a basic proposal would it be so to first ask you about that do you think that's too fast one year

Sjors Provoost so my problem with the force signal is if you if you [unclear] if you ship this thing and you say okay miners can signal for it but but if they don't it's going to activate you kind of lock yourself into that outcome, there's no real way to object anymore. Because even if people have, if miners come up and say, hey, wait a minute, there is a problem, then you can't cancel it anymore because people are running this new software and they have the force signaling in. So lots of people would see their nodes just stop. So you're essentially having a hard fork if you decide to not do it. So what I think you should do at minimum is say, we ship this version without the hard-coded date in it, but we're probably going to enforce that hard-coded date in a new upgrade.

Aaron van Wirdum Yeah, well, that's another proposal, and I want to get there next. Okay. So

Sjors Provoost this one I don't like, because if you remove any ability to object, then why even bother with the miner signaling? Because once you put a flag date in the code, and you ship that code, that's it. It's just going to activate.

Aaron van Wirdum yeah well the idea behind

Sjors Provoost unless you force people to upgrade and that's a hard fork

Aaron van Wirdum yeah although the idea behind any soft fork including taproot presumably is that there shouldn't be a problem with it if it's going to be shipped at all like at the point of it being shipped there shouldn't be any problems with it yeah and after that it's just a matter of coordinating the upgrade but

Sjors Provoost the question is when are people going to bother to review it and i could imagine that if i'm a miner and i'm like i have to run this new version let's see what it's doing right holy shit i don't like these new rules why are they reducing the block reward right yes

Aaron van Wirdum that's that's one of matt's arguments as well that people and miners will only really consider it when the code is out there and the software is out there yeah

Sjors Provoost and it's an expensive signal too right from As a developer, you're really shipping this software. That's a bigger commitment than saying, okay, looks good on GitHub. So I think that is a critical moment, and you can't expect review to happen after that or review to happen after that. So that's why I don't think you should put the date in stone, at least not the first try, maybe half a year later. Maybe you don't have to wait for the whole year.

Aaron van Wirdum Yeah, so a related idea, and it's almost kind of the same idea, I guess, but it's Luke Jr.

Sjors Provoost Luke Dashjr.

Aaron van Wirdum Yeah, Luke Dashjr, Luke Jr.

Sjors Provoost People call him Luke Jr., but he once said in the podcast it's Luke Dashjr.

Aaron van Wirdum Oh, he did?

Sjors Provoost Yeah, the Peter McCormack show. That's the first time I learned. Alright. Maybe he's lying.

Aaron van Wirdum No, he's not allowed to lie, according to his religion. Okay. He likes BIP-8 with force signaling towards the end, but he prefers it to be deployed in... forks for clients so not in bitcoin core so kind of like BIP 148 like he thinks soft fork activation should happen through different clients that sort of takes away this pressure on bitcoin core developers like potential uh you know government uh enforced soft forks that sort of stuff so only do it through forks of bitcoin core forked clients what do you think of that idea

Sjors Provoost well how do you coordinate the date Someone just

Aaron van Wirdum picks one or it's sort of coordinated in some Slack channel, like happened with BIP148.

Sjors Provoost Yeah, the problem is, like we discussed before, if you have multiple dates, you're going to get the cowboy bias. Because whoever picks the most aggressive date, that's the party you kind of have to listen to. But that might be a recklessly early date.

Aaron van Wirdum Kind of, but like we mentioned before with the kosher food. a soft fork shouldn't have any downsides really or at least that's when it's becoming but

Sjors Provoost a fast activation could still cause problems yes

Aaron van Wirdum but then that's the downside in itself yeah so if people in general think okay this is too aggressive like this isn't good for bitcoin to do this aggressively then that's the reason itself i think it might fail so there's but

Sjors Provoost the problem is with this you know the the minority rule the intransigent minority rule that taleb likes to talk about yeah so the most fanatic group So probably the most fanatic group is going to say the earliest date and the rest will have to just go along with that earliest date. No,

Aaron van Wirdum not if the rest really dislikes the solution. The only reason it works with sodas is because most people don't care either way. But if most people really cared about what was in their soda, then the minority wouldn't get their way necessarily.

Sjors Provoost I would prefer if you went this route and there's some merit to it, I would still like at least the development community, like people on the mailing list, to agree on a date. And then once that date is agreed on, we say, okay, we're not going to endorse this thing. But if you do this thing, here's the download. And we all have the same date in mind. So there's no chaos around the date. Yes. And then there is something to be said for not having...

Aaron van Wirdum But they don't seem to agree. So that's going to be tricky as well, right?

Sjors Provoost Who doesn't agree?

Aaron van Wirdum Well, I think, for example, Luke, I think also Jeremy Rubin, to name a few names, they'd like a much faster activation date than, for example, Matt Corallo. Or I think AJ Towns is also someone who prefers a slower activation date. So there's disagreement there, it seems. So that makes it kind of tricky, right?

Sjors Provoost Yeah, it may be that that ends up in something that will forever be known as the Bikeshed Wars.

Aaron van Wirdum Well, but then... the cowboy might actually come around and...

Sjors Provoost Yeah.

Aaron van Wirdum You know, almost sort of save the day or I'm not necessarily endorsing that. Yeah, but let me put it this way. I find it almost inevitable. Like someone out there is going to Leeroy Jenkins this. Like it's got to happen. I don't know if it's going to succeed, but it's almost inevitable.

Sjors Provoost So here's a bad scenario. Let's say we ship the completely ready taproot code ready for mainnet in two months. Yes. Not going to happen, but let's say we do that. The code has this one year, you know, miner signaling thing, and then it expires. And now the most aggressive group comes out and we say, no, no, no, we're going to activate this like one month later. That's going to be the consensus or the loudest people. Yes,

Aaron van Wirdum that's going to be the Leeroy Jenkins.

Sjors Provoost Yeah, so two weeks later, you know, two weeks into that scheme, the miners actually start reviewing because like we just talked about, you know, people might only review code when it's ready. Now they find a critical bug. And most of the core developers would agree, okay, this is actually a bug. We should abort this soft fork miners. Please don't signal for it. But at the same time, you have this super loud group who has already canceled everybody who doesn't agree with them to activate this thing. So that's why I like the idea of having at least some decent amount of time and some community agreement on when are we going to flag date this thing. And it shouldn't be within a few months. You should give people a decent amount of time. But, you know, I can't decide what people are going to do.

Aaron van Wirdum Well, except that's kind of my point. But you might get

Sjors Provoost a, you know, either that might be successful and it just deploys early and we get lucky. Maybe it's a botched UASF sort of situation where they try, they make a really lot of noise, but the main players in the industry, because of this bug, for example, say, no, no, no, we're not doing this. Yes. And they just collide head on and nothing happens. where you get a bunch of orphan blocks, it's hard to predict. But that could be a mess, and that could be on CNN, and then it's like, oh, Bitcoin is broken on CNN. And Bitcoin was already broken two podcasts ago, remember? I don't know what the topic was. Oh,

Aaron van Wirdum no, that was security something. Oh,

Sjors Provoost it was unconfirmed transactions. Oh, yeah, that was the... But now imagine all these very mediogenic people with their machine guns in the forest. advocating a soft fork that all of the core developers are saying, let's not activate this because there's like a really, really bad bug in it.

Aaron van Wirdum Yes, but I do think the dynamics then would be very different. Like if there's an actual bug in the actual soft fork itself compared to... an actual or just an objection to the activation situation itself like these are two this was

Sjors Provoost a very extreme example but less extreme would be I think miners should have some time to review this code after it's shipped and some people might say no they should have reviewed it earlier because we don't want to set the incentive yeah so I think it could be messy so that's why waiting longer I think is generally better

Aaron van Wirdum so here's another idea it's Another idea is BIP-8 plus BIP-91. Okay. So this basically means you're going to deploy BIP-8, I think, with a long signaling period, like could even be three years or whatever, like something that's similar to Matt's proposal. After these three years, three and a half, whatever it is, the activation is triggered. So there's a long lead up. In the meantime, though, you're gonna see what happens. So for example, if after a year, it's still not activated, then developers can sort of try to find out why it hasn't activated. Again, sort of similar to Matt's idea. Developers take their time, they figure out, okay, there's actually no good reason that it's not being activated. At that point, they can deploy a new client that has sort of BIP 91 in it. which forces miners to signal support for it before the three and a half years are over.

Sjors Provoost You mean a lower threshold?

Aaron van Wirdum Yes, a lower threshold.

Sjors Provoost Okay, so you basically ship an update which has a lower threshold in it.

Aaron van Wirdum Yes, which in turn triggers the higher threshold.

Sjors Provoost So I like the idea of lowering the threshold over time. What I am worried about, and maybe that was discussed, is what if there's a bug? Because now, if this thing has a three-year window, that means there's three years in which this thing could activate, even though everybody agrees it shouldn't activate. Right. And that's kind of scary.

Aaron van Wirdum Right, so then the answer is deploy a new client that includes a soft fork that undoes the taproot soft fork in that case.

Sjors Provoost Well, if you undo a soft fork, it's a hard fork.

Aaron van Wirdum Not if it's not activated yet.

Sjors Provoost Yeah, but you don't know that.

Aaron van Wirdum What do you mean?

Sjors Provoost So the problem is people who are running the first version, they're just waiting for that 95%. They're waiting for three years until this thing activates. But then if there's a bug fix, then you need to have a new signal flag to indicate the new version of Taproot that you're going to activate. And you have to make sure the old version never activates.

Aaron van Wirdum Yeah, but you can just soft fork that. Soft fork is a tightening of the rules. So now you say any Taproot, anything is just not allowed. You're not going to include it in blocks.

Sjors Provoost Yeah, you could completely ban version 1, basically. But that's pretty horrific. It would be nicer if you didn't have to do that.

Aaron van Wirdum It would be kind of ugly, yes. Plus, it would be important that people upgrade.

Sjors Provoost So a one-year signaling thing is nice... Because that means that you can say, okay, if this thing doesn't activate in a year because there's a bug, we wait a year and we try again. And then we know for sure we're not going to accidentally activate the old version after that year. Yes. And yeah, it's kind of annoying to have to wait for a year, but then if there really is a bug... In a thing that was ready to be deployed, that really warrants a year of thinking really, really well about how the hell that could happen.

Aaron van Wirdum Yeah. Okay, so then there was another idea. I added this.

Sjors Provoost The idea of saying that signaling thresholds could go down, that makes sense to me. So you could say, well, when the year starts, it's 95%. But you know, after six months, it should just be 80%. And after 11 months, it should be a little bit less. And then if it still doesn't happen, we give up and we decide again for next year what we're going to do.

Aaron van Wirdum Yes. Alright, so then there was another idea, which is, I guess, is it the opposite of the previous one? Maybe not. You take BIP 8 with a long period, but without forced signaling at the end. Then you still keep an eye on what's happening. If after a while you find that there is no problem with it, but miners aren't signaling for it because they're just apathic or they have another bad reason, then you can deploy another client with BIP-8, this time with force signaling, that starts force signaling before the end of the current signaling period.

Sjors Provoost Okay.

Aaron van Wirdum Or at least not later than that. Like if it starts before that, then you have two groups of nodes online on the network. The BIP-8 nodes you deployed first that don't have forced signaling on the end. And now the new group of BIP-8 nodes that do have forced signaling. So if they do the forced signaling stuff, then the older BIP-8 nodes will also accept that as an upgrade. That

Sjors Provoost sounds like a regular idea of BIP-8, right? So BIP-8 has the option to allow forced signaling so initially you do not ship that option and then later on you do ship the option and yeah the old nodes won't be confused because they see the signaling

Aaron van Wirdum yep so

Sjors Provoost Yeah. Pretty much. So

Aaron van Wirdum what's your preference here? It sounds like you're kind of conservative.

Sjors Provoost Well, like I said, I don't like the idea of hard coding a flag date initially. So I can see the benefit of you ship something, you wait, say it has a year of a window, you wait for six months, then you still don't see any signaling, but you also don't see the miners that reviewed your code and found problems. Then maybe you say, okay, let's do a flag date. It's not super patient, and then you have that flag date within six months. But I'm not sure. In the short run, it's nice to have all this stuff fast. In the long run, it's kind of scary if something can happen fast, because it gives you less time to stop it if it's bad. But again, just being slow for the sake of being slow doesn't make any sense either. So I can see why these IRC threads are going to be really long. But what I'm hoping will happen is we just do, you know... BIP-8 without a flag date with a year of a window and we get lucky and miners just activate the thing within a month and it's done.

Aaron van Wirdum That would be nice, right? If miners just cooperate and maybe we're all making too big of a problem out of this. Well, that's one of the... That's, for example, like...

Sjors Provoost Well, I don't want to say it would be nice if miners just cooperated because, you know, Ethereum has that too and miners are very cooperative. I would... Yeah, but everyone's... It would be nice if miners were very excited about this proposal for good reasons. and did so quickly. I'm not saying that's technically not cooperation, it's just agreeing, right? Not obeying. I guess it is cooperating, but I mean it in an agreement sense, not in an obeying sense.

Aaron van Wirdum Sure. Well, I think Greg Maxwell's position, for example, there are a few like him, I don't think he really cares strongly. He feels like whatever is likely to work, like just... just go for it don't over think this because it's

Sjors Provoost probably good if you know if it

Aaron van Wirdum doesn't work out we'll deal with it then i think that's sort of um his position for example um and and like all of the options i've named so far i think he's sort of okay with as long as like something needs to be picked because the longer it's going to take the more the harder it's going to get probably and the more controversial the whole topic might become and like just yeah it's quite possible try something

Sjors Provoost you get a whole holy war over the exact details of how you activate a soft fork and that might be bad

Aaron van Wirdum yeah do you think it's i mean that's one of the reasons it could be like a holy war is some people think that it's a very important precedent to set like it the way you're enforcing a soft fork the way you're activating a soft fork that really matters going forward for the next soft fork and it really sort of defines bitcoin almost in a way

Sjors Provoost Well, I don't know about the latter because things change. So even if we do things in an amazing way, five years from now, there might be a whole new generation of people that just do not care about the ways of five years ago. All these old people.

Aaron van Wirdum Especially in Bitcoin, five years is an eternity.

Sjors Provoost I mean, I think I mentioned today my main concerns. Don't set something in stone that you have a serious chance of regretting. So keep in mind that people don't review code before it's actually shipped. And so that's why I kind of like the idea of having, say, a one-year activation window, maybe with a minimum of three months. There was another proposal for that. And then give miners and others some time to actually review this thing because they haven't done it. And then if they find a problem, you can still abort. And then if you don't see this objection, then you can choose to put in a flag day. And then you can debate whether you want the flag day to be very quickly. at the end of the year, or whether you say, let's give it another year. It just depends. But I don't have a strong opinion there. But I'm not the most patient person, so I should ask a more patient person.

Aaron van Wirdum Well, you sound pretty patient to me. I think I'm pretty patient.

Sjors Provoost Not by Greg Maxwell's standards, I think. Right.

Aaron van Wirdum I guess I'm pretty patient when it comes to software, because I'm not really in a rush. Bitcoin works for me, the way it's working. At the same time, it's like users are... you know it's not up to me like people are going to get impatient and i think that's going to be a an interesting dynamic to see play out like too conservative is a risk in itself yes because

Sjors Provoost if if this soft fork is hanging in the air for years it will get political yes and then it might not go through because of politics that would not have happened if it went through a bit quicker

Aaron van Wirdum Yes, or it just increases the chance that someone's going to Leeroy Jenkins in a bad way. If developers want to be too conservative, then you're going to see that kind of movement. That might not always be the best way to do it either. I think this is a fascinating topic.

Sjors Provoost Should we end on the cliffhanger?

Aaron van Wirdum Do you have a cliffhanger?

Sjors Provoost What are sporks?

Aaron van Wirdum What's that?

Sjors Provoost What are sporks?

Aaron van Wirdum Oh, Sporks? You want to get into that one as well?

Sjors Provoost No, no, I want to leave it as a cliffhanger.

Aaron van Wirdum Okay. Oh, yeah, that's even better. So we discuss it in another episode?

Sjors Provoost In another episode. Maybe never.

Aaron van Wirdum I like that. Yeah, maybe never. Yeah, maybe we're doing a lost cliffhanger. You'll just never get the answer. So... But there is another idea for soft fork, which is called Sporks.

Sjors Provoost Sporks.

Aaron van Wirdum All right, Sjors, that was it for this episode, I think.

Sjors Provoost Thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There we go.