Episode 29: Explaining Taproot Activation and LOT=True VS LOT=False

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

Sjors Provoost Hello.

Aaron van Wirdum Sjors, make the pun.

Sjors Provoost We have a lot to talk about.

Aaron van Wirdum We have a lot to discuss.

Sjors Provoost Yes.

Aaron van Wirdum In this episode, we're going to discuss the Taproot activation process and the debate surrounding it on the parameter LOT. Lock in on timeout.

Sjors Provoost That's right.

Aaron van Wirdum Which can be set to true and false.

Sjors Provoost And maybe as a reminder to the listener, we have talked about Taproot in general multiple times, but especially in episode two. And we've talked about activating Taproot, activating soft forks in general in episode three. So we might skip over a few things.

Aaron van Wirdum Yeah, in episode three, we discussed all sorts of different proposals to activate Taproot, but it's been over half a year at least right?

Sjors Provoost That was on September 25th, so about five months, yeah.

Aaron van Wirdum Yeah so it's been a while, and by now the discussion has reached sort of its final stage, I would say. And at this point the discussion is about the LOT parameter true or false. First, to recap very briefly, Sjors, can you explain what are we doing here? What is the soft fork?

Sjors Provoost Right. So the idea of a soft fork is that you make the rules more strict. And that means that from the point of view of a node that doesn't upgrade, nothing has changed. They're just seeing transactions that are valid to them. From the nodes that do upgrade, because they have more stricter rules, they do care what happens. But the nice thing about soft forks is that as a node user, you can upgrade whenever you want. If you don't care about this feature, you can upgrade whenever you want.

Aaron van Wirdum Yeah, soft fork is a backwards compatible protocol upgrade. And the nice thing about it is that if at least half of all miners, if a majority of miners enforces the rules, then that sort of automatically means all nodes on the network will follow the same blockchain.

Sjors Provoost That's right, because the older nodes don't know about these new rules, but they do know that they'll follow the chain with the most proof of work as long as it's valid. And so if most of the miners are following the new rules, then most of the proof of work will be following the new rules. And so a node will, by definition, follow that. An old node will, by definition, follow it.

Aaron van Wirdum Okay, so the nice thing about soft forks is that if a majority of hash power enforces the new rules, the network will remain in consensus. Therefore, the last couple of soft forks were activated through hash power coordination. That means that miners could include a bit in the blocks they mined, signaling that they were ready for the upgrade. And once most miners, it was 95% in most cases, 95% of miners indicated that they were ready, nodes would recognize this and enforce the upgrade.

Sjors Provoost Yeah, that's right.

Aaron van Wirdum Okay.

Sjors Provoost And so this would involve a node would check, for example, every two weeks, how many blocks signaled this thing, and if yes, then it says okay, the soft fork is now active. I'm going to assume that the miners will enforce this.

Aaron van Wirdum Right. Now the problem with this upgrade mechanism is that it also means miners can block the upgrades.

Sjors Provoost Yeah, that's the downside.

Aaron van Wirdum Even if everyone agrees with the upgrade, so for example, in this case, Taproot, it seems to have broad consensus. But despite that broad consensus, miners could still block the upgrade, which is what happened with SegWit a couple of years ago.

Sjors Provoost Right, back then there was a lot of debate about the block size and lots of hard fork proposals and lots of hurt feelings. And so... Now, eventually it was very difficult to get SegWit activated because miners were not signaling for it, probably mostly intentionally. Now, it could also happen that miners just ignore an update, not because they don't like it, just because they're busy.

Aaron van Wirdum Yeah, in the case of SegWit, that was, in the end, resolved through UASF or at least that was part of it, we're not going to get into that in depth right but that basically meant that a group of users said on this day some date in the future, was August 1st 2017, we're going to activate the SegWit rules no matter how much hash power actually supports it.

Sjors Provoost Right, and at the same time, and perhaps as a consequence of that, a group of miners and other companies agreed that they would start signaling for SegWit, and there was a whole bunch of other things going on at the same time. But whatever happened on the 1st of August, the thing activated, or a little bit earlier, I think.

Aaron van Wirdum Yeah, okay, so now we're four years ahead in time. It's four years later, and now the Taproot upgrade is ready to go. And what happened a couple years ago is now spurring new debate on the Taproot upgrade. And that brings us to the LOT parameter, which is a new parameter. Although, you know, it's sort of inspired by things from that SegWit upgrade period.

