Episode 31: Taproot Activation with Speedy Trial

Aaron van Wirdum Before the show, a quick word from our sponsor. Live from Utrecht, this is the Van Wirdum Sjorsnado.

Sjors Provoost Hello.

Aaron van Wirdum Sjors, what is your pun of the week?

Sjors Provoost Well, I actually asked you for a pun and then you said, cut, re-edit, we're going to do it again. So I don't have a pun this week.

Aaron van Wirdum Puns are your thing.

Sjors Provoost Yeah, we tried this LOT thing last time.

Aaron van Wirdum Okay, Sjors, we're going to talk a lot this week.

Sjors Provoost We're still going to get blocked for this. Okay.

Aaron van Wirdum We talked a lot two weeks ago. Okay, so a LOT was the parameter we discussed two weeks ago. A LOT is true, a LOT is false, about Taproot activation. We're two weeks further in, and now it seems like the community is somewhat reaching consensus on an activation solution called Speedy Trial. And that's what we're going to discuss today.

Sjors Provoost That's right.

Aaron van Wirdum Should we begin with Speedy Trial? What is it? What is Speedy Trial? Sure.

Sjors Provoost Yeah, I think that's probably a good idea to do. So with the proposals that we talked about last time for activating Taproot, basically, Bitcoin Core released some software maybe in April or something. And then I think the miners will start signaling using that software. And I think it's in August or something. And then they can signal for a year. And at the end of the year, the whole thing ends.

Aaron van Wirdum That was a LOT true or false. And then the debate was on whether or not it should end with forced signaling or not. That's the true-false thing.

Sjors Provoost Yeah, but the thing to keep in mind here is that the first signaling would be a while before that starts happening. So until that time, we really don't know, essentially. So what the Speedy Trial proposes is to say, well, rather than discussing whether or not it's going to be signaling and having lots of arguments about it, let's just try that really quickly. So instead, there would be a release... Maybe also around April, whatever. Of course, there's nobody in charge of actual timelines. And in that case, the signaling would start much earlier. I'm not entirely sure when, maybe in May or pretty early. And the signaling would only be for three months. And at the end of three months, it would just give up. And the nice thing…

Aaron van Wirdum It would end on LOT false, basically.

Sjors Provoost Yeah, it's the equivalent of LOT false or just how it used to be with soft forks. It signals, but only for a couple months. And then…

Aaron van Wirdum If it isn't activated within these months by hash power, which is going to be probably 90% hash power, so it's going to require 90% hash power to activate Taproot. If that doesn't happen, then the proposal expires. And when it expires, we can continue our discussion on how to activate Taproot. Or if it activates… Then what happens?

Sjors Provoost Yeah, so the thing is, because you still want to give miners enough time to really upgrade their software, the actual Taproot rules won't take effect until September or August.

Aaron van Wirdum Miners and actual users, Bitcoin users.

Sjors Provoost Yeah, you want to give everybody

Aaron van Wirdum Yes.

Sjors Provoost plenty of time to upgrade. So the idea is we would start the signaling actually very quickly, also because miners can basically signal even without installing the software. But then once the signal threshold has been reached, then the software is sort of set in stone. It's going to happen, at least if people run the full nodes. And then there's still some time for people to upgrade and for miners to really upgrade and run that new software rather than just signal for it.

Aaron van Wirdum Yeah, so to recap…

Sjors Provoost They could… they could run that software but they might not. And that's why it's sort of okay to release a bit early.

Aaron van Wirdum But they should really be running the software if they're signaling, right?

Sjors Provoost Well, they… they should… No, I think…

Aaron van Wirdum Let's get into that later.

Sjors Provoost We can get into that later.

Aaron van Wirdum Okay, so for now, to recap really briefly, Speedy Trial means release the software fairly fast and quickly after it is released, start the signaling period for three months, which is then relatively short for a signaling period. See if 90% of miners agree. If they do, Taproot activates six months after the initial release of the software, I think. If 90% of miners don't activate within three months, the proposal expires and we can continue the discussion on how to activate SegWit… Taproot.

Sjors Provoost Then we're just basically back to where we were a few weeks ago, but with more data.

