Episode 36: Taproot Activation Update: Speedy Trial And The LOT=True Client

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

Sjors Provoost Hello.

Aaron van Wirdum Hey, Sjors.

Sjors Provoost What's up?

Aaron van Wirdum Sjors, today we have a lot more to discuss.

Sjors Provoost Oh, we've already made this pun.

Aaron van Wirdum We've already made it twice, I think.

Sjors Provoost Yeah.

Aaron van Wirdum It doesn't matter. We are going to discuss the final implementation details of Speedy Trial today.

Sjors Provoost Yep.

Aaron van Wirdum We've already covered Speedy Trial in a previous episode. This time we're also going to contrast it to the LOT=true client, which is an alternative that's been released by a couple of community members. And we're going to discuss how they compare.

Sjors Provoost Yeah, that sounds like a good idea. And we also talked about Taproot activation options in general in a much earlier episode.

Aaron van Wirdum One of the first ones?

Sjors Provoost Yeah, where we also talked about this idea of this cowboy mentality where somebody would eventually release a LOT=true client, whatever you do.

Aaron van Wirdum Yeah, so that's where we are.

Sjors Provoost And we also, I think, predicted correctly that there would be a lot of bike shedding.

Aaron van Wirdum Yes, which is also something we'll get into. So first of all, as a very brief recap. we're talking about Taproot activation.

Sjors Provoost That's right.

Aaron van Wirdum So Taproot is a proposed protocol upgrade for compact and potentially privacy-preserving smart contracts on the Bitcoin protocol. Is that a good summary in your opinion?

Sjors Provoost Yeah, I think so.

Aaron van Wirdum And the discussion on how to upgrade has been going on for a while now. The challenge is that on a decentralized open network like Bitcoin without a central dictator to tell everyone what to run when, you're not going to get everyone to upgrade at the same time. But we do want to keep the network in consensus somehow or another.

Sjors Provoost Yeah, and there used to be... The other thing that can work when it's a distributed system is some sort of conventions that you're used to, you know, ways that you're used to doing things. But unfortunately, the convention we had kind of ran into problems with the SegWit deployment. So then the question is, okay, should we try something else or was it just a freak accident and should we just try the same thing again?

Aaron van Wirdum Yeah, I think the last... preface before we really start getting into Speedy Trial is I'd like to point out the general idea with a soft fork, which is a backwards compatible upgrade, which Taproot is, means that if a majority of hash power is enforcing the new rules, that means the network will stay in consensus.

Sjors Provoost Yeah.

Aaron van Wirdum So.

Sjors Provoost And also, I guess we can repeat that is that if you keep making transactions that are pre-Taproot then those transactions are still valid. So in that sense, you can, as a user, ignore soft forks. Unfortunately, if there's a problem, you cannot ignore that as a user, even if your transactions don't use that Taproot.

Aaron van Wirdum Yeah. Well, so the general idea, I think everyone agrees that it is very nice if a majority of hash power enforces the rules.

Sjors Provoost Yeah.

Aaron van Wirdum And there are coordination mechanisms to sort of measure how many miners are on board with an upgrade. And that's how you can coordinate a fairly safe soft fork.

Sjors Provoost Yeah.

Aaron van Wirdum That's something everyone agrees on. And then there are parts where people start to disagree is what happens if miners don't actually cooperate with this coordination. We're not gonna rehash all of that. There's previous episodes about that. What we are gonna explain is that in the end the Bitcoin Core development community settled on a solution called Speedy Trial. Yes so and we already mentioned that as well in the previous episode but we're now now it's finalized basically and we're gonna explain what the finalized parameters are for this.

Sjors Provoost Yeah and there was a slight change.

Aaron van Wirdum So um let’s… let’s hear it Sjors, what are the finalized parameters for Speedy Trial? How are we… yeah so how is Bitcoin Core going to upgrade to Taproot?

Sjors Provoost Yeah so for every um so starting on let's see I think it's this Sunday. April 24th, midnight.

Aaron van Wirdum Yeah, I think that's this Sunday.

Sjors Provoost Starting this Sunday, the first time the difficulty readjusts. So that happens every two weeks. So probably one week after next Sunday.

Aaron van Wirdum Maybe it's Saturday.

Sjors Provoost Yeah, the signaling starts. So in about two weeks, the signaling starts. No earlier than one week from now.

Aaron van Wirdum Wait, just to be clear. That's the earliest it can start.

Sjors Provoost The earliest it can start is April 24th.

Aaron van Wirdum Yes.

Sjors Provoost But because it only starts at a new difficulty adjustment period or a new retargeting period, it probably won't start until two weeks from now.

Aaron van Wirdum Yeah, so it will start at the first new difficulty period after... April 24th. Yes, which is estimated I think right now somewhere early May, May the 4th or something. May the 4th be with you.

Sjors Provoost Sure, that would be a cool date. So that's when the signaling starts. And the signaling happens in you could say voting rounds, and a voting round is is two weeks, or you know one difficulty… uh adjustment period one retargeting period. Yeah now if 90 of the miners… or if 90% of the blocks in that voting period signal on bit number, I guess it's number two.

Aaron van Wirdum One or two?

Sjors Provoost Yeah, bit number two. Then, if that happens, Taproot is locked in. And locked in means that it's going to happen. So, you know, imagine the little gif with Ron Paul, I think. It's happening.

Aaron van Wirdum But...

Sjors Provoost The actual Taproot rules won't take effect immediately. They will take effect at block number 706,632.