Sjors Provoost It's basically like a built-in UASF option, which you can decide to use or not. But it's basically, there is now a sort of a formal way in the protocol to do this, to activate a soft fork like at a cutoff date.

Aaron van Wirdum Yeah, so LOT has two options. The first option is false. So that LOT is false. That means that miners can signal for the upgrade for one year and then in that year if there's 90 thresholds for the upgrade it will activate, as we just explained. By the way, one year and 90 isn't set in stone, but that's sort of what people seem to settle on. For convenience sake, that's just what I'm going to use while discussing this. So miners have one year to activate the upgrade. If after that year they have not upgraded, the Taproot upgrade will expire. It will just not happen, basically. That LOT is false.

Sjors Provoost And of course, there's always the option then of shipping any release, trying again. It's not that… it's… it's not a no vote but it just nothing happens.

Aaron van Wirdum Yeah, exactly. Okay, then there's LOT is true, which... Again, miners have one year to signal support for the upgrade. If a 90% threshold is met, then the upgrade will activate. However, the big difference is what happens if miners don't reach this threshold if they don't signal for the upgrade. In that case, when the year is almost over, nodes that have LOT is true will start to reject all blocks that don't signal for the upgrade. In other words, they only accept blocks that will signal for the upgrade, which means, of course, that the 90% threshold will be met and therefore Taproot, or any other soft fork in this mechanism, will activate.

Sjors Provoost If enough blocks are produced.

Aaron van Wirdum If enough blocks are produced, yes, that's… that's true. A little bit of nuance is that, for those who find that interesting, even LOT is true nodes will accept up to 10% of blocks that don't signal. That's to avoid weird chain split scenarios?

Sjors Provoost Yeah, basically because if it activates in a normal way, only 90% has a signal. So if you mandate signaling, then it would be weird to have a different percentage suddenly.

Aaron van Wirdum Yeah, so they're going to accept the first 10% of non-signaling blocks, but after that, every block that doesn't signal is going to be rejected. So the 90% threshold will definitely be reached. Now, the big reason for LOT is true, for that parameter to set it to true, is that this way miners cannot block the upgrade. Even if they try to block the upgrade, once the year is over, nodes will still enforce Taproot. So it's guaranteed to happen.

Sjors Provoost If enough blocks are produced.

Aaron van Wirdum If enough blocks are produced.

Sjors Provoost Yeah, we can get into some of the risks with this, but I think you want to continue explaining a bit.

Aaron van Wirdum Yeah, so in other words, the reason some people like LOT is true, it's because that way miners don't have a veto, a veto. Now the counter argument there, and you already sort of suggested that, is that miners don't have a veto anyways. Even if we use LOT is false, the upgrade would expire after a year. But after that year, we can just deploy a new upgrade mechanism and a new signaling period. And this time maybe use LOT is true.

Sjors Provoost Yes, or even while this thing is going on, right? So you could wait half a year with the LOT is false. And then half a year later saying, okay, this is taking too long. Let's take a little bit more risk and set LOT to true.

Aaron van Wirdum Exactly.

Sjors Provoost Or lower the threshold.

Aaron van Wirdum Yes.

Sjors Provoost Or some other permutation that slightly increases the risk, but also increases the likeness of activation.

Aaron van Wirdum Yeah, you're right. But that's actually also one of the arguments against using LOT is false. LOT is true proponents say that because you just suggested we can do it after six months but there's another group of users that might say no no first wait until the year is over and then we'll just redeploy again. So let's say that after six months Taproot hasn't activated now all of a sudden you get a new discussion between people that want to start deploying LOT is true clients right away and groups of users that want to wait until the year is over. So it's sort of reintroducing the discussion we're having now, except by then we only have six months to resolve it. It's like a ticking time bomb kind of situation.

Sjors Provoost Well, not really to resolve it. I mean, if you don't do anything for six months, then there's only one option left, which is to just try again with the new activation bit.

Aaron van Wirdum Yeah, but then you need to agree on when you're actually going to do that. Are you going to do that after six months or are you going to do that later? And people might disagree.

Sjors Provoost Yeah, then you'd be back to where we are now, except you know a little bit more because now you know that the miners weren't signaling.

Aaron van Wirdum Yeah, and you don't have a lot of time to resolve it because after six months, something might happen. Some group of users might run through.