Aaron van Wirdum Right, exactly. So I want to briefly touch on how we got here because we discussed the whole true-false LOT thing and there appeared to be a gridlock. And I think because some people definitely didn't want LOT true, some people definitely didn't want LOT false. And then a third proposal entered the mix, which was it was always sort of it wasn't brand new, but it wasn't a major part of the discussion which was a simple flag day. So a simple flag day would have meant that the Bitcoin Core code would have included a date in the future or block block height in the future at which point the Taproot upgrades would activate regardless of hash power up until that point.

Sjors Provoost Yeah, which I find an even worse idea, but I don't know, you know, when when there's a lot of debate people start just proposing stuff.

Aaron van Wirdum Well, I… I think the… the reason is that the reason that we reached this sort of gridlock situation where people feel very strongly about different ideas has a lot to do with what happened during the SegWit upgrade and we've discussed this before but people have very different ideas of what actually happened. Some people feel very strongly that users show their muscles, users claimed their sovereignty, users claims back the protocol, and they basically forced miners to activate the SegWit… the SegWit upgrade and it was a huge victory for Bitcoin users. And then other people feel very strongly that Bitcoin came near a complete disaster with a fractured network and people losing money, and a big mess. And so the first group of people really kind of likes doing a UASF again, or starting with false and switching to true or maybe just starting with true or something like that. And people think it was a big mess they kind of prefer to just use a flag day this time, you know nice and safe, in a way, just use a flag day, none of this miner signaling, so miners also can't be forced to signal and all of that. So these different views on what actually happened a couple years ago now means people can't really agree on a new activation proposal. So after a lot of discussion, all factions were sort of willing to settle on Speedy Trial even though no one really likes it, for a couple of reasons, which we'll also get into but you know, the UASF people they kind of they're kind of okay with Speedy Trial because it doesn't really get in the way of the UASF. If the Speedy Trial fails they'll still just do the UASF next year. The flag day people are sort of okay, because the three months doesn't allow for a big enough window to do the UASF probably. And the UASF people have said that, you know, that's too fast indeed. And let's do this trial anyways.

Sjors Provoost That's also still the LOT is false… Let's just do soft forks the way we've done them before where they might just expire… A group of people that were quietly continuing to work on the actual code that could do that. So it's, you know, just from mailing lists and Twitter, it's even hard to gauge what's really going on. This is a very short timescale.

Aaron van Wirdum Yeah, the LOT is false people, you know, this is basically LOT is false just on a shorter timescale. So everyone's sort of willing to settle on this, even though no one really likes it.

Sjors Provoost Well, from the point of view that I'm seeing, I'm actually looking at the code that's being written. And what I have noticed is that once a Speedy Trial proposal came out, more people came out of the woodworks and started writing code that could actually get this done. Whereas before, it was mostly Luke, I think, writing that one pull request.

Aaron van Wirdum That's BIP 8, or?

Sjors Provoost Yeah, BIP-8. So now, and I guess we can get into the technical details, but what I'm trying to say is that one thing that shows that the Speedy Trial seems like a good idea is that there's more developers from different angles cooperating on it and getting things done a little bit more quickly. When you have some disagreement, then people start procrastinating, not reviewing things or not writing things. So, but that's… that's kind of a vague indicator of this seems to be okay because people are working on it quickly and it's making progress so that's good.

Aaron van Wirdum Right. Yeah, so some… some technical details I think you want to get into right?

Sjors Provoost Yeah, so… so the idea of this Speedy Trial can be implemented in two different ways. You can use the existing BIP 9 system that we already have.

Aaron van Wirdum Yes.

Sjors Provoost And the argument for that would be, well, that's far less code because it already works and it's just for three months, so why not just use the old BIP 9 code?

Aaron van Wirdum BIP 9 used date. A date into the future, right?

Sjors Provoost Yeah, so you can tell when it… when the… when the signaling could start, when the signaling times out. And there's some annoying edge cases there where if it ends right around the deadline, but then there's a reorg and it ends right before the deadline, and then people's money might get lost if they try to get into the first Taproot block. And it's just difficult to explain.