Aaron van Wirdum Yes, which is estimated to be mined when?

Sjors Provoost That would be November 12th this year.

Aaron van Wirdum Right. That's going to differ a bit, of course, based on how fast blocks are going to be mined over the coming months. But it's going to be November, almost certainly.

Sjors Provoost Yeah, which would be four years after the SegWit2x effort imploded.

Aaron van Wirdum Right nice nice timing in that sense.

Sjors Provoost Yeah every date is nice. Um okay so that's that's what the Speedy Trial does. So there's going to be every two weeks as a vote if 90 of the vote reaches, then that's the activation date. So it doesn't happen immediately and because it's a Speedy Trial uh it could also fail quickly. And that is in August. So if I think around August 11th, If the difficulty period after that or before that, I always forget, doesn't reach the goal, I think it's after, then...

Aaron van Wirdum The difficulty period must have ended by August 11th, right?

Sjors Provoost I think when August 11th is passed, it could still activate. But then the next difficulty period, it cannot. So I think the rule is at the end of a difficulty period, you start counting. And if the result is a failure, then if it's after August 11, you give up. But if it's not yet August 11, you enter the next round.

Aaron van Wirdum Okay, wait. So if the first block of a new difficulty period is mined on August 10, will that difficulty period still count?

Sjors Provoost Yeah, that's right. And I think that's one of the subtle changes made to BIP 9 to make BIP 9 easy to reason about.

Aaron van Wirdum I see.

Sjors Provoost Because I think it used to be the other way around where you would first check the date. But if it was past the date, you would give up. But if it was before the date, you would still count. And now I think it's the other way around. So it's a bit simpler.

Aaron van Wirdum I see. Okay, so there's going to be a signaling window of about three months.

Sjors Provoost That's right.

Aaron van Wirdum And then if in any difficulty period within that signaling window of three months, 90% of hash power is reached, Taproot will activate in November of this year.

Sjors Provoost Yes.

Aaron van Wirdum Right? I think that covers Speedy Trial.

Sjors Provoost That's right. And the threshold is 90%, as we said. Like normally with BIP 9, it's 95%, but it's been lowered to 90.

Aaron van Wirdum Yeah. What happens if the threshold is not met?

Sjors Provoost Nothing.

Aaron van Wirdum Great.

Sjors Provoost Which means anything could still happen, right? So people could deploy new versions of software, try another bit or try it, et cetera.

Aaron van Wirdum Yeah. I just wanted to clarify that.

Sjors Provoost It does not mean that Taproot is canceled.

Aaron van Wirdum Yeah. If the threshold isn't met, then this specific software client will just do nothing. But, you know, Bitcoin Core developers and the rest of the Bitcoin community can still figure out new ways to activate Taproot.

Sjors Provoost Yeah, exactly. It's kind of a win-win. Well, I don't know if it's win-win, but the idea is it's a low-cost experiment. If it wins, we get Taproot. If not, then we have some more information as to why we don't.

Aaron van Wirdum Yes. I also want to clarify, we don't know what that's going to look like yet. That will have to be figured out then, or we can start figuring it out now, but that hasn't been decided yet.

Sjors Provoost Exactly.

Aaron van Wirdum What redeployment will look like. Okay, so... This week, another client was also launched. There's a lot of debate on the name. I think we're just going to call it the LOT=true client.

Sjors Provoost That sounds good to me.

Aaron van Wirdum It derives from this sort of technical and philosophical difference about how soft forks should be activated in the first place. And this client uses, you guessed it, LOT=true. The specifics of this. So a LOT=true, just to sort of spoil that before we get into specifics, a LOT=true means that if the signaling window is over, by the end of the signaling window, nodes will start to reject any blocks that don't signal. They'll only accept blocks that signal.

Sjors Provoost Exactly.

Aaron van Wirdum That's sort of the main difference. But let's get into the specifics here about a LOT=true client.

Sjors Provoost Yeah. So in the beginning, it is the same. That is... In principle it's the same, there's a theoretical possibility that it's not if miners do something really crazy, but it starts at a certain block height.

Aaron van Wirdum Um yeah so we just mentioned that Bitcoin Core… and so this is Bitcoin Core 21.1 uh starts its signaling window on the first difficulty period after April 24th, and this uh LOT=true client will also in practice, start its signaling window on the first difficulty period after April 24th, except that April 24th isn't specified specifically. They just pick the specific block height that is expected to be the first one after April 24th.

Sjors Provoost Exactly. So they pick 681,408.

Aaron van Wirdum Yeah. So it's specified as a block height instead of sort of indirectly through using a date.

Sjors Provoost Yeah, but in all likelihood, that's going to be the exact same moment. So both the Speedy Trial and the BIP 8, sorry, the LOT=true client, will start signaling the voting periods at the same time.

Aaron van Wirdum Yes.

Sjors Provoost And the voting periods themselves, they vote on the same bit. They both vote on bit two. They both have a threshold of 90%. And... Also, if the vote is true, then it also has a delayed activation. So the delayed activation is a block height in both scenarios, in both the Speedy Trial and in the LOT=true variant.

Aaron van Wirdum Yeah, so it's both that 12th November or November activation anyway. So if... Taproot, if miners signal readiness for Taproot within the Speedy Trial period, both of these clients will just activate Taproot in November on the exact same date.

Sjors Provoost Yeah.

Aaron van Wirdum Exact same block.

Sjors Provoost Exactly. So in that sense, they're identical.

