 It's worked exactly as intended, and it has allowed Ethereum to continue to introduce new features, even features the miners don't want by forcing them into a situation where they have to accept the hard fork that's offered to them. Hey, folks. I'm Adam B. Levine, and this is Speaking of Bitcoin. A couple of weeks ago, the Ethereum network adopted its latest and long series of backwards incompatible upgrades known as hard forks. The London hard fork introduced among other things, a pretty substantial rethink about how miners are rewarded and what happens to the fees you pay. But that's not what we're talking about here today. It actually just got me thinking, and it's a topic that we like to revisit from time to time, whether we'll really ever see that sort of protocol level, fundamental change to the incentives governing Bitcoin, the first cryptocurrency, ever again. So we're going to talk about it. To do that, I'm joined as always by the other host of the show, Jonathan Mohan, and Andreas M. Antonopoulos. Hello. Money is off this week. So we saw the taproot upgrade go into effect, but that was not a backwards incompatible upgrade. It was what we call a soft fork. And in kind of Bitcoin's recent history, the soft fork really is how we have made these improvements. And it has some positives, which is that there's really no possibility of creating two versions of the network, one network which agrees with the new change and one network which doesn't agree with the new change and is still on the old software. The downside is that when it comes to adoption of those changes, then it can sometimes take a really long time because nobody has to adopt any of the stuff. It just becomes kind of a new additional option. So using that as a starting point, maybe Andreas, you want to kind of walk us through the differences in a tangible sense between a hard fork and a soft fork for the purposes of this type of like ossification conversation? I think the easiest way to think about it is a soft fork is a change that reduces the rules or makes them narrower. And a hard fork is a change that widens the rules. Let's put it this way. If you run a vegetarian restaurant and you turn your restaurant into a vegan restaurant, that's a soft fork because the rules got narrower. Fewer things are now allowed on the menu than before. The fact is that because the rules got narrower, all of your vegetarian customers can quite happily still eat at your restaurant because so it's vegan. Yeah, they might not get what they want, but nothing's going to cause them any problem with their digestion or eating. If, on the other hand, you add pork to the menu, the rules have now gotten wider, you are no longer vegetarian. And you may end up in a situation where all of your customers who came to your restaurant specifically for vegetarian food can't come anymore. But the customers who were okay with pork but just liked vegetarian food can still continue to come to your restaurant. And then you end up essentially with a situation where it's a fork. Your clientele split. So this is really the difference. And it means that soft forks are much easier to deal with. And we've actually introduced soft forks in such a way that in many cases, what we're doing is we're narrowing the rules for everybody who's reading off the menu, but we have a few off menu items that introduce new and exciting features. But if you're just reading off the existing menu, you won't even see them and that's okay. That's how Segwit V1 or Taproot is done. So that allows us to do interesting features, not just remove things, without disrupting our existing users. So when you look at a blockchain like Ethereum, why isn't Ethereum doing their upgrades in the same way that Bitcoin does its upgrades? Well, among other things because they watched the whole debate that was happening in the Bitcoin community over doing hard forks for the block size. And Vitalik has said very explicitly that one of the design goals was to not put too much power in the hands of the miners and to create the conditions that force miners to go along with frequent changes in the form of hard forks that are backwards incompatible and would otherwise break the protocol. And this is to be able to iterate faster and move things forward. Ethereum is designed explicitly and deliberately to be far less conservative and is willing to break things in order to iterate faster to maturity. That's a very different design philosophy. One that is arguably much more attractive to developers than it is economists and one that allows Ethereum to achieve its missions, that development philosophy would not work in Bitcoin. It would be contrary to Bitcoin's design mission. So I want to dig into that a little bit more. But before we do, Jonathan, you know, one of the other things that they changed in this most recent hard fork to Ethereum is they pushed back the time bomb date until November of this year. So for our listeners who are unfamiliar with what the time bomb is, am I even calling it the right thing? Is that what it's called? What is this and why was it moved? I'm somewhat pessimistic because it's like a red line in the sand that always gets pushed back the date that it's supposed to arrive. Ethereum is sort of like John the Baptist saying the rapture is going to happen in the next six months, every six months for the past five years. I'm not surprised that the difficulty bomb got pushed back. That sort of seems the status quo. I'd be more shocked if it ever actually happened. There are many incarnations of it. The original incarnation of this Ethereum poison pill that the developers can activate in order to get a hard fork was Gavin Wood was talking about an inflation bomb where there was an exponential increase in the tokens on one chain versus the other, which very quickly was viewed as untenable and then it switched to a difficulty bomb, which was a period of block height that one hit would have an exponential increase of the difficulty of each block such that it then became untenable to continue manufacturing new blocks to basically force a switch. The fundamental problem with any form of chain invalidation code is that if you're going to activate some sort of difficulty bomb, you're trying to turn the network off. A, why would the hash rate migrate? And then B, why would the hash rate just not hard fork out the difficulty bomb? Like if staying in consensus is to kill the protocol, they could just trivially stay out of consensus by just taking out the difficulty bomb. And so it's sort of this delusion of choice where every time it's apparent the difficulty bomb wouldn't be executed because the hash rate wouldn't go along with it. They announced that they're pushing back the difficulty bomb, which is just another way of saying they lost that round. So it's sort of a problem. How do you get consensus to maintain parity with a system that tries to negate the consensus that it needs to buy into it, right? Like, how do you get Ethereum to turn off proof of work when proof of work has to acknowledge the decision and agree to it? Well, so let's not go down that particular rabbit hole about the proof of work to proof of stake transition that's coming. I want to stay focused on this difficulty bomb and the incentives that Andreas was talking about kind of up front. It feels to me like the difficulty bomb is not something that potentially is ever intended to go off. It's intended to create leverage such that the incentives where miners might typically be very conservative and very happy with the way that things are and not want to change anything. Instead, they kind of have a gun to their head, right? Which is that either you go along with our changes and then those changes effectively as part of that package push back the difficulty bomb, which allows you to continue to do exactly the thing that you're doing, assuming that you go along with sort of the consensus, I suppose. Although it's kind of an interesting way to think about consensus with this leverage that the difficulty bomb kind of presents. Andreas, how do you feel about the difficulty bomb and is that the mechanism that allows them to do this? To me, that's what the difficulty bomb is about. I think for some people it was also meant to eventually disarm the miners so that if they could move to proof of stake, but that's simply a side effect. It's meant to force frequent hard forks. And whether you choose to do a hard fork with nothing but the diffusion of the difficulty bomb or you choose to do a hard fork that also has other desirable features. If you force a hard fork, then you're forcing people to take sides and people invariably take sides with a feature filled hard fork that the developers have proposed. It's very, very similar to the way the US legislature uses the deficit ceiling and the National Defense Authorization Act and reconciliation mechanism to pass budgets in the face of a filibuster. It's intended to prevent a filibuster by the miners and to prevent ossification of the protocol. And I'm not pessimistic at all about it. I think it's worked. It's worked exactly as intended. And it has allowed Ethereum to continue to introduce new features, even features the miners don't want by forcing them into a situation where they have to accept the hard fork that's offered to them. Let's take this and draw it back to Bitcoin, then. So Bitcoin doesn't have a difficulty bomb. There's no doomsday device that miners have to be concerned about. Is that a mistake? Is that not important for Bitcoin? Is it a better thing that Bitcoin has in the long term? Jonathan, let's start with you on this one. When we talk about changes going into Bitcoin, should it have something like this? Does it suffer for not? Or do you think that it's just irrelevant? Well, I mean, it was apparent that not enough of consensus was signalling within the protocol, which is why UASF got implemented in Bitcoin. If you look at the whole big block, small block debate, the reason why it was so contentious and the method in which it got solved could all be sort of reduced into there weren't enough methods to signal on chain when the halting function was miners themselves not agreeing. And so when Bitcoin implemented user activated soft fork signalling, or in this case, user activated hard forks, the consensus issue of how do we move forward got solved. I think there are many ways to address checks and balances with regards to consensus that don't necessitate something as extortionist or threatening as, you know, pray I don't take away what you have further that occurs in Ethereum. But, you know, Bitcoin did encounter this problem in a very serious way that almost broke the system in half. That's exactly what happened. And for those listeners who weren't around then, in August of 2017, there was a deadlock between the big block, small block and centrists who wanted both situation in Bitcoin. And it was brought to a head by a threat by users to embargo blocks to basically not accept blocks that did not adopt Segwit. And that resolved the deadlock in that moment. And that remains Bitcoin's difficulty bomb. It's not a difficulty bomb, but it's basically a revolt of the users using a boycott slash embargo mechanism against miners. And it allows the economically active part of the consensus to apply pressure to the mining part of the consensus constituency. So when we talk about applying pressure really in both of the scenarios we've been talking about here, both the user activated soft fork on Bitcoin when it had its last significant hard fork. And then on the other side with Ethereum, with the difficulty bomb, what that sounds like to me is actually a lot less like consensus and a lot more like people kind of setting up situations where they can force consensus, where consensus may not actually exist. I disagree with that characterization because at least in the Bitcoin context, what you could say is like conceptually, what is consensus and what are the different groups involved in achieving consensus? And then I think the goal of a protocol is to have as many of the different mechanisms of consensus expressed on chain rather than off chain. And so what we saw with USF was a maturation in Bitcoin's ability to take off chain signal procedures and bring them on chain. And I actually think that one of the things we need in Bitcoin is more robust on chain signaling of these off chain consensus coordinating mechanisms, like the fact that the core devs they act and they propose and they engage. Like I want more of that signaled within the protocol. And I think that in the areas where we find issues with miners or stagnation, it's from a lack of more distinct ways to signal within the protocol, not because we're trying to counterman the miners or there's too much signaling on chain. I would also argue that the USF model of applying pressure at the end of the day, there will always be disagreements between different constituencies that participate in any social experiment like this. A consensus is not going to be achieved without kind of a jostling or power play between different and potentially competing interests. In the case of Segwit, after the fact we discovered that these competing interests had a very specific monetary basis because of a secret optimization in ASICS that was being used by one mining manufacturer and that was being messed up by Segwit. So there was a hidden motivation there for this kind of power play. What's interesting I think is that the USF model acts as the proverbial gun on the mental piece in a check-off play. It's there just to remind everyone that it's there. And if you see it in Act 1, it might get fired in Act 3. In the particular case of the USF, the mere threat of firing it achieves the end goal. And what's interesting is that we saw that play out in Taproot again. We saw a play out where the USF was effectively disguised in another parameter called lock in on timeout where the big debate for activation of Taproot was between whether lock on timeout or LOT should be set to true, meaning that the miners get a chance to activate it and if they don't by the timeout of activation it gets locked in anyway or whether it should be false and they don't get activation. Now that caused a big delay in the start of the activation and signalling process but it also put a ton of pressure. In the end, the compromise that was reached I think is beautiful was this option for a speedy trial. And a speedy trial is again to use the reference to a legislature is a unanimous consent voice call where basically you asked by voice vote for everyone to give unanimous consent to proceed and that was speedy trial. It was like, why force the miners if we don't know yet if they're going to try to filibuster? So instead, what we're going to do is we're going to give the miners an opportunity to act in good faith by doing a very fast trial of signalling called speedy trial which will activate or not within a matter of three months and either the miners will play along and if they don't we fail that experiment and then we decide how to proceed with the implicit threat behind that how we will proceed will probably be a flag day activation effectively a user activated hard fork or soft fork to force this issue and in the end it was unnecessary. In the second difficulty period of speedy trial we got activated and locked in and were good either the miners blinked or the miners were always on board and had no intention of filibustering but in any case we got a very fast activation and I think that will become the go forward model for doing activations in bitcoin. But there's also something worth mentioning here when it comes to semantics or word play which is at least an ethereum they call it a difficulty bomb which itself sounds contentious. The funny thing with semantics is if you ask someone does user activated soft forks ever result in a hard fork and they'll say no. And it's sort of funny even the name user activated soft fork is taking a position within the argument because if you're saying you want a restriction in rules then the people who don't agree with that weren't agreeing with the restriction in rules and so by proxy you're basically saying like it was a soft fork it wasn't a hard fork because the restriction in rules was the appropriate set of rules and then by not restricting you have a higher rule set than what we have and so you're hard forking but the proposal was a restriction on rules not an increase in rules so it's like this dumb semantic where like if you talk to most of core and ask them if bitcoin cash was a hard fork or not they'll say no it was a soft fork that resulted in a chain split they wouldn't even use the word hard fork. Yeah it's funny because the user activated soft fork in practice is just as powerful but it just has a nice name it's almost as if the gun on the mantle piece is a sawed off shotgun but it's in a hello kitty brand pink color it's kind of like in the debate where you can tell where someone sits if they say that they're pro choice or pro life because they'll use the antonym of their option to define the other so it's like well you're anti-choice or you're anti-life right and so the funny thing about the way that they describe user activated soft forks is it's only a soft fork if you're in consensus with the agreement for the change if you're not then it's a hard fork but by calling it a user activated soft fork you're basically presupposing that the change in and of itself is the beneficial outcome so I think that we've done a good job here kind of exploring the various ways in which consensus has happened recently across the two largest protocols and I think the question that I'm wondering at this point is I mean it took what maybe two and a half years of development and discussion and figuring out exactly the right way to get it implemented and then you know putting it into the protocol for taproot within bitcoin to actually make its way from an idea into the protocol itself and now we probably have another I don't know three or four years before we see you know more than 50 adoption and I'm totally pulling those numbers out of my butt but it's a slow manual process where different companies different wallet makers all need to proactively choose to put resources into adopting the changes that were introduced with taproot the thing I want to kind of end this conversation on is do we think that there will be more taproot level changes which again was a pretty fundamental change in a lot of ways and not backwards incompatible but in terms of changing the method in which signatures for example are actually generated and the algorithm kind of around that so I mean like that seems to me like it's a pretty big change do you think that there will be any changes of this size in the future or perhaps larger or perhaps smaller absolutely there will be and they're already in the pipeline yes you're absolutely right that it took three years to get here and the reason it took three years to get here is among other things because a lot of fundamental invention had to happen with snore signatures so picking exactly how to formulate the type of snore signature and make it so that we could use some of the kind of tricks or magic of snore signatures to do things like adapter signatures and signature aggregation and not bite off too much in the first bite and make it a bit smoother make it easier for developers and of course a bunch of other features that have gone in here because taproot isn't just snore signatures it's also mercilized abstract syntax trees that allow you to have much more complex scripts and you can only reveal one portion as well as taproot which allows you to disguise those much more complex scripts as a single pair this was a major package of upgrades an omnibus reconciliation bill if you like and it took three years to research and test because it was very thoroughly tested the use of snore signatures and reference implementations in a bunch of different languages as well as in libsec p256 which is the main consensus and cryptography library of bitcoin have been out for a while now and what that means i think is that developers can move much faster to implement this than they needed to implement with segwit in many cases because the segwit code they introduced had the types of modularities in script construction when you go from one type of script to two it becomes a lot easier to then add a third because you had to rewrite your code base to identify two different sets of scripts right i think we're going to see much faster adoption of taproot and you know to the point that it takes three years to research and develop these technologies and then maybe another one or two years to adopt them in wallets while that is true these do not happen sequentially the very next one i expect to happen is probably going to be some form of cross input aggregation or possibly the any prev out sig has no input basically adaptation that allows us to implement more flexible construction of smart contracts for things like lightning or some form of covenants using either op cat or op check from stack or some other formulation of that and all of these things have been in very active debate for at least three years some of them just as long as taproot some of them as long as segwit so they're getting much closer to reaching a level of maturity where they can be deployed we've got a better deployment and activation mechanism we've got a whole bunch of features that have been drafted and are moving forward and i expect we're going to see changes like that happen again the real question i think is are we ever going to see hard fork changes that modify the consensus protocol either to increase the block size and or to introduce privacy features into the base blockchain that's a much harder question to answer and i think there's a lot more consensus and a lot more political will for taking those kinds of very risky moves that at the same time are also very powerful moves so it sounds like we're talking about different changes will continue to be made will continue to see these same types of potentially fundamental upgrades come into even bitcoin even in its current quote mature state so in the past we've talked about this idea of ossification and ossification just basically means that you can't change it anymore right it's fixed it is what it is and that's what we deal with we talked about this in the past in the context of ipv4 versus ipv6 right ipv4 is the old standard it has basically run out of room so it can actually no longer really be used in the way by all the people who want to use it and then on the other side we've got ipv6 which is the much larger space that sort of resolves this problem but the problem is is that ipv4 is built into so much stuff that's out there in a way where it really can't be upgraded they're kind of stuck you know we have the new technology but we can't make the move from the old to the new are we concerned about that for bitcoin still i don't think the analogy works for a couple of reasons one is that as adoption of the internet grows you have more and more people using the internet the reality is that the vast majority of people who are new to bitcoin aren't doing on train transactions and so the switch to taproot transactions are going to be for people who first and foremost actually use the bitcoin protocol and then to that end taproot actually saves you money so it's as if the difference between ipv4 and 6 was the amount of money you paid every month for internet was 50 percent lower if you used ipv6 versus 4 there are no incentives on the internet in the same way they are for bitcoin in this adoption and the transaction fee differential is even greater than the switch from you know regular transactions to segwit transactions there's going to be a real meaningful incentive for those of us who actually do on chain transactions to transition over especially for complex protocols and it has a huge impact on the adoption of the lightning network by simplifying and strengthening the core protocol i think probably one of the biggest users of this is going to be the lightning network and that's another way that ossification has been overcome in bitcoin we're now talking about protocol level features that are being used not by end users and wallets but by layer two protocols and make those layer two protocols more powerful so for the average user we don't really want to see the average user necessarily doing paid to taproot transactions on their on-chain bitcoin wallet i think in the longer term what we want to see is people migrating to using lightning almost exclusively for almost all transactions with the only time they go on chain is their wallet doing some kind of channel open close or rebalancing operation in the background so the customer for these changes is the layer two protocol it's the layers above that are using this not the end user and at that point it doesn't matter as much because you end up with both the legacy stuff and the new stuff coexisting on the network just like ipv4 and ipv6 coexist on the network now and when devices need to be upgraded they get upgraded in places where they've run out of addresses they use the new protocol i think jonathan's right though there is an economic incentive here so i think we will see faster adoption the bigger concern i have is that ossification will really be a stumbling block for us in the adoption of better privacy in the base layer and perhaps even to me the bigger block thing was never if we should have bigger blocks or if we should not have bigger blocks but when when can we squeeze all of the optimizations out of what we have now and still need more space i think an interesting thing to watch when we talk about ossification and tiering of the bitcoin network is in relation to these overly onerous disclosure statements and the fear as to what constitutes obfuscation on chain if we might see a two tiered system within bitcoin and exchanges and regulated entities themselves will refuse to use or engage with taproot transactions because of the ability to not be able to disprove if that transaction was a coin mixed transaction or not and so just because they can't demonstrate that it wasn't they'll then both deny the usage of it or the sending and receiving from it and so it'll be very interesting to see in a stupidest of stupid outcomes if just by simply having taprooted transactions coming to an exchange or going out from an exchange to it is something and then we have two tiers of bitcoin everything on lightning that's using taproot with normies and everything in the custody not your keys not your coins bitcoin world so what i'm hearing there and you guys got right to where i wanted to go with this which is like okay so there are changes that we can make and it feels like that's good moving forward what are the changes that we can and basically i heard two things there and they're definitely overlapping in the venn diagram of issues one is that companies that are regulated probably won't support changes that make it difficult for them to be compliant with that regulation because they're continued ongoing existence as businesses especially larger companies like coinbase in the current era that are actually publicly traded they'd be shooting themselves in the foot effectively making their job harder by making the protocol more private which could then impact their ability to be compliant under whose auspices they operate needs them to be and then the other related one is privacy generally and i believe the argument there is that privacy although many people support it has no inherent financial incentive behind it that is driving the adoption of it in the same way that some of the changes that we've been discussing here which actually make it cheaper to use the bitcoin network as a whole first am i right on those and second is there anything else that we think that might turn into a problem down the road as things that the network should do to make it a better more efficient more useful tool for all of us but which might run into problems for either those reasons or something else i mean if we're talking about 20 to 30 years out this whole like public markets mining coalition and this whole push to make co2 the devil and that people need to sell you know indulgences to the catholic church to get blessed for their sin i think you know we were blessed with a great opportunity when china shot itself in the foot and pushed their miners out but i am concerned for the 10 to 20 year outlook on consensus if all of that inverts into the united states creates you know a self regulatory organization and then you have an opec or a dtcc or a finra of mining that constitutes 80 or 90 percent of the hash rate and there may be some serious consensus level conversations that need to happen when that occurs if that does occur i think you're gonna see some as you put it jonathan some difficult consensus conversations including switching consensus algorithms and switching consensus approaches one of the good things however is that unlike a coin that's being bootstrapped where you can't do proof of stake because no one has a stake and you can't do a fair distribution bitcoin's already bootstrapped and it's already been broadly distributed and the people who actually own their keys are the ones who care the most about these things so you could do effectively a proof of stake system and i think that will become the ultimate loaded gun on the mantle piece for these kinds of moves by regulators well this is certainly a topic we'll be revisiting as we see more of these big changes coming in and ask ourselves once again are we at that point where the bitcoin protocol probably won't change except in very specific circumstances but for today that is all the time that we have today's episode featured andreus m and sinopoulos jonathan mohan and myself adamby levine this episode featured music from jared rubens and girdie beats with editing by jonas if you enjoyed this episode send us an email at adam at speaking of bitcoin dot show or just leave us a review on your favorite podcast player and until next time thanks for listening