Aaron van Wirdum Because the thing is, the signaling happens per difficulty period of 2016 blocks. And then at least up till now, 95% of blocks needed to signal support. But these two block periods… you know, they don't neatly fit into exact dates or anything. They just happen. But while the signaling period does start and end on specific dates, so then that's why you can get weird edge cases.

Sjors Provoost Yeah, so let's do a little example there because it's kind of fun to illustrate. Let's say the deadline of this soft fork is on September 1st. Pick a date for signaling. On September 1st at midnight UTC. Now, a miner mines block number, what was it? 2016. You know, some multiple of 2016, because that's when the voting ends. And they mine this block one second before midnight UTC. And they signal yes. And so everybody who sees that block says, okay, we have 95% or whatever it is right before midnight. Taproot is active. And so they have this automatic script that says, I'm going to now put all my savings in a Taproot address because I want to be in the first block and I'm feeling reckless and I love being reckless. And then there is a, you know, another miner who mines two seconds later because they didn't see that, you know, recent block because, you know, that can be stale blocks. And they, their block arrives at one second past midnight. And it votes positive too, but it's too late. And so the software does not activate because the signaling was not done before midnight at the deadline. That's the subtlety you get with BIP 9. And, you know, usually it's not a problem, but it's difficult to explain these edge cases to people.

Aaron van Wirdum And it gets a bigger problem, I'd say, maybe with shorter signaling periods as well.

Sjors Provoost Yeah. Yeah, of course. If there's a longer signaling period, it's less likely that the signal is going to arrive just at the edge of a period.

Aaron van Wirdum Yeah. About the threshold, is that still going to be... Because I thought it was going to be 90% this time, or is it...

Sjors Provoost Well, so that's a separate thing. So first, let's talk about, regardless of the threshold, there's two mechanisms.

Aaron van Wirdum Okay, sure.

Sjors Provoost So one is based on time. That's BIP 9. You know, easy because we already have the code for it. Downside is all these weird things that you need to explain to people. And, you know, nowadays soft forks in Bitcoin are so important that maybe CNN wants to write about it. And it's nice if you can actually explain it without sounding like a complete nerd. But the alternative is to say, okay, let's just use this new BIP 8 that was proposed anyway, and that uses height. And we ignore all the LOT is true stuff, but the height stuff is very useful. And then it's much simpler. We're just saying, as of this block height, that's when the signaling ends. And that height is always at the edge of these retargeting periods. And so that's just easier to reason about. It's just saying, okay, if the signaling is achieved by a block, I don't know, [unclear] 700,321, then it happens or it doesn't happen. And even if there's a reorg, that could still be a problem, by the way, because there could be a reorg at the same height. But then the difference would be that it would activate because we just made the precisely 95%. And then there's a reorg and that miner votes no. And then it doesn't activate.

Aaron van Wirdum Right.

Sjors Provoost So you still…

Aaron van Wirdum But that's that was…

Sjors Provoost Yeah, but I was still…

Aaron van Wirdum That's also true with BIP 9. So it's just you removed one edge case. You have one edge case less, which is better.

Sjors Provoost In BIP 9, you could have the same same scenario. Exactly one vote. If it's… if it's just at the edge one miner votes yes, one miner votes no. But the much bigger problem with BIP 9 is that if the time on the block is one second after midnight or before. This matters, even if they're way over the threshold. So they might have 99.999%, but that last block comes in too late. And so the entire period is disqualified. So then you might be like with an election, you're looking at all the votes and you're saying, okay, it's got 97% support. It's going to happen. And then that last block is just too late and it doesn't happen. So again, difficult to explain, but we don't have this problem with height-based activation.

Aaron van Wirdum Yeah, so I guess the biggest disadvantage of using BIP 8 is that the code isn't, it's a bigger change as far as code comes.

Sjors Provoost Yeah, but to be honest, I have actually looked at that code yesterday and wrote some tests for it. And Andrew Chow and Luke Dashjr have already implemented a lot of it. It's already been reviewed by people. It is actually not too bad. It looks like 50 lines of code. However, you know, if there's a bug in it, it's really, really bad. So just because it's only a few lines of code doesn't mean it might be safer to use something that already is out there. But I'm not terribly worried about it.

Aaron van Wirdum Right. And then there's the hash power threshold.

Sjors Provoost Yes.