Aaron van Wirdum Yes.

Sjors Provoost But they are also different.

Aaron van Wirdum Let's get into the first big difference. Well, we already mentioned one difference, which is the very, very, very subtle sort of difference between starting at a height or the thing we just mentioned. Now let's get into a bigger difference.

Sjors Provoost Right, because there is also a height for a timeout in this [unclear] and that's also a block. But not only is that a block, you know, that could be a slight difference, especially when it's a long time period, right? In the beginning, if you use block height or time date, you can guess very accurately. But if it's a year ahead, then you can't.

Aaron van Wirdum Yeah.

Sjors Provoost But this is actually almost two years ahead, this block height that they have in there. So it goes on much longer.

Aaron van Wirdum Two years from now, you mean?

Sjors Provoost Yeah.

Aaron van Wirdum Well, one and a half, but yeah.

Sjors Provoost Exactly. So in that sense, it doesn't really matter that they're using height because it's such a big difference anyway. But this is important. So they will keep signaling much longer than the Speedy Trial. which, well, we can get into the implications later, but basically they'll signal much later.

Aaron van Wirdum Yeah, let's stick to the facts first and the implications later. So yeah, Speedy Trial, the Bitcoin Core thing, it will last for three months. And this one, the LOT=true client will allow signaling for 18 months.

Sjors Provoost And then the biggest difference, of course, or well, the other big difference is that at the end of that 18 months, whereas the Speedy Trial will simply give up. And continue, the LOT=true will actually wait for miners who do signal which could be nobody or it could be everybody. Yeah so they'll

Aaron van Wirdum only accept signaling blocks after these 18 months. Yeah so it's a little bit, um for those who are aware of sort of the whole block size war period it's a little bit like the BIP 148 client.

Sjors Provoost Yeah it's pretty much the same with slightly… better tolerance, I think. Like the... The UASF client required every single block to signal, whereas this one requires 90% to signal. But in practice, if… if… you know, if… you're the miners in the last 10% of that window, I guess you you need to pay a bit more attention. But other than that, it's the same.

Aaron van Wirdum Yeah, so that's why some people would call this the UASF client. It's the UASF client where the BIP 148 client was the UASF client for SegWit. This is sort of the UASF client for Taproot. I know that, for example, Luke Dashjr, who's been contributing to this client, doesn't like the term UASF in this context because there's also 18 months of just regular miner signaling.

Sjors Provoost So did the UASF. It's a bit more patient than the UASF.

Aaron van Wirdum Like I said, there's a lot of discussion on the names of the client and how people should call it or not call it. But just in general, some people have been calling it the UASF client and this is why.

Sjors Provoost Okay. Yeah. So you can call it the slow UASF or something. Yeah.

Aaron van Wirdum I've also seen the name user-enforced miner-activated soft fork. So that's... [unclear] or whatever there people are coming up with terms and names. I think the basic facts are clear now I hope.

Sjors Provoost Yes.

Aaron van Wirdum Okay, so let's get into the implications and in specific there are some potential incompatibilities between these two activation clients.

Sjors Provoost Yeah for sure.

Aaron van Wirdum Yeah so everyone agrees that Taproot is great. Everyone wants Taproot. Everyone agrees that it would be preferable if miners activate it. The only thing that there are still some disagreements on is sort of what's what's kind of the backup plan, and that's where the incompatibilities come in. Am I saying that right? Do you agree?

Sjors Provoost Yeah, I think so.

Aaron van Wirdum Okay, so what are the incompatibilities?

Sjors Provoost Yeah, so in the case where the Speedy Trial does not activate um so

Aaron van Wirdum First of all and I already mentioned this but just to emphasize emphasize this, if Speedy Trial activates Taproot there are no incompatibilities. Both clients are happily using Taproot starting in November. And this seems pretty likely because 90% of miners, mining pools, I should say, have already indicated that they support Taproot. So likely there's no big deal here. Everything will turn out fine. If Speedy Trial doesn't succeed in activating Taproot, that's where we enter a phase where... We're going to start to look at potential incompatibilities.

Sjors Provoost Yeah, for sure. So imagine one scenario where Speedy Trial fails and, you know, probably Bitcoin Core people will think about that for a while and think about some other possibilities. But for some reason, miners get wildly enthusiastic right after Speedy Trial fails and start signaling at 90%.

Aaron van Wirdum Right.

Sjors Provoost Now, as far as Bitcoin Core is concerned, Taproot never activated. Where as far as the speed… as far as the UASF or a LOT=true client, Taproot did just activate.

Aaron van Wirdum Yeah so let's say in month four, you know we have three months of Speedy Trial, and in month four miners suddenly signal readiness for Taproot that means Bitcoin Core doesn't care anymore. Bitcoin Core at least a 21.1 client isn't looking at the signaling anymore. But this LOT=true client is. So on the LOT=true client, Taproot will be activated in November, while on this Bitcoin Core client, it will not. Yeah.

Sjors Provoost And then, of course, if you are using that LOT=true client and you start immediately using Taproot at that moment because you're very excited and you see all these blocks coming in, you may or may not lose your money because... Anybody who's running the regular Bitcoin Core client will accept those thefts from Taproot addresses essentially.

Aaron van Wirdum Yeah well in this case it matters what miners are doing as well right? So

Sjors Provoost Yes exactly.