Sjors Provoost Yeah, so the thing you're talking about here is the possibility of, say, anarchy in the sense that there's no consensus about when to activate this thing. And one group, I think we discussed this at length in the third episode, one group just gets really aggressive and says, no, we're going to activate this earlier. And so then nobody knows when it's going to happen.

Aaron van Wirdum Yes, well, and also let me put it differently. If right now we're saying, okay, if after six months miners haven't activated for Taproot, then we'll just upgrade to LOT is true clients after six months. Then LOT is true proponents will say, well, if that's the plan anyways, let's just do it now. That's much easier. Why do we have to do that halfway? So that's sort of the counter argument to the counter argument.

Sjors Provoost Yeah, I can see that. But of course, there's also the scenario where we never do this, where Taproot just doesn't activate. I mean, it just depends on what people want. But there is something to be said for a status quo bias where you don't do anything if it's too controversial for whatever reason. Now, there's another sort of a side case here that is useful to keep in mind. There might be a very good reason to cancel Taproot, right? There might just be a bug that...

Aaron van Wirdum You're getting ahead of me, Sjors, You're getting ahead of me… Let me… Because there are a bunch of arguments in favor of LOT is false.

Sjors Provoost Okay.

Aaron van Wirdum Okay, so one argument is we've basically already done LOT is false a bunch of times, the previous miner activated soft forks. And most of the times it went fine. There was just this one time with SegWit in the midst of a big war. And we don't have a big war now. There's no reason to change what we've been doing successfully until now. That's one argument. The counter argument would, for example, be, yeah, but if you choose LOT is false now, that could actually draw controversy itself. You know, that could be used to drive a wedge or, you know, we're not in a war right now, but it could cause a war.

Sjors Provoost Yeah, but I don't see how that argument doesn't apply to LOT is true.

Aaron van Wirdum No, that's probably fair. Yeah, I tend to agree with that. Okay, then the other argument for LOT is false is that miners and especially mining pools have already indicated that they're supportive of Taproot and that I'll activate it and you know it's not necessary to do the LOT is true thing as far as we can tell. Then the third argument is what you just mentioned is that it's possible that maybe someone finds a bug with Taproot, maybe a software bug or maybe some other problem is possible and then if you do LOT is false it's fairly easy to just let it expire and users won't have to upgrade their software again.

Sjors Provoost Right, the only thing then you'd have to recommend that miners do not install that upgrade. And it's worth noting, I think we pointed this out in episode three, people don't always review things very early. So it's very possible that a lot of you know a lot of people have reviewed Taproot code, but others might not bother to review it until the activation code is there because they just wait for the last minute. So it's… it's not implausible that somebody, you know, very smart starts reviewing this very late. Perhaps some exchange that's, you know, about to deploy it.

Aaron van Wirdum Yeah, something like that happened with the P2SH. So the predecessor to P2SH was OP_CSV, I think. That was just about to be deployed and then a pretty horrible bug was found.

Sjors Provoost Yeah, we've seen it with certain altcoins too, that right before deployment, people find zero days, either because they're bullies or just because the code was shipped in a rush and nobody checked it. So there is definitely always a risk, whatever soft fork mechanism you use, that a bug is discovered at the last minute. And if you're really unlucky, then it's too late, it's deployed, and you need a hard fork to get rid of it, which would be really, really bad.

Aaron van Wirdum Well, no, I don't think that's true. There are other ways to get rid of it.

Sjors Provoost Oh yeah, you may be able to soft fork, depending on what the bug is, you may be able to soft fork it out. Yeah,

Aaron van Wirdum There are ways to fix it even in that case. And the other sort of counter argument to that point would be, well, if we're not sure that it's bug free and if we're not sure that this upgrade is correct and it shouldn't be deployed. Either way, not in false or true or anything. So we need to be sure of that anyways.

Sjors Provoost Yeah, but like I said, some people won't review something until it is sort of inevitable.

Aaron van Wirdum Yeah, I'm just… I'm just listing the arguments.

Sjors Provoost That's all right.

Aaron van Wirdum Okay, fourth argument. So the fourth argument for LOT is false, basically, or against LOT is true, is that LOT is true. Am I saying that right? Against LOT is true? Yeah. LOT is true could feed into the perception that Bitcoin and especially Bitcoin Core developers control the protocol have power over the protocol because you know they're shipping code and that becomes that sort of necessarily becomes the new protocol rules in the case of in the case of Taproot so that perception could…