Aaron van Wirdum Is it 90 or 95?

Sjors Provoost I think in the current proposal, so what's being implemented now in Bitcoin Core is the general mechanism. So it is saying for any software that you call Speedy Trial, you could, for example, use 90%. But for Taproot, the code that is for Taproot in Bitcoin Core just says it never activates. That's sort of the way you indicate the software is in the code, but it's not going to happen yet. And it stays never activates. And these numbers are arbitrary. So the code will support 70% or 95%, as long as it's not some imaginary number or more than 100%.

Aaron van Wirdum It's worth pointing out that in the end, it's always 51% effectively because 51% of miners can always decide to orphan non-signaling blocks.

Sjors Provoost Yeah, and create a mess. But they could, yeah.

Aaron van Wirdum Yeah, I'm just, you know, it's something to be aware of that miners can always do that if they would choose to.

Sjors Provoost Yeah, but the general principle that's being built now is that at least we could do a slightly lower threshold. And that might be still some discussion of whether or not that's safe or not. And then the final detail.

Aaron van Wirdum But hang on, it's not settled yet, 90 or 95, as far as you know?

Sjors Provoost I don't think so.

Aaron van Wirdum Okay.

Sjors Provoost But, you know, you can have some arguments in favor for it, because, but we'll get into that with the risk section. And the other thing, the final thing that's…

Aaron van Wirdum Well, we can mention real briefly that the benefit of having a higher threshold is that a lower risk of orphan blocks after activation.

Sjors Provoost Yes.

Aaron van Wirdum That's mainly the reason.

Sjors Provoost But because we are doing a delayed activation, so there's a long time between signaling and activation, whereas normally you signal and it immediately activates when the signaling, or at least within just two weeks, it activates.

Aaron van Wirdum Yeah.

Sjors Provoost But right now… it can take much, much longer. So that means you have a longer time to upgrade, so there's a little less risk of orphaning, even if you have a lower signaling threshold.

Aaron van Wirdum True. Okay, and I think that was the first point you wanted to get at anyways, right? The delayed activation.

Sjors Provoost Yeah, so what happens normally is you tally the votes in the last difficulty period, if it's more than whatever the threshold is, then the state of the software goes from started, as in we know about it, we're counting, to locked in. And the state locked in will normally last for two weeks or one retargeting period, and then the rules actually take effect. And what happens with Speedy Trial, the delayed activation part, is that this locked-in state will go on for much longer. It might go on for months. So it's locked in for months, and then the rules actually take effect. And this changes only two lines of code, so that's quite nice.

Aaron van Wirdum Right. Okay. Should we get to some of the downsides of this proposal?

Sjors Provoost Yeah, some of the risks. I think the first one we kind of briefly mentioned, because this thing is deployed quite quickly, and because it's very clear that the activation of the rules is delayed, there is an incentive for miners to just signal rather than actually install the code. And then they could procrastinate on actually installing the software. And that's fine unless they procrastinate so long that they forget to actually enforce the rules.

Aaron van Wirdum Yeah, which sounds quite bad to me, Sjors.

Sjors Provoost Yeah, but yeah, that is bad. I agree. Of course, it's always possible for miners to just signal and not actually enforce the rules, right? This risk exists with any software deployment.

Aaron van Wirdum Yes, miners can always just signal, fake signal, and that has happened in the past. We've seen fake signaling. It was the BIP66 soft fork where we learned later that miners were fake signaling, in fact, because we saw big reorgs on the network. So that is definitely something we would want to avoid.

Sjors Provoost Yeah, and I think we briefly explained this earlier, but we [unclear] explain it again. Bitcoin Core, if you use that to create your blocks as a miner, there are some safety mechanisms in place to make sure that you do not create a block that is invalid. However, if another miner creates a block that is invalid, you will mine on top of it. And then you have a problem because the full nodes that are enforcing Taproot will reject your block. And presumably most of the ecosystem, if this signaling thing works, will upgrade. But then you get into this whole very scary situation where you really hope that that's true. And that not a massive part of the economy is too lazy to upgrade and you get a complete mess.

Aaron van Wirdum Yes, correct.