Aaron van Wirdum If miners signal readiness because they're actually ready and they're actually gonna enforce Taproot then it's fine. Then there's no issue because they'll just you know, enforce the software and even Bitcoin Core 21.1 nodes will follow this chain and the Taproot LOT=true client will also enforce and everyone's still happy on the same chain. The only scenario where this is a problem which you just described, if it is if… miners do signal readiness but they aren't actually going to enforce…

Sjors Provoost Yeah.

Aaron van Wirdum The Taproot rules.

Sjors Provoost The problem is of course in general with soft forks but especially if it's you know not everybody's on the same page about what the rules are, is you only know that it's enforced when it's actually enforced. You don't know if it's going to be enforced in the future. So this would create a conundrum for everybody else because then the question is okay what to do? One thing you could do at that point is saying well obviously Taproot is activated so let's just release a new version of Bitcoin Core that just says okay retroactively it activated. It could just be a BIP 9 soft fork repeating the same bit, but slightly later. Or could you say, no, we know it activated. We'll just hard code the flag date. The problem is between the time you...

Aaron van Wirdum It could just be a second Speedy Trial, whatever. Everything would work in that case, right?

Sjors Provoost Well, yeah, there is a problem with reusing the same bit number within a short period of time. So because it would be exactly the week after... In a scenario we talked about, it may not be possible to use the same bit. And so then you have a problem because you can't actually check that specific bit, but there's no signal on any of the other bits. So that would create a bit of a headache. But the other solution would be very simple to say, okay, it apparently activated. So we'll just hard code the block date and activate it then. The problem is, what if between the time that... the community decides, let's do this. And the moment that software is released and somewhat widely deployed, one or more miners say, actually, we're going to start stealing these Taproot coins. You'd get a massive clusterfuck in terms of agreeing on the chain. Now, miners would not be incentivized to do this, right? Because why would you deliberately create complete chaos if you just signaled for a soft fork? But it is a very scary situation, and it might make it scary to make the release. Because if you do make the release, but miners start playing the shenanigans, well, what do you do then? Do you accept a huge reorg at some point? Or do you give up and consider it not deployed, but then people lose their money, and you've released a client that you now have to hard fork from, technically? So it's not a good scenario.

Aaron van Wirdum It gets complicated in scenarios like this, also with game theory and with economics. You know, even if miners would choose to steal, they risk stealing coins on a chain that could be re-orged. So now they've just mined a chain that could be re-orged if other miners do enforce the Taproot rule. So it gets weird. It gets, you know, it's a discussion about economic incentives and game theory in that scenario. Personally, I think it's pretty unlikely that something like this would happen, but it's at least technically possible, and it's something to be aware of.

Sjors Provoost Yeah, it does make you wonder whether, as a miner, it's smart to signal immediately after the Speedy Trial. Because this LOT=true client allows for two years anyway. So if the only reason you're signaling is because this client exists, then I would strongly suggest not doing it immediately after the Speedy Trial. But maybe waiting a little bit until there's some consensus about what to do next.

Aaron van Wirdum Yeah, one thing you mentioned, and I want to quickly address that and emphasize that, is that this risk always exists for any soft fork.

Sjors Provoost Yes.

Aaron van Wirdum Miners can always sort of false signal, and then you know they could have done it with SegWit, for example, false signal, and then steals coins from SegWit outputs, and then old nodes will notice difference. So that's… always a risk. I think the difference here is that Bitcoin Core 21.1 users in this scenario might think that they're running a new node and from their perspective they are running an update node and still they're sort of running the same risks as previously all only sort of outdated nodes would runs.

Sjors Provoost Well I'd be mostly worried about the potential 0.21.2 users who are installing the successor to Speedy Trial, which retroactively activates Taproot, perhaps, that group is just very uncertain of what the rules are.

Aaron van Wirdum Sorry, which group is this?

Sjors Provoost So if the Speedy Trial fails and then it's signaled, right? So there might be a new release and people would install that new release, but then it's not clear whether that new release would be safe or not. Because that very new release would be the only one who would actually think that Taproot is active, as well as [unclear].

Aaron van Wirdum Yeah, as well as [unclear].

Sjors Provoost But now we don't know what the miners are running, and we don't know what the exchanges are running, because this is very new, right? This would be done... you know in a period of weeks rather than right now we have a six month…

Aaron van Wirdum No hang on hang on, because I guess…

Sjors Provoost The activation date would still be in November.

Aaron van Wirdum Yeah it would still be November. So there's still room to sort of prepare in that case.

Sjors Provoost Yeah okay okay then I guess what I said before is nonsense. And the easier solution would be to do a flag date where the new release would say okay it's just going to activate on November 12th or whatever that block height is without any signaling because the signaling exists but people have different interpretations about it. Yeah that could be a way. Okay.

Aaron van Wirdum I… I'm still completely clear about what we're talking about here but I'm not sure if our listeners are catching up at this point. All right, so we sort of very briefly um re recap… a bit recap. Yeah so if miners activate during the Speedy Trial periods then everything is fine everyone is consensus.

Sjors Provoost Yeah and the new rules take effect in November.

Aaron van Wirdum Yeah, if miners activate after the Speedy Trial period, then there is a possibility that the LOT=true client and the Bitcoin Core 21.1 client won't be in consensus if an invalid Taproot block is ever mined. However...

Sjors Provoost No, earlier. Because of the... Oh, no, you're right. Because they have no force signaling. Yeah, you're right. If an invalid Taproot transaction shows up after November... 12?