Sjors Provoost There could be some future soft fork where really nobody in the community cares about it, but just a handful of Bitcoin Core developers do, and they kind of force it onto the community, and then you get a bunch of chaos. The… the nice thing about having at least a miner signal is that they are part of the community, and at least they are okay with it. But the problem is it doesn't reflect… it doesn't reflect what other people in the community think about it. It just reflects what they think about it. So there's a bunch of mechanisms, right? There's a discussion on the mailing list. And you see if people have problems, then there's the miner signaling, which is a nice indication that people are happy. So you could just see it as that, as many people consenting as possible. It'd be nice if there were other mechanisms, of course.

Aaron van Wirdum Yeah, the other point is that, you know, Bitcoin Core developers, while they decide which software they include in Bitcoin Core, which code they include in Bitcoin Core, they don't decide what users actually end up running.

Sjors Provoost No, exactly. So nobody might download it.

Aaron van Wirdum Yeah, exactly. They don't actually have power over the network. So in that sense, the argument is bunk, but it could still feed into the perception that they do. And even that perception, if you can avoid it, maybe that's better. That's sort of an argument.

Sjors Provoost And the precedent, right? But if Bitcoin Core is compromised at some point and ships an update and says, well, if you don't stop it, then it's going to activate. And then it's actually nice if the miners can say, nah, I don't think so.

Aaron van Wirdum But users could say that as well by not downloading it, like you said. Okay, then now we get to the fifth argument. And this is the most, this is where it gets pretty complex. Okay, so the fifth argument against LOT is true is that it could cause all sorts of network instability. If it happens that the year is over and there are LOT is true clients on the network, it's possible that they would split off from the main chain and there could be reorgs and people could lose money and miners could mine invalid block and lose their block rewards and all that sort of stuff. But the LOT is true proponents argue that that risk is actually best mitigated if people adopt a LOT is true.

Sjors Provoost Yeah I'm very skeptical that sounds very circular but maybe it's useful to explain what these bad scenarios look like.

Aaron van Wirdum That's exactly where I wanted to get at.

Sjors Provoost Yeah, and then others can decide whether a they think those bad scenarios are worth risking and b whether they think you know how to make them less likely because some of that I think is almost political. It's kind of like, you know, you have all these discussions in society, like should people have guns or not? And, you know, what's the incentives? And you may never figure that out. But we can talk about some of the mechanics here.

Aaron van Wirdum Just to be clear, if somehow there would be complete consensus on the network over either LOT is true, all nodes run LOT is true, or all nodes run LOT is false, then I think that would be totally fine either way.

Sjors Provoost Yeah, but the irony, of course, is that if there's complete consensus and everybody runs LOT is true, then it will never be used. But you're right in theory.

Aaron van Wirdum Well, I mean, even if miners wouldn't...

Sjors Provoost I don't… I don't see a scenario where miners would say, yeah, we're happy with LOT is true. We're just not deliberately not going to signal and then signal at the very last moment.

Aaron van Wirdum Yeah, you're right. But we're also digressing. The point is that... the really complicated scenarios arise when some parts of the network are running LOT is true, some parts of the network are running LOT is false, or some parts of the network are running neither because they haven't upgraded, or some combination of these, you know, half of the network is true, half of the network is neither. That's where things get very complicated, and Sjors, you've thought about it. What do you think?

Sjors Provoost The nice thing is, I kind of thought about this stuff during the SegWit2x debacle as well as the UASF debacle, which were similar in a way, but also very different because of who was doing this [unclear] and whether it was a hard fork or a soft fork. But, okay, so let's say you are running the current version of Bitcoin Core. Now, let's start easier. Okay, let's say you're running the LOT is true version of Bitcoin Core. You downloaded it, and maybe it was released by Bitcoin Core, maybe you self-compiled it, but it says LOT is true. You want Taproot to activate. But the scenario here we're taking is that the rest of the world, the miners aren't really doing this. And the day arrives, and you see a block, and it's not signaling correctly. But you want it to signal correctly. So you say, this block is now invalid. I'm not going to accept this block. And I'm just going to wait until another miner comes with a block that does meet my criteria. And maybe that happens once in every 10 blocks, for example. So you are seeing new blocks, but they're coming in very, very slowly. Okay, so somebody sends you a transaction. You know, you won Bitcoin from somebody, they sent you a transaction. And this transaction has a fee, and it's probably going to be wrong. So let's say you're receiving a transaction from somebody who is running a node with LOT is false. So they're on a chain that is going 10 times faster than you are, right? This is intermediate state. Their blocks might be just full, so their fees are pretty low, and you're receiving it. But you're on this shorter, slower moving chain. So your mempool is really full and your blocks are completely full. So that transaction probably won't confirm on your side. It's just going to be sitting in the mempool. That's just one complexity. And that's actually a relatively good scenario because you don't accept unconfirmed transactions.