Sjors Provoost I think that the term we used… we talked about is the idea of a troll, basically, a troll. So you could have a troll user. Let's say I'm a mean user and I'm going to create a transaction that looks like a Taproot transaction, but it is actually invalid according to Taproot rules. Now, the way that works, like the mechanism in Bitcoin to do soft forks, is that you have this version number in your SegWit transaction. And so you say this is a SegWit version 1 transaction. And nodes know that you're allowed to, when you see a SegWit version you don't know about, a higher version than you know about…

Aaron van Wirdum Or Taproot version.

Sjors Provoost Well, a SegWit version.

Aaron van Wirdum Oh, okay. Sure. Yeah.

Sjors Provoost So current version of SegWit is version zero because we're nerds. And if you see a SegWit version transaction with one or higher, you assume that anybody can spend that money. That means that if somebody is spending from that address, you don't care. You don't consider the block invalid as an old node. But a node that is aware of the version will check the rules. So what you could do as a troll is you could create a broken Schnorr signature, for example. You just take your Schnorr signature and you swap one byte. Then if that is seen by an old node, it says, oh, this is SegWit version 1. I don't know what that is. It's fine. Anybody can spend this, so I'm not going to check the signature. But the Taproot nodes will say, hey, wait a minute, that's an invalid signature. Therefore, that's an invalid block. And we have a problem. Now, there's a protection mechanism there that normal miners will not mine SegWit transactions that they don't know about. So they will not mine SegWit version one if they're not upgraded.

Aaron van Wirdum Isn't it also the case that regular nodes will just not forward the transaction to other nodes?

Sjors Provoost That's another safety mechanism.

Aaron van Wirdum Right, so there are two safety mechanisms.

Sjors Provoost They're basically saying, hey, dear other node, I don't think you want to just give your money away. Or alternatively, you're trying to do something super sophisticated that I don't understand. There's something called standardness. If you're doing something that is not standard, I'm not going to relay it. But that is not a consensus rule. And that's important. It means that you can compile your node to relay those things. And you can compile your miner to mine these things. But it's like, you know, it's a footgun if you don't know what you're doing. But it's not against consensus. However, when a transaction is in a block… then you are dealing with consensus rules. And that, again, means that old nodes will look at it and say, I don't care. I'm not going to check the signature because that's a higher version than I know about. But the nodes that are upgraded will say, hey, wait a minute. This block contains a transaction that's invalid. This block is invalid. And so a troll user doesn't really stand a chance to do much damage.

Aaron van Wirdum No, because the transaction won't make it over the peer-to-peer network. And even if it does, it would… only make it to miners that will still reject it. So troll user probably can't do much harm.

Sjors Provoost So our troll example of a user that swaps one byte in a Schnorr signature, he tries to send this transaction, he sends it to a node that is upgraded. That node will say, that's invalid, go away, I'm going to ban you now. Or maybe not ban, but definitely gets angry. But if he sends it to a node that is not upgraded, that node will say, I don't know about this whole new SegWit version of yours. Go away. Don't send me this modern stuff. I'm like really old school. Send me old stuff. And so the transaction doesn't go anywhere, but maybe somehow it does end up with a miner. Then the miner says, well, I'm not going to mine this thing that I don't know about. That's dangerous because I might lose all my money. However, you may have a troll miner. Now that would be very, very expensive trolling. But, you know, we have billionaires in this ecosystem. So if you mine a block that is invalid, it's going to cost you a few hundred thousand euros, I think, at the current prices, maybe even more.

Aaron van Wirdum Yeah, 300,000 something.

Sjors Provoost Yeah. But if you have 300,000 euros to burn, you could make a block like that and just challenge the ecosystem and say, hey, here's a block. Let me see if you actually verify it. Then if you're a miner… So then if that block goes to nodes that are upgraded, those will reject it. If that block goes to nodes that are not upgraded... It's fine. It's accepted. But then if somebody mines on top of it, if that miner has not upgraded, they will not check it. They will build on top of it. And then eventually the ecosystem will probably reject that entire chain and it becomes a mess. So then you really, really, really want a very large majority of miners to really check the blocks, not just mine blindly in general. And there are already problems with miners just blindly mining on top of other miners, even for a few seconds. For like economic reasons.

Aaron van Wirdum Yeah, so that was a long tangent on the problems with false signaling.