Aaron van Wirdum Yeah. And if that is mined and enforced by a majority of miners, only then, so then a majority of miners must have false signals, then the two clients can get out of consensus.

Sjors Provoost Yes.

Aaron van Wirdum This is just a technical, technically this is true. I personally think it's fairly unlikely. I'm not too concerned about this, but it's at least technically true and something people should be aware of.

Sjors Provoost And so that scenario could be prevented, by saying, well, if we see this false signaling, like a week direct… or false quote unquote signaling, if we see this massive signaling a week after the Speedy Trial, then you could decide to release a flag date client, which just says we're just going to activate this November 12th because apparently the miners want this. And otherwise we have no idea what to make of the signal.

Aaron van Wirdum Yes. Well, I find it very hard to predict what Bitcoin Core developers in this case are going to decide.

Sjors Provoost I agree.

Aaron van Wirdum This is one possibility. Okay. That was sort of one way the two clients can become incompatible potentially and that there is another way which is maybe more likely or at least more... It's not as complicated. The other one is a little bit simple.

Sjors Provoost Yeah, the other one is let's imagine that the Speedy Trial fails and the community does not have consensus of how to proceed next. And Bitcoin Core developers can see that. Like there's just ongoing discussion and nobody agrees. And maybe Bitcoin Core developers decide to therefore just wait and see.

Aaron van Wirdum Yeah, miners aren't signaling.

Sjors Provoost Yeah, or erratically, et cetera. Miners aren't signaling. The discussion still goes on. Nothing happens. Well, then this LOT=true mechanism kicks in.

Aaron van Wirdum After 18 months? Yeah. So we're talking about November 2022 now. It's a long way off. But at some point, the LOT=true mechanism will kick in.

Sjors Provoost Exactly. So those nodes will then, assuming the miners are still not signaling, they will just stop.

Aaron van Wirdum Yeah, or may at least if there's… that… that's if there's literally no LOT=true blocks, basically, if there are no signaling blocks.

Sjors Provoost Now, in the other scenario where miners do massively start signaling, now we're kind of back to that previous scenario where suddenly there's a lot of miners signaling on bit number one. So maybe the fork is active, but now there's no delay because... If the signaling happens anywhere after November 12th, the LOT=true client will immediately activate Taproot or after one adjustment period.

Aaron van Wirdum Well, let's be clear because I'm not sure I'm following you, but I think what you mean is that in that case, okay, repeat what you said.

Sjors Provoost Yeah, so let's say in this case, in December of this year, The miners suddenly start signaling because...

Aaron van Wirdum In September of this year.

Sjors Provoost December of this year. So at the end of this year.

Aaron van Wirdum Yeah.

Sjors Provoost But after the minimum activation height.

Aaron van Wirdum Sure.

Sjors Provoost So in December, they all start signaling. So then the Bitcoin Core client will ignore it, right? But the LOT=true thing, clients will say, okay, Taproot is active. So then we get...

Aaron van Wirdum This is just the same scenario we just discussed.

Sjors Provoost Well, except now there's no...

Aaron van Wirdum Where it's only a problem if there's false signaling. Otherwise, it's fine.

Sjors Provoost Yeah, there's a problem with this false signaling, but it is more complicated to resolve this one because that option of just releasing a new client with a flag date in it that is far enough into the future, that's no longer there because it's potentially active immediately. And if you do a release, but then suddenly a miner starts not enforcing the rules, you get this confusion that we talked about earlier. And then we were able to solve it by just making a flag day. So this would be even messier. Maybe it's also even less likely.

Aaron van Wirdum It's pretty similar to the previous scenario, but even a little bit more difficult. Less obvious how to solve it.

Sjors Provoost Yeah, I think it's messier because it is less obvious how you would do a flag day release in Bitcoin Core in that scenario because it immediately activates.

Aaron van Wirdum But that's not where I wanted to go with this.

Sjors Provoost Well, you wanted to go to, for some scenario, miners would wait all the way until the end.

Aaron van Wirdum Yes.

Sjors Provoost Until they start signaling.

Aaron van Wirdum That's where I wanted to go.

Sjors Provoost Which is where the mandatory signaling kicks in. So if there's no mandatory signaling, then the LOT=true nodes will stop until somebody mines a block that they like to see, which is a block that signals. Now, if they do see this block that signals, we're back in the previous example where suddenly the regular Bitcoin Core nodes see this signaling, but they ignore it. And now there's a group of nodes that believe Taproot is active, and there's a group of nodes that don't. So somebody has to then decide what to do with it.

Aaron van Wirdum You're still talking about false signaling here?

Sjors Provoost Well, no.

Aaron van Wirdum Otherwise, there's no problem.

Sjors Provoost There is, because even if the signaling is genuine, you still want there to be a Bitcoin Core release, probably, that actually says, okay, we have Taproot now. But the question is, when do we have Taproot now, according to that release? What is the safe date to put in there? You could do it retroactively.

Aaron van Wirdum Whenever they want.

Sjors Provoost Yeah, well then the problem is what happens…

Aaron van Wirdum The point is, if miners are actually enforcing the new rules then the the chain will stay together.

Sjors Provoost That's true.

Aaron van Wirdum And it's sort of up to Bitcoin Core I guess to implement it whenever they've…

Sjors Provoost Yeah but again the problem is with this signaling, is you don't know if it's active until somebody decides to try and break the rules right? Yeah.

Aaron van Wirdum Yeah but my assumption was that there weren't false signaling, so then they'll just create the longest chain with the valid rules anyways.