Aaron van Wirdum Yeah.

Sjors Provoost So you'll have a disagreement with your counterparty. You'll say, okay, it hasn't confirmed. And they'll say it has confirmed. Then at least you might realize what's going on. You know, you read about the LOT war or whatever. So that's one scenario. The other scenario is where somehow it does confirm on your side, but maybe it also confirms on the other side. So that's kind of good because then you're safe either way, right? If it's confirmed on both sides and whatever happens in a future reorg, that transaction is actually on the chain, just maybe in a different block.

Aaron van Wirdum Sure.

Sjors Provoost Another scenario could be because these blocks are these chains, there's two chains, one short chain, one long chain, but they're different. And so if you're receiving coins that are from the coinbase, that descend from a coinbase transaction on one side or the other, then there's no way it can be valid on your side.

Aaron van Wirdum Yeah.

Sjors Provoost And this can also be a feature. It's called replay protection, essentially. So you receive a transaction and you just don't even see it in your mempool and you call the other person and you say, this doesn't make any sense. So that's good. Okay. But now, suddenly, the world changes its mind and says, no, we do want Taproot, we do want LOT is true, we are now LOT is true diehards. And all the miners start mining on top of your shorter chain and your short chain becomes the very long chain. So in that case, you're pretty happy in most of the scenarios we discussed, right? The transaction…

Aaron van Wirdum Sounds good to me.

Sjors Provoost Right, you had a transaction that was in maybe your 10th block and on the other side it was in the first block, but it's still yours. There were some transactions floating in the mempool for a very long time that finally confirmed. I think you're… you're fairly happy, but I wonder if I was doing it right. Yeah, so we were talking about the LOT is true node, right? So… so yeah, as a LOT is true node user… It sounds like in these scenarios, you're happy.

Aaron van Wirdum Yep.

Sjors Provoost Maybe not if you're paying someone, but anyway.

Aaron van Wirdum You're starting to make the case for LOT is true Sjors, I know that's not your intention, but you're doing a good job at it.

Sjors Provoost For the full-node user who knows what they're doing in general, right? If you're a full-node user and you know what you're doing, then I think you're going to be fine in general. I think, yeah, this is not too bad. Now, let's say you are a LOT is false user, and let's say you… You just are, you know, you don't know what you're doing or you do know what you're doing. I don't know. Pick one. In the same scenario, you're on the longest chain. You're receiving coins from an exchange. And you've seen these headers out there for this shorter chain. You might have seen them. Depends on whether they reach you or not. But it's a shorter chain. And it's valid according to you because it's a more strict rule set. So you're fine. So this other chain has Taproot and you don't probably. And you're accepting transactions and you're a happy camper. But then all of a sudden, because the world changes, everything disappears from under you. All the transactions you've seen confirmed in the block are now back in the mempool. And it might have been double spent even.

Aaron van Wirdum Yeah, the reason for that is that even if you're running LOT is false, if the LOT is true chain, we're talking about the chain split that's happened… So if your LOT is false node… but at some point at any point the LOT is true chain becomes the longest chain then your LOT is false node would still accept that chain it would still consider it valid. Yeah, the other way around is not true. But the LOT is false node will always consider the LOT is true chain valid. So in your scenario, we're using Bitcoin on the longest chain, on the LOT is false chain. We're happy. We receive money. You know, we did a hard days of work and we got our paycheck at the end.

Sjors Provoost Yeah.

Aaron van Wirdum Paid in Bitcoin. We think we're safe. We got a bunch of confirmations. But then all of a sudden, the LOT is true chain becomes longer. Which means your node switches to the LOT is true chain and that money you received on the LOT is false chain, which you thought was the Bitcoin chain, is just gone. Poof.

Sjors Provoost Right.

Aaron van Wirdum That's the problem you're talking about.

Sjors Provoost Exactly. Now you could still say, okay.

Aaron van Wirdum I will… I will add to this very briefly. I think this is an even bigger problem for non-upgraded nodes.

Sjors Provoost Yeah, I was about to get to that.

Aaron van Wirdum Okay.