Sjors Provoost Yes.

Aaron van Wirdum Because all of this would only happen if miners are false signaling.

Sjors Provoost Yeah, and false signaling, to be clear, it's not some malicious act. It's just a lazy convenient thing, you say, yeah yeah yeah don't worry I'll do my homework, you know, I'll I'll send you that memo in time. Don't worry.

Aaron van Wirdum Yeah, I haven't upgraded yet, but I will upgrade, and you [unclear] know the difference for now. So, yeah, yeah, that's yeah that's that's sort of the risk of uh, false signaling.

Sjors Provoost Yeah, it could be deliberate too, but that would have to be a pretty large conspiracy then.

Aaron van Wirdum Yeah, I guess one… one other sort of concern, one risk that has been mentioned, is that using LOT false in general, just could help users launch a UASF because they could run a UASF client with LOT true and then incentivize miners to signal like we just mentioned, and that would not only mean they would fork off to their own software themselves but basically activate the software for the entire economy. That's not a problem in itself, but some people, I think, consider it a problem if users are incentivized to try a UASF. Do you understand that problem?

Sjors Provoost I guess if… if we go for this BIP 8 approach right, if we don't… if we switch to using block height rather than timestamps it is…

Aaron van Wirdum Or flag high… or flag day.

Sjors Provoost Well, the Speedy Trial doesn't use a flag day.

Aaron van Wirdum I know. I'm saying that if you do a flag day you cannot do a UASF that triggers something else.

Sjors Provoost Well, yeah. Well, you could maybe. Why not?

Aaron van Wirdum What would you trigger?

Sjors Provoost Well, you can basically run... There is a flag day out there, but you deploy software that requires signaling. That's what…

Aaron van Wirdum Yes, that's what UASF people would be running.

Sjors Provoost Yeah, they can run that anyway. Even if there's a flag day, they can decide to run a software that requires signaling, even though nobody will signal probably, but they could.

Aaron van Wirdum Absolutely, but they cannot co-opt, to call it that… LOT false nodes if there's only a flag day out there.

Sjors Provoost Yeah that's true. Yeah, so they they would require the signaling, but the LOT false nodes that are out there would be like… not even LOT false… like the flag day nodes that are out there would be like okay I don't know why you're not accepting these blocks, but there's no signal. There's nothing to activate. There's just my flag day, and I'm gonna wait for my flag day.

Aaron van Wirdum Yes, and I don't want to get into the weeds too much, but if there are no LOT false nodes to co-opt, then miners could just false signal. So now the UASF nodes are activating Taproot but the rest of the network still hasn't got Taproot activated. So now, if the UASF nodes ever send coins to a Taproot address, they're gonna lose their coins at least on the rest of the network.

Sjors Provoost And they wouldn't get this reorg advantage that they think they have. This sounds even more complicated than the stuff we talked about two weeks ago.

Aaron van Wirdum Yes, that's why I mentioned I'm getting a little bit into the weeds now, but do you get the problem?

Sjors Provoost But is this an argument for or against a flag day?

Aaron van Wirdum This is basically… well, depends on your perspective, Sjors.

Sjors Provoost That of somebody who does not want Bitcoin to implode in a huge fire. And would like to see Taproot activated.

Aaron van Wirdum If you don't like UASFs, if you don't want people to do UASFs, then you might also not want LOT is false nodes out there.

Sjors Provoost Yeah, okay. So you're saying if you really want to not see UASF exist at all. Yeah, I'm not terribly worried about these things existing. What I especially talked about two weeks ago is I'm not going to contribute to them probably.

Aaron van Wirdum Right. You know, okay, so I just… I just wanted to mention that that is one argument against LOT is false that I've seen out there. Not an argument I agree with myself either, but I've… I've seen the argument.

Sjors Provoost And I think apparently, what you're saying is it's an argument for not using signaling but using a flag day.

Aaron van Wirdum Yes. So, you know, even Speedy Trial uses signaling, and while it's shorter… you know, it might still be long enough to throw a UASF against it.