Sjors Provoost Of course. The problem with that is that it's unknowable.

Aaron van Wirdum The scenario I really wanted to get to, Sjors, is the very simple scenario that the majority of miners isn't going to signal when the 18 months are up.

Sjors Provoost Exactly.

Aaron van Wirdum In that case, they're going to create a long chain, the longest chain that the Bitcoin Core nodes, the Bitcoin Core 21.1 nodes, I guess in this case, are going to follow, while the LOT=true nodes are only going to accept blocks that do signal, which may be... Either zero or at least fewer or, well, if it's a majority, then there's no split. But if it's not a majority, then we have a split.

Sjors Provoost Yeah, and that chain would get further and further and further behind. So then the incentive to make a release to account for that would be quite small, I think. Well, it depends. This is where your game theory comes in. But from a safety point of view, if you now make a release that says, oh, by the way, we retroactively consider Taproot active, well, that would cause a giant reorg. Well, if you just activate it, that wouldn't cause a giant reorg. But if you say, oh, by the way, we're going to retroactively mandate that signaling that you guys care about, that would cause a massive reorg, which would be unsafe. So that would not be something that would be released probably. So that's a very messy situation.

Aaron van Wirdum There are messy potential scenarios. I want to emphasize to our dear listeners, none of this is going to happen in a couple of... months next couple of months.

Sjors Provoost And hopefully never.

Aaron van Wirdum And hopefully never.

Sjors Provoost So we'll throw in a few other bad scenarios and then I guess we can go into some other topics but yeah.

Aaron van Wirdum Now, I want to mention real quick that the reason I'm not too concerned about these kinds of really bad scenarios playing out is because I think if it seems even slightly likely that there might be a coin split or anything like that there will probably be futures markets and these futures markets will probably make it very clear to everyone if the alternative chain stands a chance or, you know, they'll inform miners on what to mine and prevent the split that way. Or I think, I feel pretty confident about sort of the collective wisdom of the market to warn everyone about potential scenarios and it will probably work out fine. That's kind of my... general assessment.

Sjors Provoost Yeah, I mean, the problem with this sort of stuff is if it doesn't work out fine, it's really, really bad.

Aaron van Wirdum Yes.

Sjors Provoost And then we get to say retroactively, well, I guess it didn't work out fine. So one little...

Aaron van Wirdum I want to bring something up before you bring up whatever you wanted to bring up. I've seen some concerns by Bitcoin Core developers about the development process of the LOT=true client. And I think this gets down to the sort of... Gitian building, Gitian signing, which we also discussed in our episode on that specific topic.

Sjors Provoost Yeah, we talked about the need for software to be open source, to be easy to audit.

Aaron van Wirdum Yeah, okay. Sort of quickly give your view on that in this context.

Sjors Provoost So basically the change that they made relative to the main Bitcoin Core client is not huge. And you can see it on GitHub. So in that sense, that part of the open source, I think is... reasonably doable to verify. I think that code has had less review, but not zero review.

Aaron van Wirdum Less than Bitcoin Core is what you mean?

Sjors Provoost Yeah, exactly. But much more than the UASF.

Aaron van Wirdum A LOT=true client.

Sjors Provoost No, I mean much more than the 2017 UASF.

Aaron van Wirdum Oh, more than that?

Sjors Provoost I would say.

Aaron van Wirdum Right, okay.

Sjors Provoost And besides, the idea has been studied a bit longer. But then the second problem is how do you know that what you're downloading isn't malware? And that's where you get release. Well, there's two measures there. There's release signatures. Now the website there, I think, explains pretty well how to check those. So I think they're signed by Luke Dashjr and by the other developer. So you can check that.

Aaron van Wirdum Bitcoin Mechanic is the other.

Sjors Provoost Okay.

Aaron van Wirdum Well, okay. So actually it's released by Bitcoin Mechanic and Shinobi. And then Luke Dashjr is sort of the... advisor, contributor.

Sjors Provoost Yeah. So there's a, usually there's a, there's a binary file that you download and then there's a file with checksums in it. And that file with checksums is also signed by a known person. So if you have Luke's key or whatever they're key and you know them, then you can check that at least the binary you downloaded is not coming from a hacked website.

Aaron van Wirdum Right.

Sjors Provoost And then the second thing, because then you just have a binary and you know, they signed it, but… Who are they, right? So the second thing is you want to check that this code matches the binary. And that's where Gitian building comes in, which we talked about in an earlier episode.

Aaron van Wirdum Right.

Sjors Provoost Basically deterministic builds. So it takes a software, it takes a source code and it produces the binary. And then you sign or multiple people can then sign that indeed, according to them, this source code produces this binary. And the more people that confirm that, the more likely it is that they're not colluding.

Aaron van Wirdum Yeah.

Sjors Provoost Right. And so I think there's only two Gitian signatures for this other release so far.

Aaron van Wirdum So the Bitcoin Core software is being Gitian signed by...

Sjors Provoost I think 10 or 20 people.

Aaron van Wirdum Yeah. A lot of the experienced Bitcoin Core developers that we know that have been developing the Bitcoin Core software for a while, maybe including you, did you sign it?

Sjors Provoost The most recent release, yes.

Aaron van Wirdum And, you know, you're kind of trusting that they're not all colluding and spreading malware, I guess. It still comes down to trust in that sense for most people.

