Taproot activation and LOT=true vs LOT=false
Speakers: Sjors Provoost, Aaron van Wirdum
Date: February 26, 2021
Transcript By: Michael Folkson
Tags: Taproot, Soft fork activation
Media: https://www.youtube.com/watch?v=7ouVGgE75zg
BIP 8: https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki
Arguments for LOT=true and LOT=false (T1-T6 and F1-F6): https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
Additional argument for LOT=false (F7): https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
Aaron van Wirdum article on LOT=true or LOT=false: https://bitcoinmagazine.com/articles/lottrue-or-lotfalse-this-is-the-last-hurdle-before-taproot-activation
Intro
Aaron van Wirdum (AvW): Live from Utrecht, this is the van Wirdum Sjorsnado. Sjors, make the pun.
Sjors Provoost (SP): We have a “lot” to talk about.
AvW: We have a “lot” to discuss. In this episode we are going to discuss the Taproot activation process and the debate surrounding it on the parameter lot, lockinontimeout which can be set to true and false.
SP: Maybe as a reminder to the listener we have talked about Taproot in general multiple times but especially in Episode 2. And we have talked about activating Taproot, activating soft forks in general in Episode 3 so we might skip over a few things.
AvW: In Episode 3 we discussed all sorts of different proposals to activate Taproot but it has been over half a year at least right?
SP: That was on September 25th so about 5 months, yeah.
AvW: It has been a while and by now the discussion has reached its final stage I would say. 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 a soft fork?
What is a soft fork?
SP: The idea of a soft fork is you make the rules more strict. That means that from the point of view of a node that doesn’t upgrade nothing has changed. They are just seeing transactions that are valid to them from the nodes that do upgrade. Because they have stricter rules they do care about what happens. 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.
AvW: A soft fork is a backwards compatible protocol upgrade and the nice thing about it is that if a majority of miners enforce the rules then that automatically means all nodes on the network will follow the same blockchain.
SP: That’s right. 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 is valid. 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 an old node will by definition follow that.
AvW: The nice thing about soft forks is that if a majority of hashpower 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. Once most miners, 95 percent in most cases, indicated that they were ready nodes would recognize this and enforce the upgrade.
SP: That’s right. A node would check, for example every two weeks, how many blocks signaled this thing and if yes, then it says “Ok the soft fork is now active. I am going to assume that the miners will enforce this.”
The ability for miners to block a soft fork upgrade
AvW: Right. The problem with this upgrade mechanism is that it also means miners can block the upgrade.
SP: Yeah that’s the downside.
AvW: Even if everyone agrees with the upgrade, 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.
SP: Back then there was a lot of debate about the block size and lots of hard fork proposals and lots of hurt feelings. 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.
AvW: Yeah. In the case of SegWit that was in the end resolved through UASF, or at least that was part of it. We are not going to get into that in depth. That basically meant that a group of users said “On this day (some date in the future, it was August 1st 2017) we are going to activate the SegWit rules no matter how much hash power supports it.”
SP: Right, at the same time and perhaps as a consequence as that, a group of miners and other companies agreed that they would start signaling for SegWit. There were a whole bunch of other things going on at the same time. Whatever happened on 1st August, the thing activated, or a little bit earlier I think.
The lockinontimeout (LOT) parameter
AvW: Now we are four years ahead in time, it is four years later and now the Taproot upgrade is ready to go. What happened a couple of years ago is now spurring new debate on the Taproot upgrade. That brings us to the lockinontimeout (LOT) parameter which is a new parameter. Although it is inspired by things from that SegWit upgrade period.
SP: It is basically a built in UASF option which you can decide to use or not. There is now a formal way in the protocol to do this to activate a soft fork at a cut off date.
AvW: LOT has two options. The first option is false, LOT is false. That means that miners can signal for the upgrade for one year and then in that year if the 90 percent threshold for the upgrade is met it will activate as we just explained. By the way 1 year and 90 percent isn’t set in stone but it is what people seem to settle on. For convenience sake that is what I’m going to use for discussing this. Miners have 1 year to activate the upgrade. If after that year they have not upgraded the Taproot upgrade will expire. It will just not happen, that is LOT is false.
SP: And of course there is always the option then of shipping a new release, trying again. It is not a “no” vote, it is just nothing happens.
AvW: Exactly. Then there is LOT=true which again miners have 1 year to signal support (readiness) for the upgrade. If a 90 percent 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=true will start to reject all blocks that don’t signal for the upgrade. In other words they will only accept blocks that will signal for the upgrade which means of course that the 90 percent threshold will be met and therefore Taproot, or any other soft fork in this mechanism, will activate.
SP: If enough blocks are produced.
AvW: If enough blocks are produced, yes, that’s true. A little bit of nuance for those who find it interesting, even LOT=true nodes will accept up to 10 percent of blocks that don’t signal. That’s to avoid weird chain split scenarios.
SP: Yeah. If it activates in the normal way only 90 percent has to signal. If you mandate signaling then it would be weird to have a different percentage suddenly.
AvW: They are going to accept the first 10 percent of non-signaling blocks but after that every block that doesn’t signal is going to be rejected. So the 90 percent threshold will definitely be reached. The big reason for LOT=-true, 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 is guaranteed to happen.
SP: If enough blocks are produced. We can get into some of the risks with this but I think you want to continue explaining a bit.
AvW: The reason some people like LOT=true is because that way miners don’t have a veto. The counterargument there, you already suggested that, is that miners don’t have a veto anyway even if we use LOT=false the upgrade will expire after a year but after that year we can just deploy a new upgrade mechanism and a new signaling period. This time maybe use LOT=true.
SP: Or even while this thing is going on. You could wait half a year with LOT=false and half a year later say “This is taking too long. Let’s take a little more risk and set LOT=true.” Or lower the threshold or some other permutation that slightly increases the risk but also increases the likeliness of activation.
AvW: Yeah, you’re right. But that is actually also one of the arguments against using LOT=false. LOT=true proponents say that as you’ve suggested we can do it after 6 months, but there are another group of users that might say “No. First wait until the year is over and then we will just redeploy again.” Let’s say after 6 months Taproot hasn’t activated. Now all of a sudden you get a new discussion between people that want to start deploying LOT=true clients right away and groups of users that want to wait until the year is over. It is reintroducing the discussion we are having now except by then we only have 6 months to resolve it. It is like a ticking time bomb kind of situation.
SP: Not really to resolve it. If you don’t do anything for 6 months then there is only one option left which is to try again with a new activation bit.
AvW: But then you need to agree on when you are going to do that. Are you going to do that after 6 months or are you going to do that later? People might disagree.
SP: Then you’d be back to where we are now except you’d know a little bit more because now you know that the miners weren’t signaling.
AvW: And you don’t have a lot of time to resolve it because after 6 months might happen. Some group of users might run LOT=true or….
SP: The thing you’re talking about here is the possibility of say anarchy in the sense that there is no consensus about when to activate this thing. One group, I think we discussed this at length in the third episode, just gets really aggressive and says “No we are going to activate this earlier.” Then nobody knows when it is going to happen.
AvW: Let me put it differently. If right now we are saying “If after 6 months miners haven’t activated Taproot then we will just upgrade to LOT=true clients” then LOT=true proponents will say “If that’s the plan anyways let’s just do it now. That’s much easier. Why do we have to do that halfway?” That is the counterargument to the counterargument.
SP: I can see that. But of course there is also the scenario where we never do this, Taproot just doesn’t activate. It depends on what people want. There is something to be said for a status quo bias where you don’t do anything if it is too controversial for whatever reason. There is another side case here that is useful to keep in mind. There might be a very good reason to cancel Taproot. There might be a bug that is revealed after.
AvW: You are getting ahead of me. There are a bunch of arguments in favor of LOT=false. One argument is we’ve already done LOT=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, we don’t have a big war now. There is no reason to change what we’ve been doing successfully until now. That is one argument. The counterargument would for example be “Yeah but if you choose LOT=false now that could draw controversy itself. It could be used to drive a wedge. We are not in a war right now but it could cause a war.”
SP: I don’t see how that argument doesn’t apply to LOT=true. Anything could cause controversy.
AvW: That is probably fair. I tend to agree with that. The other argument for LOT=false is that miners and especially mining pools have already indicated that they are supportive of Taproot, they’ll activate it. It is not necessary to do the LOT=true thing as far as we can tell. The third argument is what you just mentioned. It is possible that someone finds a bug with Taproot, a software bug or some other problem is possible. If you do LOT=false it is fairly easy to just let it expire and users won’t have to upgrade their software again.
SP: The only thing there is that you’d have to recommend that miners do not install that upgrade. It is worth noting, I think we pointed this out in Episode 3, people don’t always review things very early. 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. It is not implausible that someone very smart starts reviewing this very late, perhaps some exchange that is about to deploy it.
AvW: Something like that happened with P2SH, the predecessor to P2SH. OP_EVAL was just about to be deployed and then a pretty horrible bug was found.
SP: We’ve seen it with certain altcoins too, right before deployment people find zero days, either because they were… or just because the code was shipped in a rush and nobody checked it. There is definitely always a risk, whatever soft fork mechanism you use, that a bug is discovered at the last minute. If you are really unlucky then it is too late, it is deployed and you need a hard fork to get rid of it which would be really, really bad.
AvW: I don’t think that’s true. There are other ways to get rid of it.
SP: Depending on what the bug is you may be able to soft fork it out.
AvW: There are ways to fix it even in that case. The other counterargument to that point would be “If we are not sure that it is bug free and we are not sure that this upgrade is correct then it shouldn’t be deployed either way, LOT=true or LOT=false or anything. We need to be sure of that anyway.”
SP: Yeah but like I said some people won’t review something until it is inevitable.
AvW: I am just listing the arguments. Fourth argument against LOT=true is that LOT=true could feed into the perception that Bitcoin and especially Bitcoin Core developers control the protocol, have power of the protocol. They are shipping code and that necessarily becomes the new protocol rules in the case of Taproot.
SP: There could be some future soft fork where really nobody in the community cares about it, just a handful of Bitcoin Core developers do, and they force it onto the community. Then you get a bunch of chaos. The nice thing about having at least the miners signal is that they are part of the community and at least they are ok with it. The problem is it doesn’t reflect what other people in the community think about it. It just reflects what they think about it. There are a bunch of mechanisms. There is discussion on the mailing list, you see if people have problems. Then there is miner signaling which is a nice indication that people are happy. You get to see that, there are as many people consenting as possible. It would be nice if there were other mechanisms of course.
AvW: The other point that Bitcoin Core developers, while they decide which code they include in Bitcoin Core they don’t decide what users actually end up running.
SP: Nobody might download it.
AvW: Exactly. They don’t actually have power over the network. In that sense the argument is bunk but it could still feed into the perception that they do. Even that perception, if you can avoid it maybe that’s better. That is an argument.
SP: And the precedent. What if Bitcoin Core is compromised at some point and ships an update and says “If you don’t stop it then it is going to activate.” Then it is nice if the miners can say “No I don’t think so.”
AvW: Users could say that as well by not downloading it like you said. Now we get to the fifth argument. This is where it gets pretty complex. The fifth argument against LOT=true is that it could cause all sorts of network instability. If it happens that the year is over and there are LOT=true clients on the network it is possible that they would split off from the main chain and there could be re-orgs. People could lose money and miners could mine an invalid block and lose their block reward and all that sort of stuff. The LOT=true proponents argue that that risk is actually best mitigated if people adopt LOT=true.
SP: I’m skeptical, that sounds very circular. Maybe it is useful to explain what these bad scenarios look like? Then others can decide whether a) they think those bad scenarios are worth risking and b) how to make them less likely. Some of that is almost political. You all have these discussions in society, should people have guns or not, what are the incentives, you may never figure that out. But we can talk about some of the mechanics here.
AvW: To be clear, if somehow there would be complete consensus on the network over either LOT=true, all nodes run LOT=true, or all nodes run LOT=false then I think that would be totally fine. Either way.
SP: Yeah. The irony is of course that if there is complete consensus and everybody runs LOT=true then it will never be used. You’re right in theory. I don’t see a scenario where miners would say “We are happy with LOT=true but we are deliberately not going to signal and then signal at the very last moment.”
AvW: You are right but we are digressing. The point is that the really complicated scenarios arise when some parts of the network are running LOT=true, some parts of the network are running LOT=false or some parts of the network are running neither because they haven’t upgraded. Or some combination of these, half of the network has LOT=true, half of the network has neither. That’s where things get very complicated and Sjors, you’ve thought about it, what do you think? Tell me what the risks are.
The chain split scenario
SP: I 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 explaining and whether it was a hard fork or a soft fork. Let’s say you are running the LOT=true version of Bitcoin Core. You downloaded it, maybe it was released by Bitcoin Core or maybe you self compiled it, but it says LOT=true. You want Taproot to activate. But the scenario here is that the rest of the world, the miners aren’t really doing this. The day arrives and you see a block, it is not signaling correctly but you want it to signal correctly so you say “This block is now invalid. I am not going to accept this block.” I’m just going to wait until another miner comes with a block that does meet my criteria. Maybe that happens once in every 10 blocks for example. You are seeing new blocks but they are coming in very, very slowly. So somebody sends you a transaction, you want Bitcoin from somebody, they send you a transaction and this transaction has a fee and it is probably going to be wrong. Let’s say you are receiving a transaction from somebody who is running a node with LOT=false. They are on a chain that is going ten times faster than you are, in this intermediate state. Their blocks might be just full, their fees are pretty low, and you are receiving it. But you are 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 is just going to be sitting in the mempool, that is one complexity. That’s actually a relatively good scenario because you don’t accept unconfirmed transactions. You will have a disagreement with your counterparty, you’ll say “It hasn’t confirmed” and they’ll say “It has confirmed”. Then at least you might realize what is going on, 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 and it also confirms on the other side. That is kind of good because then you are safe either way. If it is confirmed on both sides then whatever happens in a future re-org that transaction is actually on the chain, maybe in a different block. Another scenario could be because there are two chains, one short chain and one long chain, but they are different. If you are receiving coins that are sent from a coinbase transaction on one side or the other then there is no way it can be valid on your side. This can also be a feature, it is called replay protection essentially. You receive a transaction and you don’t even see it in your mempool, you call the other person and say “This doesn’t make any sense.” That’s good. But now suddenly the world changes its mind and says “No we do want Taproot, we do want LOT=true, we are now LOT=true diehards” and all the miners start mining on top of your shorter chain. Your short chain becomes the very long chain. In that case you are pretty happy in most of the scenarios we’ve discussed.
AvW: Sounds good to me.
SP: You had a transaction that was in maybe in your tenth block and on the other side it was in the first block. It is still yours. There were some transactions floating in the mempool for a very long time, they finally confirm. I think you are fairly happy. We were talking about the LOT=true node. As a LOT=true node user, in these scenarios you are happy. Maybe not if you’re paying someone.
AvW: You are starting to make the case for LOT=true Sjors, I know that is not your intention but you are doing a good job at it.
SP: For the full node user who knows what they are doing in general. If you are a full node user and you know what you are doing then I think you are going to be fine in general. This is not too bad. Now let’s say you are a LOT=false user and let’s say you don’t know what you are doing. In the same scenario you are on the longest chain, you are 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 is a shorter chain and it is valid according to you because it is a more strict ruleset. You are fine, this other chain has Taproot and you don’t probably. You are accepting transactions and you are 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 a block are now back in the mempool and they might have been double spent even.
AvW: Yeah the reason for that is that we are talking about a chain split that has happened. You have a LOT=false node but at any point the LOT=true chain becomes the longest chain then your LOT=false node would still accept that chain. It would still consider it valid. The other way round is not true. But the LOT=false node will always consider the LOT=true chain valid. So in your scenario where you are using Bitcoin on the longest chain, on the LOT=false chain, we’re happy, we received money, we did a hard day’s work and got our paycheck at the end, paid in Bitcoin. We think we’re safe, we got a bunch of confirmations but then all of a sudden the LOT=true chain becomes longer which means your node switches to a LOT=true chain. That money you received on the LOT=false chain which you thought was the Bitcoin chain is just gone. Poof. That is the problem you are talking about.
SP: Exactly.
AvW: I will add to this very briefly. I think this is an even bigger problem for non-upgraded nodes.
SP: I was about to get to that. Now we are talking about the LOT=false people. You could still say “Why did you download the LOT=false version?” Because you didn’t know. Now we are talking about an unupgraded node. 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.
AvW: It is someone in Korea, he doesn’t keep up with discussion.
SP: Let’s not be mean to Korea.
AvW: Pick a country where they don’t speak English.
SP: North Korea.
AvW: Someone doesn’t keep up with their Bitcoin discussion forums, maybe doesn’t read English, doesn’t really care. He just likes this Bitcoin thing, downloaded the software a couple of years ago, put in his hard day’s work, gets paid and the money disappears.
SP: Or his node might be in a nuclear bunker that he put it in 5 years ago under 15 meters of concrete, airgapped, and somehow it can download blocks because it is watching the Blockstream satellite or something but it cannot be upgraded. And he doesn’t know about this upgrade. Which would be odd if you are into nuclear bunkers and full nodes. Anyway somebody is running an out of date node, in Bitcoin we have the policy that you don’t have to upgrade, it is not a mandatory thing. It should be safe or at least relatively safe to run an unupgraded node. You are receiving a salary, the same as the LOT=false person, then suddenly there’s a giant re-org that comes out of nowhere. You have no idea why people bother to re-org because you don’t know about this rule change.
AvW: You don’t see the difference.
SP: And poof your salary just disappeared.
AvW: That’s bad. That’s basically the worst case scenario that no one wants I think.
SP: Yeah. You can translate this also to people who are using hardware wallet software that hasn’t been updated, they are using remote nodes or they are using SPV nodes that don’t check the rules but only check the work. They’ll have similar experiences where suddenly the longest chain changes so your SPV wallet, which we explained in an earlier episode, its history disappears. At least for the lightweight nodes you could do some victim shaming and say “You should be running a full node. If bad things happen you should have run a full node.” But I still don’t think that’s good safety engineering, to tell people “If you don’t use your safety belt in the correct position the car might explode.” But at least for the unupgraded full node that is an explicit case that Bitcoiners want to support. You want to support people not upgrading and not suddenly losing their coins in a situation like this. That is why I’m not a LOT=true person.
Avoiding a chain split scenario
AvW: That’s what I want to get that. 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 how do you avoid this scenario? That’s also one of the things where LOT=true and LOT=false people differ in their opinions. LOT=false proponents like yourself argue against LOT=true because the chain split was caused by LOT=true and therefore if we don’t want chain splits we don’t want LOT=true and the thing we just described won’t happened. The worst case scenario is that we don’t have Taproot, it will just expire. That’s not as bad as this poor Korean guy losing his honest day’s work.
SP: Exactly and we might have Taproot later.
AvW: The LOT=true proponents will argue Bitcoin is an open network and any peer can run any software they want. For better or worse LOT=true is a thing that exists. If we want to avoid a chain split the best way to avoid that is to make sure that everyone uses LOT=true or at least the majority of miners upgrade in time and LOT=true is the best way to ensure that. Getting critical mass for LOT=true is actually the safer option despite the fact that LOT=true also introduced the risk. If I want to give an analogy it is kind of like the world would be a safer place without nuclear weapons but there are nuclear weapons. It seems like it is safer to actually have one in that case.
SP: I think that analogy breaks down very quickly but yeah I get the idea.
AvW: It is not a perfect analogy I’m sure. The point is LOT=true exists and now we have to deal with that. It might be a better world, a safer place if LOT=true didn’t exist, if UASFs didn’t exist. But it does and now we have to deal with that fact. There is an argument to be made that making sure the soft fork succeeds is actually the best way to go to save that poor Korean guy.
SP: I am always very skeptical of this type of game theory because it sounds rhetorically nice but I’m not sure it is really true. One of the obvious problems is how do you know you’ve reached the entire Bitcoin community. We talked about this hypothetical person in this other country who is not reading Twitter and Reddit, has no idea that this is going on 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. 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. In this episode we roughly try to explain what would go wrong if they don’t upgrade. We can’t just tell them they must upgrade. That violates the idea that you persuade people with arguments and let them decide what they want to do rather than tell them based on authority.
AvW: Keep in mind that in the end all of this is avoided if a majority of hash power upgrades. With LOT=true it actually is any majority would be fine in the end. If miners themselves use LOT=true then they’ll definitely get the longest chain by the end of the year.
SP: The game theory is kind of narrowed to say you want to convince the miners to do this. The problem though is if it fails we just explained the disaster that happens. 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?
AvW: I am on the fence on this. I see compelling arguments on both sides. I was leaning towards lot=false at first but the more I think about it… The argument is if you include lot=true in Bitcoin Core then that practically guarantees that everything will be fine because the economic majority will almost certainly run it. Exchanges and most users.
SP: I’m not even sure that is true. That assumes that this economic majority is quick to upgrade and not ignoring things.
AvW: At least within a year.
SP: There might be companies that are running 3 or 4 year old nodes because they have 16 different s***coins. Even that, I would not assume that. We know from the network in general that lots of people don’t upgrade nodes and one year is pretty short. You can’t tell from the nodes whether they are the economic majority or not. That might be a few critical players that would do the trick here.
AvW: Yes I can’t be sure. I’m not sure. I am speculating, I am explaining the argument. But the opposite is also true, now that lot=true exists some group of users will almost certainly run it and that introduces maybe greater risks than if it was included in Core. That would increase the chances of success for LOT=true, the majority upgrading.
SP: It really depends on who that group is. Because if that group is just some random people who are not economically important then they are experiencing the problems and nobody else notices anything.
AvW: That is true. If it is 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. They have an asymmetry, this advantage because their chain can never be re-orged away while the LOT=false chain can be re-orged away.
SP: But their chain may never grow so that’s also a risk. It is not a strict advantage.
AvW: I think it is definitely a strict advantage.
SP: The advantage is you can’t be re-orged. The disadvantage is your chain might never grow. I don’t know which of those two…
AvW: It would probably grow. It depends on how big that group is again. That’s not something we can objectively measure. I guess that’s what it comes down to.
SP: Even retroactively we can’t. We still don’t know what really caused the SegWit activation even four years afterwards. That gives you an idea of how difficult it is to know what these forces really are.
AvW: Yes, that’s where we agree. It is very difficult to know either way. I am on the fence about it.
SP: The safest thing to do is to do nothing.
AvW: Not even that. There might still be a LOT=true minority or maybe even majority that might still happen.
SP: Another interesting thought experiment then is to say “There is always going to be a LOT=true group for any soft fork. What about a soft fork that has no community support? What if an arbitrary group of people decides to run their own soft fork because they want to? Maybe someone wants to shrink the coin supply. Set the coin issuance to zero tomorrow or reduce the block size to 300 kilobytes.” They could say “Because it is a soft fork and because I run a LOT=true node, there could be others who run a LOT=true. Therefore it must activate and everybody should run this node.” That would be absurd. There is a limit to this game theory. You can always think of some soft fork and some small community that will say this and completely fail. You have to estimate how big and how powerful this thing is. I don’t even know what the metric is.
AvW: But also how harmful the upgrade is because I would say that is the answer to your point there. If the upgrade itself is considered valuable then there is very little cost for people to just switch to the other chain, the chain that can’t be re-orged and that has the upgrade that is valuable. That’s a pretty good reason to actually switch. While switching to a chain even if it can’t be re-orged that screws with the coin limit or that kind of stuff, that is a much bigger disincentive and also a disincentive for miners to switch.
SP: Some people might say that a smaller block size is safer.
AvW: They are free to fork off, that is also possible. We didn’t even discuss that but it is possible that the chain split is lasting, that it will forever be a LOT=true minority chain and a LOT=false majority chain. Then we have the Bitcoin, Bitcoin Cash split or something like that. We just have two coins.
SP: With the big scary sword of Damocles hanging above it.
AvW: Then maybe a checkpoint would have to be included in the majority chain which would be very ugly.
SP: You could come up with some sort of incompatible soft fork to prevent a re-org in the future.
AvW: Let’s work towards the end of this episode.
SP: I think we have covered a lot of different arguments and explained that this is pretty complicated.
AvW: What do you think is going to happen? How do you anticipate this playing out?
SP: I started looking a little bit at the nitty gritty, one of the pull requests that Luke Dashjr opened to implement BIP 8 in general, not specifically for Taproot I believe. There’s already complexity with this LOT=true thing engaged because you need to think about how the peer-to-peer network should behave. From a principle of least action, what is the least work for developers to do, setting LOT to false probably results in easier code which will get merged earlier. And even if Luke is like “I will only do this if it is set to true” then somebody else will make a pull request that sets it to false and gets merged earlier. I think from a what happens when lazy people, I mean lazy in the most respectful way, what is the path of least resistance? It is probably a LOT=false, just from an engineering point of view.
AvW: So LOT=false in Bitcoin Core is what you would expect in that case.
SP: Yes. And somebody else would implement LOT=true.
AvW: In some alt client for sure.
SP: Yeah. And that might have no code review.
AvW: It is just a parameter setting right?
SP: No it is more complicated because how it is going to interact with its peers and what it is going to do when there’s a chain split etc.
AvW: What do you think about this scenario that neither is implemented in Bitcoin Core? Do you see that happening?
SP: Neither. LOT=null?
AvW: Just no activation mechanism because there is no consensus for one.
SP: No I think it will be fine. I can’t predict the future but my guess is that a LOT=false won’t be objected to as much as some people might think.
AvW: We’ll see then I guess.
SP: Yeah we’ll see. This might be the dumbest thing I’ve ever said.