Sjors Provoost So, right. So now we're talking about the LOT is false people and you could still say, well, why did you download the LOT is false version? Well, because you didn't know. Okay. Now we're talking about an unupgraded node. Now, for the unupgraded node, Taproot does not exist. So it has no preference for which of the chains. It will just pick the longest one.

Aaron van Wirdum Yeah, it's someone in Korea. He doesn't keep up with discussion.

Sjors Provoost Well, let's not be mean to Korea.

Aaron van Wirdum No, well, pick a country where they don't speak English.

Sjors Provoost North Korea, yeah.

Aaron van Wirdum You know, someone doesn't keep up with their Bitcoin discussion forums, maybe doesn't read English, doesn't really care. He just likes the Bitcoin thing, downloaded the software a couple of years ago, now put in this hard days of work, gets paid, and the money disappears.

Sjors Provoost Yeah, or his node might be in a nuclear bunker that he put it in five years ago under 15 meters of concrete, air-gapped. And he can… he can put… he can give it, you know, and somehow it can download blocks because it's watching the block stream satellite or something, but it cannot be upgraded. And he doesn't know about this upgrade, which would be odd if you're into nuclear bunkers and full nodes. Anyway, somebody is running an out of… an out-of-date node but but you know, in Bitcoin, we have the policy, you don't have to upgrade. It's not a mandatory thing. So it should be safe, or at least relatively safe, to run an unupgraded node. And then, all of a sudden, you're receiving your salary as sort of the same as the LOT is false person. And then suddenly there's a giant reorg that just comes out of nowhere and you have no idea why people bother to reorg. Because you don't know about this rule change.

Aaron van Wirdum Yeah, you don't see the difference.

Sjors Provoost And poof, your salary just disappeared.

Aaron van Wirdum Yeah, that's bad. So that's basically the worst case scenario that no one wants, I think.

Sjors Provoost Yeah, and you can translate this also to, say, people who are using hardware wallet software that hasn't been updated or they're using remote nodes or they're using sort of SPV nodes that don't check the rules but only check the work and they'll have similar experiences where suddenly the longest chain changes so your SPV wallet which we explained in an earlier episode just its history disappears and At least for the, you know, for the lightweight nodes, you could say, you could do some victim shaming and say, well, you should be running a full node. And if bad things happen, then you should have run a full node. But I still don't think that's… that's good safety engineering. You know, to tell people like, okay, if you do not use your seatbelt in the correct position, the car might explode.

Aaron van Wirdum Yeah.

Sjors Provoost But at least for the unupgraded full node, that's an explicit case that I think Bitcoiners want to support. You want to support people not upgrading and not suddenly losing their coins in a situation like this.

Aaron van Wirdum Yes.

Sjors Provoost Well, that's kind of why I'm not a LOT [unclear]…

Aaron van Wirdum Yeah, well that's that's where I want to get at so then we everyone agrees or at least we both agree and I think most people would agree that this scenario we just painted that's horrible. We don't want that. So the next question is okay, how do you actually avoid this scenario and that's also one of the things where a LOT is true and a LOT is false people differ in their opinions. A LOT is false proponents like yourself argue against LOT is true because the chain split was caused by LOT is true and therefore if we don't want chain splits we don't want LOT is true and then the thing we just described won't happen. The worst case scenario is that we don't have Taproot. It will just expire and you know that's that's not as bad as this poor Korean guy losing his honest days of work.

Sjors Provoost Exactly and we might have Taproot later or you know…

Aaron van Wirdum Yeah now that LOT is true proponents will argue: Look, Bitcoin is an open network and anyone, you know, any peer can run any software they want. And for better or worse, LOT is true is a thing that exists. Now, if we want to avoid a chain split, the best way to avoid that is to make sure that everyone uses LOT is true or at least that the majority of miners upgrade in time and LOT is true is the best way to ensure that. So getting critical mass for LOT is true is actually the safer option despite the fact that LOT is true also introduced the risk. If I want to give an analogy, it's kind of like you know the world would be a safer place without nuclear weapons, but there are nuclear weapons and it seems like it's safer to actually have one in that case.

Sjors Provoost I think that analogy breaks down very quickly but yeah I I get the idea.

Aaron van Wirdum But the the point is that you know it's not a perfect analogy I'm sure. The point is LOT is true exists and now we have to deal with that. It might be a better world. It might be a safer place if LOT is true didn't exist, if UASF didn't exist. But it does. And now we have to sort of deal with that fact.

Sjors Provoost I'm always…