Sjors Provoost Yeah, a little bit. I mean, the thing is, I think if you're really contemplating running this type of alternative software, you really should be knowing what you're doing in terms of all these reorg scenarios. If you already know what you're doing in those terms, then just compile the thing from source. Because why not? If you're not able to compile things from source, you probably shouldn't be running this. But that's up to you. Uh I I'm not I'm not saying that I'm worried that they would be like I'm not worried that they're shipping malware of course, but um the thing is it's in general it's it's just a matter of time before somebody says oh I have a different version with LOT=happy, and please download it here and then it steals all your Bitcoin. So it's more the precedent this is setting that I'm worrying about then that this thing would actually have malware in it.

Aaron van Wirdum Yeah that's fair. So maybe um sign it, Sjors?

Sjors Provoost No, because I don't think this is a sane thing to release.

Aaron van Wirdum Okay, fair enough.

Sjors Provoost But that's just my opinion. I mean, everybody's free to run whatever they want to run.

Aaron van Wirdum Was there any other thing you wanted to bring up?

Sjors Provoost Yeah, basically, we talked about true signaling or false signaling on bit one, but a very real possibility, I think, is if this activation fails and we want to try something else, then we probably don't want to use the same bit, if it's before the timeout window. So that could create a scenario where you might start saying, okay, let's use another bit to do signaling. And then you could get some confusion where there's a new Bitcoin Core release that activates using bit three, for example. But the LOT=true folks don't see it because they're looking at bit one. That may or may not be an actual problem. The other thing is that there could be all sorts of other ways to activate this thing. One thing could be a flag day. So if Bitcoin Core were to release a flag day, then there won't be any signaling. So a LOT=true clients won't know that Taproot is active and they will demand signaling at some point, even though Taproot is already active.

Aaron van Wirdum Yeah, your point being that we don't know what... Bitcoin Core will release after a Speedy Trial and what they might release might not necessarily be compatible with the LOT=true client.

Sjors Provoost Exactly. Now, it's also true of course...

Aaron van Wirdum I will say that works both ways, of course.

Sjors Provoost Yeah, sure. I'm just reasoning from one point here. I would also say that in the event that Bitcoin Core releases something else that has pretty wide community support, I would imagine the people who are running the BIP 8 clients are not like sitting in a cave somewhere. They're probably the relatively active users that know that they can decide, okay, you know what? I'm just going to run this Bitcoin Core version again because there's a flag date in it, which is earlier than the force signaling. So I could imagine that they would decide to just run it or not.

Aaron van Wirdum That also works both ways.

Sjors Provoost Well, no, not really, because I am much more worried about people who are not following this discussion, who just default download whatever the newest version of Bitcoin Core is, or don't upgrade at all, right, who are still running, say, Bitcoin Core 0.15. I'm much more worried about that group than about the group that actively takes a stance in this thing. Because if you actively take a stance by running something else, then you know what you're doing. And so it's kind of up to you to stay up to date. But we have kind of a commitment towards all the users that if you're still running in your bunker the 0.15 version of Bitcoin Core, that nothing bad should happen to you if you just follow the most proof of work.

Aaron van Wirdum Yes, that could also mean making it compatible with the LOT=true Client.

Sjors Provoost No, because as far as the 0.15 node is concerned, there is no LOT=true Client.

Aaron van Wirdum Well, okay. Do we want to get into all sorts of scenarios? The scenario that I'm most concerned about is that... The LOT=true chain, to call it that, if there's ever a split, will win, but only after a while, because then you get long reorgs. So this gets back to the sort of LOT=true versus LOT=false discussion in the first place.

Sjors Provoost I can only see that happening with a massive price collapse of Bitcoin itself. But because if… if… if… the scenario comes to be where a LOT=true starts winning after delay, which requires a big reorg, I would say that… Yeah… if it's more likely to win, its relative price will go up because it's more likely to win. But because a bigger reorg is more disastrous for Bitcoin, the longer the reorg, the lower the Bitcoin price. So I think, yeah, that would be the bad scenario. If there is a thousand block reorg or more, then I think the Bitcoin price will just collapse to something very low where we don't really care whether the LOT=true client wins or not. That's just... It doesn't matter anymore.

Aaron van Wirdum Yeah, I agree with that. The reason I'm not concerned is what I mentioned before is because I think these things will be sorted out by futures markets well before it actually happens.

Sjors Provoost Yeah, I guess the futures market would predict exactly that, basically saying, well, that would not be good. Depending on your confidence in futures market, which for me is not that amazing.

Aaron van Wirdum Back on topic. Did we cover everything? More or less, I think. Was there anything else?

Sjors Provoost I think so. I mean, we could still talk about this nitty difference between block height versus block time, which caused all this fiasco, but I don't think it's an interesting difference.

Aaron van Wirdum I guess while we're recording the podcast, you might as well mention it.

Sjors Provoost Okay. So when we first described the Speedy Trial, we kind of assumed it would be a… everything would be based on block height. So there would be a transformation from the way soft forks work right now, which is based on these medium times, to just block heights, which is conceptually simpler. But later on, there was some discussion between the people who were working on that, considering maybe the only Speedy Trial difference should be the activation height, and none of the other changes. So from the point of view of the existing code base, it's easier to make the Speedy Trial just adjust one parameter, which is an activation height, minimum activation height, versus the change where you change everything into block height, which is a bigger change from the existing code, even though the end result is easier.

Aaron van Wirdum Yeah.