Sjors Provoost Yeah, and it is compatible with that, right? Because it uses signaling, it is perfectly compatible with somebody deploying a LOT is true system and making a lot of noise about it. Yeah, but I guess in this case, even the strongest LOT is true proponents, one of them at least argued that it would be completely reckless to do that. So it sounds like…

Aaron van Wirdum Yeah, there are no UASF proponents out there right now who think this is a good idea. As far as I know at least.

Sjors Provoost Yeah, so… so far there are not, but we talked about in September, I think we talked about this cowboy theory, so I'm sure there's somebody out there that will try a UASF even on the Speedy Trial.

Aaron van Wirdum You can't exclude the possibility at least. Well, so then there there's another argument against Speedy Trial which is… and I find this argument quite compelling actually, which is that we came out of 2017 with a lot of uncertainty. And I just mentioned the uncertainty at the beginning of this episode. I mentioned some of it at least, that some people thought the UASF was a great success. Some people thought it was a reckless thing that happened. Yep. I think both are partly true or there's truth to all of it. Now we have a soft fork, Taproot, that everyone seems to love. Users seem to like it, developers seem to like it, miners seem to like it, everyone likes it. The only thing we need to do is upgrade it. Now might be a very good opportunity to sort of… clean up the mess from 2017 in a way, agree on what soft forks are exactly, what is the best way to deploy a soft fork and then use that, because that way it sort of becomes a template that we can use in more contentious times in the future, when maybe there is another civil war going on or there's more flood being thrown at Bitcoin, or you know, we seem to be in calm waters right now. Maybe this is a really good time to do it right, which will help us moving into the future. While Speedy Trial, you know, no one thinks this is actually the right way. It's sort of a fine, we need something, so let's do it. But, you know, we might arguably… it's arguably kicking the can of the really big discussion we need to have down the road.

Sjors Provoost Yeah. Maybe. So one scenario I could see is where the Speedy Trial goes through, activates successfully, and the type of deployment goes through and everything is fine. Then I think that would remove that trauma. And then the next software would be done in the nice and old traditional LOT is false, BIP-8. We'll release something and then several months later, miners start signaling and it'll activate. And so maybe it's a way to get over the trauma.

Aaron van Wirdum Yeah, maybe you think this is a way to get over the post-traumatic stress disorder. Just let everyone see that miners can actually activate.

Sjors Provoost Yeah, it might be good to get rid of that tension because the downside of releasing regular, say, BIP-8, LOT is false mechanism is that it's going to be six months of hoping that miners are going to signal and then hopefully just two weeks and it's done. But that six months where everybody's anticipating it, people are just going to go even crazier than they are now, perhaps. So I guess it's a nice way to say, you know, let's get this trauma over with. But I think there are downsides. For one thing, what if in the next six months we find a bug in Taproot? Because we have six months to think about something that is… already activated.

Aaron van Wirdum We can soft fork it out.

Sjors Provoost If that is a bug that can be fixed in the soft fork, yes.

Aaron van Wirdum I think any Taproot, you can just burn that type of…

Sjors Provoost Yeah, I guess you could add a soft fork that says no version 1 addresses.

Aaron van Wirdum Yes, exactly. I think that should be possible, right?

Sjors Provoost Yeah. So I guess it is possible to nuke Taproot.

Aaron van Wirdum Yeah, this is a pretty minor concern for me.

Sjors Provoost Well, yeah, it is and it isn't, because old nodes that are released now, basically, that will know about this Speedy Trial… They'll think Taproot is active. They might create receive addresses and send coins. But then, yeah, their transactions won't confirm or they'll confirm and then get unconfirmed. But they might get swept. No, they won't get swept away because I guess the software will say you cannot spend this money. It's not anyone can spend this. You cannot spend this. So it is protected in that sense. So, yeah, I suppose there are software ways out of a mess, but that are not as nice as saying abort, abort, abort, don't signal. Right? If we use the normal BIP-8 mechanism, arguably, till miner starts signaling, you can just say, do not signal.

Aaron van Wirdum Sure. Any final thoughts, Sjors? What are your expectations? Are we going to… What's going to happen?

Sjors Provoost I don't know. I'm happy to see progress on the code. So at least we've got, you know, actual code. And then we'll decide what to do with it.

Aaron van Wirdum Yeah.

Sjors Provoost I would say, then… thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.