Aaron van Wirdum And there's an argument to be made that making sure the software succeeds is actually the best way to go to save that poor Korean guy.

Sjors Provoost Yeah, I'm always very skeptical of this type of game theory because it sounds rhetorically nice, but I'm not sure if it's really true. And one of the obvious problems is how do you know you've reached the entire Bitcoin community? Because like we talked about, this hypothetical person in this other country that's not reading Twitter and Reddit, it has no idea that this is going on. You know, let alone most of the lightweight wallet users. The number of people who use Bitcoin is much, much greater than the number of people who are even remotely interested in these discussions. And also to even explain the risk to those people, even if we could reach them, to explain why they should upgrade, that alone is a rather big challenge because, you know, in this episode, we roughly try to explain what would go wrong if they don't upgrade. And we can't just tell them you must upgrade because that sort of violates the... you know, the idea that you persuade people with arguments and let them decide what they want to do rather than tell them based on authority.

Aaron van Wirdum Well, keep in mind that in the end, all of this is avoided if a majority of hash power upgrades. And with LOT is true, it actually is any majority would be fine in the end because if miners themselves use LOT is true, then they'll definitely get the longest chain once by the end of the year.

Sjors Provoost Yeah, so the game theory is kind of narrow to saying, well, you want to convince the miners to do this.

Aaron van Wirdum Yeah, pretty much.

Sjors Provoost The problem, though, is if it fails, we just explain the disaster that happens. So then the question is, what is that risk? Can you put a percentage on that? Can you somehow simulate the world and find out what happens?

Aaron van Wirdum No, look I'm kind of on the fence on this. I see compelling arguments on both sides. I was leaning towards LOT is false at first but the more I think about it… I… you know, the argument is if you include LOT is true in Bitcoin Core then that practically guarantees that everything will be fine because the economic majority will almost certainly run it, you know, exchanges and most users.

Sjors Provoost I'm not even sure that's true because that assumes that this economic majority is quick to upgrade and not sort of ignoring things.

Aaron van Wirdum At least within a year.

Sjors Provoost I don't know, there might be companies that are running three or four-year-old nodes because they have 16 different shitcoins. So even that, I would not assume that, you know, we know from the network in general that lots of people don't upgrade nodes. And that one year is pretty short, and then… yes, but you can't tell from the nodes whether they're the economic majority or not. That might just you know be a few critical players that would do the trick here.

Aaron van Wirdum Yes, I I can't be sure. I'm not sure. I'm you know speculating, I'm explaining the argument, but the opposite is also true that now that LOT is true exist some group of users will almost certainly run it and that introduces you know maybe greater risks than if it was included in Core, because that would increase the chances of success for, you know, a LOT is true, basically, or the majority upgrading.

Sjors Provoost Yeah, it really depends on who that group is. Because if that group is just some random people who are not economically important, then, you know, they're experiencing the problems and nobody else notices anything.

Aaron van Wirdum Yeah, so that's true. If it's a very small group, that might be true. But the question is how small or how big does that group need to be for this to become a problem?

Sjors Provoost Yeah.

Aaron van Wirdum And because they have a very, they have an asymmetric, is that the correct English word?

Sjors Provoost Yeah.

Aaron van Wirdum Asymmetric advantage.

Sjors Provoost There's an asymmetry there.

Aaron van Wirdum Asymmetry, yeah. They have this advantage because their chain can never be reorged away. Or the LOT is false chain, so to say, can be reorged away.

Sjors Provoost That's true, but their chain might never grow. So that's also a risk. So I don't know if it's a it's not a complete advantage, it's not a strict advantage, right?

Aaron van Wirdum I think it's definitely a strict advantage.

Sjors Provoost Well, I mean, the advantage is you can't be re-orged. The disadvantage is your chain might never grow. And I don't know which of those two is…

Aaron van Wirdum It will probably grow, right? It depends on how big that group is again. And that's not something we can objectively measure.

Sjors Provoost No.

Aaron van Wirdum And I guess that's sort of what it comes down to.

Sjors Provoost And even retroactively we can't, right? We still don't know what really caused the SegWit activation, even four years afterwards. So that gives you an idea of how difficult it is to know what these forces really are.

Aaron van Wirdum Yes. Well, so that's where we agree. I think it's very difficult to know either way.

Sjors Provoost Yeah. So, you know, from the...

Aaron van Wirdum So I'm sort of on the fence about it. Not even, there might still be a LOT is true minority that, or, you know, maybe even a majority, you know, that might still happen.