Sjors Provoost So a purely block height-based approach is easier to understand, easier to explain what it's going to do, when it's going to do it. And there's some edge cases that are also easier. But to stay closer to the existing code base is easier for reviewers, somehow, somewhat. But the difference is pretty small, so I think they eventually decided... Some people decided on the coin toss and other people, I think, agreed even without the coin toss.

Aaron van Wirdum There are arguments on both sides, but they seem to be pretty subtle, pretty nuanced. Like we mentioned, Speedy Trial is going to start on the same date anyways. So it doesn't seem to matter that much. And at some point, some developers were seriously considering just deciding through a coin flip, basically using the Bitcoin blockchain for that, picking a block in the near future and seeing if it ends with an even or uneven number, I guess. I don't know if that's literally what I did, but that would be one way of doing it. I think they did do the coin flip, but then after that, the sort of champions for both solution ended up agreeing anyways.

Sjors Provoost Yeah, and they happen to agree on the same thing that the coin flip said, but yeah.

Aaron van Wirdum Yeah. The main dissenter was Luke Dashjr, who feels strongly about using block heights consistently. And he also is of the opinion that the community had found consensus on that and that Bitcoin Core developers not using that is sort of going back on breaking community consensus, which...

Sjors Provoost Well, that's his perspective.

Aaron van Wirdum That's his opinion.

Sjors Provoost If you look at the person who wrote the original pull request that was purely height-based, I think that was Andrew Chow, he closed his own pull request in favor of the... mixed solution that we have now. So if the person writing the code removes it himself, I think that's pretty clear. I mean, from my point of view, the people who are putting in the most effort should probably decide when it's something this trivial. Yeah either way I don't think it matters that much.

Aaron van Wirdum So it seems like a minor point to me, but clearly not everyone agrees it's a minor point.

Sjors Provoost No but that's sort of what bike shedding is about right? It wouldn't be bike shedding if everybody thought that it was irrelevant which color the bike shed had.

Aaron van Wirdum Okay. Let's let's just let's leave the coin flip and uh the the time block height thing behind us because I think we covered everything and in maybe we shouldn't dwell on this last point. Okay is that it?

Sjors Provoost I think so.

Aaron van Wirdum I hope this was um at all clear for all this…

Sjors Provoost I think we can very briefly still interject one thing that was brought up which is the time warp attack which I think we have…

Aaron van Wirdum Oh yeah we don't mention that and that is somewhat relevant maybe. Yeah, in this context.

Sjors Provoost Yeah one of the arguments against…

Aaron van Wirdum using block time is that it opens the door to… time warp attacks where miners are basically faking the timestamps on the blocks they mine to pretend like it's a different time and date and that way they can, for example, just skip the signaling period altogether if they collude in doing that.

Sjors Provoost Yeah, that sounds like an enormous amount of effort for no good reason, but it is an interesting scenario. We did an episode about the time warp attack a long time ago, back when I understood it, and there is a software proposal to get rid of it, that I don't think anybody objected to but also nobody bothered to actually implement and so one way to deal with this hypothetical scenario is that if it were to happen well then we deployed the soft fork against the time warp attack first and then we tried Taproot activation again.

Aaron van Wirdum Yeah I mean the argument against that from someone like Luke is of course that yeah you can fix any bug but you can also just not include the bug in the first place.

Sjors Provoost Well, it's nice to know that miners would be willing to use… if we know that miners are actually willing to exploit the time warp attack that is incredibly valuable app information. If they have a way to collude and and a motivation to use that attack then I think it's worth… the cost of that attack would just be pretty low right it would be delaying Taproot by a few months but we'd have this massive conspiracy unveiled. So I think that's a win.

Aaron van Wirdum Yeah, the other thing, I think I'll just mention this because Luke believes, the way Luke sees it is that there was sort of already consensus on all sorts of things, on using BIP 8 and even sort of this LOT=true thing he saw as something of a consensus effort. And then using block times is sort of frustrating that in his opinion. I don't want to speak for him, but if I'm trying to sort of... channel Luke a little bit or trying to explain his perspective that would sort of be it. That in his view consensus was already forming and now a different path is taken.

Sjors Provoost I don't think this new approach blocks any of the LOT=true stuff that much we looked through all the scenarios here and I don't think we got… the confusion wasn't around block height versus time right it was against all sorts of things that could go wrong depending on how things evolve, but not that particular issue. So I don't think you should worry about that. As for consensus, I mean, consensus is in the eye of the beholder, right? But I would say if multiple people disagree, then there's not consensus.

Aaron van Wirdum Yeah, but that would also work the other way around, where Luke disagrees with using block time.

Sjors Provoost Right, but then he cannot say there was consensus on something. People, if they disagree, then by definition there wasn't consensus. But maybe...

Aaron van Wirdum Yes, it was my impression that there was no consensus because people disagreed.

Sjors Provoost Exactly.

Aaron van Wirdum Okay. Lars… Sjors.

Sjors Provoost Sjors.

Aaron van Wirdum I'm starting to forget your name.

Sjors Provoost That's all right.

Aaron van Wirdum The podcast is taking too long. Sjors, we're dwelling a lot. Let's wrap it up. I’m going to… for our listeners that are confused and worried, I'm going to emphasize the next three months, Speedy Trial is going to run on both clients. If miners activate through Speedy Trial, we're going to have Taproot in November and everyone's going to be happy. And then we'll continue the soft fork discussion with the next soft fork.

Sjors Provoost Exactly. We can have the same arguments all over again because we have learned absolutely nothing. All right. In that case, thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.