Sjors Provoost Yeah.

Aaron van Wirdum So...

Sjors Provoost Another interesting thought experiment then is to say, well, okay, so there's always going to be a LOT is true group for any soft fork. But what about a soft fork that has no community support? What about a... Some arbitrary group of people just decides to run their own soft fork because they want to. Maybe somebody wants to shrink the coin supply. You know, set the coin issuance to zero tomorrow or reduce the block size to 300 kilobytes. And they could say, well, because it's a soft fork and because I run a LOT is true node, there could be others who run a LOT is true node. Therefore, it must activate and everybody should run this node. So that would be absurd. So it's clear that there is a limit to this game theory. You can always think of some soft fork and some small community that will just say this and just completely fail so we come back to you have to estimate how big and how powerful this thing is and I don't even know what the metric is.

Aaron van Wirdum Yes, but also how harmful the upgrade is because that's I would say that's sort of the answer to your point there that if the upgrade itself is considered valuable, then there's very little cost for people to just switch to the other chain you know the chain that can't be reorged and that has to upgrade that's valuable that's a pretty good reason to actually switch while switching to a chain even if it can't be reorged that you know screws with the coin limit or that kind of stuff, that's much bigger disincentive, also a bigger disincentive for miners to switch.

Sjors Provoost But some people might say that a you know maybe a smaller coin so a smaller block size is safer.

Aaron van Wirdum Well, they are free to fork off. That's also possible. You know, it is possible even, we didn't even discuss that, but it is possible that the chain split is lasting, that it will just forever be a LOT is true minority chain and a LOT is false majority chain. Now we have, you know, like the Bitcoin-Bitcoin Cash split or something like that. We just have two coins.

Sjors Provoost With the big, scary, like, [unclear] of Damocles hanging above it.

Aaron van Wirdum Yeah. Unless maybe a checkpoint would have to be included in the majority chain, which would be very ugly.

Sjors Provoost You could come up with some sort of incompatible software to prevent the reorg in the future.

Aaron van Wirdum Okay, sure. So let's work towards the end of this episode.

Sjors Provoost Yeah, I think we've covered a lot of different arguments and explained that this is pretty complicated.

Aaron van Wirdum Yeah, I want to... What do you think is going to happen? That's sort of my last question. How do you anticipate this playing out?

Sjors Provoost Well, I started looking a little bit at the nitty-gritty, for example, today at one of the pull requests that Luke Dashjr opened to implement BIP 8 in general. Not specifically for Taproot, I believe. And there's already complexities with this LOT is true thing engaged because you need to think about how how the peer-to-peer network should behave and so from a principle of least action like what is the least work for developers to do, removing basically setting LOT to false probably results in an easier code which will get merged earlier. And even if Luke is like, well, I will only do this if it's set to true, then somebody else will make a pull request that sets it to false and gets merged earlier. So I think for me, just a what happens when lazy people, and I mean lazy in the most respectful way, but just what is the path of least resistance? It's probably a LOT is false, just from an engineering point of view.

Aaron van Wirdum Yeah, so LOT is false in Bitcoin Core is what you would expect in that case.

Sjors Provoost Yes, and then somebody else would implement LOT is true. And that might have…

Aaron van Wirdum And some alt client for sure.

Sjors Provoost Yeah, and that might have no code review.

Aaron van Wirdum But I mean, it's just a parameter setting, right?

Sjors Provoost No, no, no, it's more complicated… because of the…

Aaron van Wirdum A little bit more, yeah, you're right.

Sjors Provoost Exactly, because of how it's going to interact with its peers and what it's going to do when there's a chain split etc. So yeah.

Aaron van Wirdum Yeah, what do you think about the scenario that neither is implemented in Bitcoin Core? Do you see that happening? Because, you know...

Sjors Provoost Neither?

Aaron van Wirdum Yeah, neither…

Sjors Provoost A LOT is null? Or...

Aaron van Wirdum Just no activation mechanism because there's no consensus for one.

Sjors Provoost No, I think... No, I think they'll be fine.

Aaron van Wirdum Yeah.

Sjors Provoost I mean, I [unclear] predict the future, but my guess is that a LOT is false, will… won't be objected to as much as some people might think.

Aaron van Wirdum All right. Well, we'll see then, I guess.

Sjors Provoost Yeah, we'll see. This might be the dumbest thing we've ever said. Thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.