UASFs, BIP 148, BIP 91 and Taproot Activation
Speakers: Matt Corallo
Date: February 11, 2021
Transcript By: Michael Folkson
Category: Podcast
Topic: UASFs, BIP 148, BIP 91 and Taproot Activation
Location: Tales from the Crypt podcast
Intro
Marty Bent (MB): Sitting down with a man who needs no introduction on this podcast. I think you have been on four times already. I think this is number five Matt. You are worried about the future of Bitcoin. What the hell is going on? You reached out to me last week, you scaring the s*** out of me. Why are you worried?
Matt Corallo (MC): First of all thanks for having me. I think the Bitcoin community broadly right now is selectively misremembering events that happened only a few years ago now and taking conclusions from it that are not entirely justified. We can get into it in depth but I think the block size wars had an effect on a lot of people. There were two sides that both had a story to tell. One side got largely pushed out of Bitcoin, a lot of people on the “losing side” have moved on from Bitcoin and are doing cryptocurrency exchanges or just not working in cryptocurrency anymore. That left a side that gets to write their own history. I think there is some facts that have been left out and more importantly it impacts the way people see Bitcoin’s future and how Bitcoin should exist going forward. And that worries me, I don’t really care if the history got rewritten, I care if it results in a Bitcoin that is fundamentally less safe.
The history of SegWit and SegWit2x
MB: This all revolves around the user activated soft fork and that mechanism to activate certain upgrades, whether it be SegWit or potentially Schnorr and Taproot on the horizon. Let’s jump into the fine details of what went on, how a user activated soft fork works and why you believe it should be the nuclear option, is that the correct term?
MC: Yeah maybe. If we wanted to get into it we have to go back and revisit the history. We have to go back and remember exactly what happened and more importantly what didn’t happen. For most of your listeners who were around a few years ago or who have since learned the history of SegWit2x and the activation of SegWit, it bears revisiting and ensuring that everyone is on the same page, there is a more complete history that people are aware of. As hopefully most of your users know with SegWit there was a large debate within the Bitcoin community broadly, exchanges, large industry players, miners, users, developers, a number of different crowds around how Bitcoin should scale. Whether the block size should just be increased ad infinitum, whether the block size should completely be untouched. It all focused on the block size largely, there were a number of technical issues with just blindly increasing the block size which after some time led to the proposal of SegWit. SegWit is kind of a nifty little trick to increase the block size somewhat while also solving a number of technical issues that prevented increasing the block size previously. There were potential denial of service issues with just blindly increasing the block size that SegWit solved. So it was this nifty little trick that came out from Pieter Wuiille and Luke Dashjr designed for Bitcoin and proposed that as a standalone soft fork. That is the beginning of the story. Over the next year after that was all out Bitcoin civil war that had already been building but it reached a fever pitch throughout the course of the one year activation timeline. SegWit and several soft forks prior to it generally had a theory of soft fork activation which went something like this. Developers work on the soft fork, design it and propose it to the community broadly in the form of both a BIP and code and that code eventually hopefully takes the form of a Bitcoin Core release. This in effect is a formal proposal to the community for a new soft fork. Then hopefully the community adopts it, upgrades to it, is happy with it by the time it is out there, hopefully it has really strong consensus behind it. And as a final step, because with soft forks you want to make sure that the network stays together on one chain you have miners signal when they are ready and when they are in fact enforcing rules. If you don’t have that you could have a chain split. You have a majority or a good chunk of miners who aren’t enforcing the rules, the chain can go off in one direction that is invalid to a number of nodes and suddenly you are going to have two chains depending on who you ask and whether nodes have upgraded or whatnot. That is a mess, you don’t want that. It is not fun, you end up with double spend potential for some people who might have forgotten to upgrade a node or whatever. No one wants that. So ideally you have miners say “Yes I’m ready. I’ve upgraded.” Once you reach some threshold, in the case of SegWit and a number of other proposals it has been 95 percent, the change locks in and activates and everything goes forward. SegWit took place over the course of a year, it came out as a proposal and a Bitcoin Core release. At the end of a year it would have timed out and presumably some other activation method would have been tried. SegWit kind of languished and depends on who you ask for exactly why, miners had some dubious incentives around some optimizations they were using that were patented and they weren’t very upfront about it, other reasons to block it. There was a contingent within the community that might have been happy with SegWit but viewed it as insufficient, that the block size needed to be increased hugely and SegWit represented some small multiple, somewhere between 1.5x and 2x, which is still a pretty substantial increase but they wanted a significantly higher multiple. SegWit, which might have been fine on its own was not sufficient and thus simply shouldn’t happen. Long story short, this kind of miner readiness signaling that was intended to just prevent the network from splitting into a million pieces was abused to prevent SegWit from activating.
MB: This is version bit signaling via BIP 8 correct?
MC: BIP 9 I think. BIP 8 is BIP 9 with a few fixes in it. Then during this time period a number of companies got together in secret and decided they were going to decide Bitcoin’s consensus for us all, signed what became the New York Agreement led by DCG and declared unilaterally that Bitcoin was going to activate SegWit and in addition a hard fork which further doubles the block size on top of the SegWit increase. SegWit is already a 1.5x to 2x, and then we are going to double it again and get something between 2x and 4x. This was going to activate on some, I forget the exact timeline but it was something completely nonsensical. It was like “We are going to upgrade the entire Bitcoin network and everyone is going to upgrade their node in like 3 months. Let’s go.” The increase block size more thing, whatever, let’s do it all in 3 months is obviously brain dead. But more importantly SegWit2x represented a small group of people coming together and deciding Bitcoin’s rules. Fundamentally my issue with anything around consensus changes is that we as a community need to have a higher bar. We need to have a very high bar for how changes get made and if in the end you have some small group of people who are allowed to just blindly upgrade the rules, decide in a private meeting, invite only, what the rules are then Bitcoin has failed. This private meeting is going to decide that you have to do KYC or a private meeting is going to decide that it is ok if not everyone can run a node and it can be prohibitively expensive to run a node. There are a number of things that would be unacceptable but would be trivial to do if you are able to change the rules by small committee. That was the New York Agreement, SegWit2x. The community was broadly up in arms, the developer community was universally up in arms, there were no objections within the developer community to condemning SegWit2x and the New York Agreement. So the community is up in arms, there is this group of industry players who are saying “We are just going to do it, it doesn’t matter what you say Bitcoin users, it is just going to happen, suck it up.” Because SegWit2x was a hard fork it was fundamentally going to be a different token. If you had sufficient hash power on both sides you could always have two tokens, you could always trade the old one for the new one and vice versa. And so of course several exchanges just listed both and listed a futures market. Bitfinex listed a futures market that was relatively deep and BitMex, it is only a futures market but they declared that the futures were going to be only non hard forked Bitcoin as it exists today, not the SegWit2x Bitcoin. The futures market told a very different story from the confidence of the business community. SegWit2x tokens traded something around 20, 30 percent, sometimes it was 10 percent of Bitcoin. You could see this both on Bitfinex’s direct trading of the two tokens but you could also see it in the discount on the futures on BitMex. You had billion dollar daily volumes on BitMex showing exactly what these hard fork tokens were worth. It was a pretty good indicator that the market was not a fan of the SegWit2x idea. Now you have this very vocal Bitcoin community on Twitter, the developer community, you have a very confident business community, several key businesses, not every cryptocurrency business but several key businesses in the cryptocurrency space. Coinbase, it was led largely by BitGo, a number of others, a number of large mining pools. They are both declaring they are going ahead with their vision and this would have resulted in two separate currencies fighting over who gets the term Bitcoin and as you might imagine that would be a mess and that would destroy the value of Bitcoin for basically everyone.
MB: If they were successful in writing good code, we came to find that they were off by one block and it wouldn’t have successfully hard forked.
MC: Their software didn’t actually function. This is what happens when the entire developer community thinks this is a terrible idea, they can’t hire someone with a deep understanding of the codebase because they all don’t want to work for you. You have these two factions that are screaming they are going ahead and both won’t admit it publicly but very well aware that if they both go ahead the whole thing catches fire and any legitimacy that Bitcoin had in the financial world is gone because now you have two different people claiming to be Bitcoin. Why would anyone care? A number of critics who have always suggested that Bitcoin has no value because anyone can create a new cryptocurrency and thus there is no scarcity, a poor argument, but it would have actually been true had this come to pass. I think a big reason why it didn’t come to pass is because everyone understood that their entire value would be gone. That’s a pretty strong incentive if nothing else. So how do two competing factions who both have very different visions and both think the other is acting in bad faith come together and protect the value of Bitcoin and prevent it from splintering into two different things but presumably later having more issues. The very loud Twitter community, there were a few folks who were very “Screw big business” and blah blah blah, but notably only one or two folks who ever contributed materially to Bitcoin Core decided that they were going to do what was then termed a user activated soft fork. Before BIP 148 and UASF we would have just termed it a flag day soft fork but basically it is just a change where on a certain day it activates, period. You have some software, the software says “On this date the consensus rules are going to change to be X, whatever X is.” In this case X was “If your block does not signal readiness for SegWit and isn’t contributing to turning SegWit on we are just going to ignore you and consider the block invalid.” That was one group, it was very vocal. So now you have two proposed changes in addition to original Bitcoin. You have the soft fork that is led by a bunch of users on Twitter who are saying “We are going to fork off any blocks that don’t signal for SegWit and we are going to go off on our own way and have our own chain.” Then you have this business community that is saying “We are going to go hard fork and have our own chain.” Then you have the people in the middle who are still just running the software that they downloaded two weeks ago and are a little confused maybe. Now suddenly you have Bitcoin careering towards three different tokens. What happens next depends on who you ask. I think this is really the key issue.
MB: Can we take a step back before we get to the key issue? Did the Twitter users propose the user activated soft fork? Where does Shaolin Fry play into this?
MC: There was one anonymous developer who wrote BIP 148, I don’t believe their actual name or identity has ever been revealed, there is various speculation about it. They posted the BIP and posted some code for it and provided binaries. A bunch of people downloaded it, the alias Shaolin Fry had never contributed to Bitcoin Core, it was never used for anything else, that alias existed only to post what became BIP 148 and this code. They obviously had a relatively active Twitter account but that is where this code came from. So if you ask someone who was staunchly in favor of BIP 148 and UASF, their view is that UASF activated, BIP 148 was enforced and on the day of BIP 148 no blocks did not signal for SegWit and thus no blocks were every forked off and the consensus rules of BIP 148 still remained on the same chain with the rest of Bitcoin. That soft fork was enforced and SegWit activated and happily ever after. It is obviously a little wrong because to my knowledge no pool or materially sized transactor ever run that code. A lot of Twitter users were running it, there was a campaign to get people to spin up UASF enforcing nodes but just spinning up a node as we know doesn’t have much impact on anything. Otherwise Chainalysis would be in charge of the consensus rules because they certainly have a lot of nodes. What really matters is people using a node to transact saying “I will only accept your transaction in Bitcoin if my node thinks that the rules of the network have been enforced and that transaction meets all the rules of the network including is included in a block that meets the rules of the network.” Some individuals presumably transacted around that code but no large businesses, no people accepting large volume payments, no mining pools and presumably not even very much in terms of total transaction volume of individuals ran on it. I certainly never ran it and I transact some on Bitcoin Core. So what really did happen and why was it that all the blocks suddenly started signaling for SegWit on that day? That is where it gets complicated and it is kind of unclear. There is some indication that the very confident Twitter users who were saying “We are running UASF whether you like it or not” scared several large players in the mining pool space, specifically there were rumors going round that Jihan (Wu) was scared by it. It is not unreasonable right, you have people who are very ideological and believe very strongly in Bitcoin and are telling NYA to go screw themselves. Saying that they are going to run the software and they are going to fork Bitcoin into another coin whether you get onboard or not. It is absolutely the case that both those users and everyone loses out if Bitcoin forks. You have two tokens and in every possible way it is a mess. There was a proposal which several New York Agreement signatories, SegWit2x supporting businesses and mining pools got behind called I believe BIP 91, I may be wrong.
MB: I remember BIP 148, BIP 90 and BIP 91 being crucial around this time.
MC: There was BIP 91 which said “What we are going to do is we are going to do SegWit2x, you are going to signal readiness for SegWit by the date of the UASF activation timeline and that signaling is going to signal support for both SegWit and a hard fork. The SegWit2x people should go ahead and signal readiness for SegWit and we should activate SegWit that way.” If you asked some large businesses that is probably what they would have told you at the time they were signaling.
MB: There were sites tracking the percentage to it.
MC: Bitmain exerted a lot of influence on their customers and basically the entire Bitcoin industry in China because a large part of it was mining related. Basically they would tell people “If you get onboard and do what we say and use our pool or use a pool that we bless then you’ll get the next generation hardware sooner and for a cheaper price.” Basically once Bitmain came around, they were the big blocker, once they came around all the other dominos fell within a week. That’s largely what happened. The “UASF activated and we won. We showed them via the free market thing” it is a little disingenuous. Clearly the free market and the very large volumes of futures trading and this fork token trading on Bitfinex showed very clearly that the SegWit2x New York Agreement token was dead in the water. It had 10 percent of the value of Bitcoin or 20 or 30 depending on where you looked. It was a small fraction of the value of Bitcoin and it was dead. There was never any futures trading for what would have happened had the UASF token gone off in one direction and classic Bitcoin had gone off in the other direction which was totally a possibility. The UASF thing, the code for it was released very, very quickly because of the time crunch basically, SegWit was about to timeout and they wanted to make sure that it activated before SegWit timed out. They released it and it was going to turn on I think within a month or two or maybe even a few weeks. And so no one spent the time to figure it out on paper and give the markets the voice. No one had the time to audit the code so no one was materially risking their business on it or accepting really large volume payments on it or switching out to it. There were a number of issues in the code depending on which case you looked at. One Bitcoin node forking off from the rest of the network and finding other peers to connect to that are on its fork is not a solved problem in the codebase at all. Hopefully it should never happen. Or it definitely wasn’t at the time. It is very unclear whether you could say that this UASF, BIP 148 movement ever activated. You could absolutely say it had an impact and it probably if you believe rumors, who knows, had some impact on Jihan and Bitmain and actually scared some people into allowing SegWit to activate in the signaling. But had they decided not to do that it basically had no hash rate behind it. So somebody needed to step up, if it was going to be a thing, and invest a very large sum of money to buy miners, offer existing miners to buy their UASF tokens had Bitcoin forked. It is unclear that there was this kind of money behind it. You see a lot of people running around saying “Yeah UASF is great, it works, we’ve done it before. It activated and it is how we activated SegWit.” The story is 10x more complicated than that. At the end of the day the only thing you can say for certain is Bitcoin users, Bitcoin mining pools, Bitcoin miners, Bitcoin businesses all understood that if Bitcoin forked into multiple tokens that would be very bad for their investment. Then they took action to make sure that didn’t happen. You can’t really say anything more than that. You can’t say that one thing was the thing that activated anymore than you can say that another thing was the thing that activated SegWit. There were several things involved.
MB: I am pulling up the newsletter that I wrote on Tuesday July 18th 2017 and one of the headlines in that newsletter is “BIP 91 to the rescue, hopefully.” This is the way I understood it in the middle of July to bring some clarity. Funnily enough this is the same one in which John McAfee said he is going to eat his d***. I have that in the newsletter too. There is the possibility of locking in SegWit via BIP 141 which required 95 percent miner consensus. At this point 95 percent miner consensus was not reached via BIP 141. Our last hope of activating the protocol upgrade without a network split may be BIP 91 which is authored by James Hilliard. The BIP makes it so BIP 148 and SegWit2x are compatible. In short if 80 percent of the miners represented by collective hash power signal for BIP 91 SegWit will be activated and all blocks that are not signaling for SegWit activation will be rejected from the network. That is the way I described it.
MC: Right, BIP 91 basically reduced the threshold from 95 percent to 80 percent and then also made a non technical statement that this signaling would also include signaling for a hard fork. That hard fork never materialized, there were no developers interested in writing code for that and even if someone had written code for it it probably would have got laughed out the room. That part was basically ignored after the fact.
MB: It is cool have this historical journal. So James Hilliard, BIP 91 was “Alright guys, let’s not split, let’s compromise here.”
MC: It is terrible for all of us if we split. Here is a thing that we can do where both sides get to claim they won. The UASF people get to scream about how UASF locked in on this date. The miners and large pool operators get to talk about how they successfully activated SegWit2x and at the end of the day SegWit will be activated in a way that is compatible with every node that is currently sitting on the network. We can all go about our lives and have one Bitcoin.
MB: The miners were crucial in this, you needed 80 percent of miner signaling.
MC: Right, with all of these really compressed timelines the UASF BIP 148 crowd was suggesting they could activate something on a really compressed timeline but you can’t get any material amount of nodes upgraded. The only thing you can really do is get miners to enforce these rules. As long as they are enforcing them they are the rules of the network and we’ll get nodes to upgrade over time to enforce them.
MB: It was a hairy situation back then if you weren’t around.
MC: It was so hairy. There was definitely some hair loss due to some stress. When you compare a President’s photo when they start their term and when they end. These days not so much, they used to start and they didn’t have gray hair and then they always ended with gray hair and they always looked about 20 years older even though it had already been 8. Over the course of one year.
MB: Obama’s was pretty drastic.
MC: Obama looked about 20 years older.
MB: I am loving that we are rehashing this, jogging memories and going back through all the newsletters now. This was a daily update. BIP 91, shoutout to James Hilliard for pushing this forward. Arguably prevented a network split. Even myself personally, the years that have come to pass, I have somehow whitewashed my own memory and thought that BIP 148 was the driving factor for actually activating it. It was more influence or pressure.
MC: It was definitely a very successful pressure campaign. If you want to argue that that kind of thing activates you really have to make a market analysis and have some evidence that the other token is going to be completely worthless and thus our flag day activation and our splitting off is going to be the only thing with value and the only thing with hash power and the only thing that exchanges care about. That just didn’t exist then. If you want to assign blame for what really succeeded and what really activated SegWit you would have to have visibility into how things would have gone had the various splits happened. And we just don’t. There are a lot of things that came together and a lot of things that had an impact. It is impossible to say what did it.
MB: Now I’m refreshing my memory around this, the consensus right after was both sides can say they won. Everybody can be happy. Why are you worried about this now?
Taproot activation
MC: Rehashing old history is fun, well actually for most of us it is miserable because that was a pretty stressful time. But it is important I think to take away the right conclusion because in discussion of Taproot, there aren’t as many voices in it as SegWit, it is pretty straightforward.
MB: Not even close to as controversial.
MC: It is very, very well designed. Too well designed sometimes. A lot of effort has gone into it. I think importantly Optech has done some good work on reaching out to businesses and chatting with businesses about the design, making sure these large industry players who are using Bitcoin are aware of it and know about it, and also a lot of the community. The core consensus bits of Taproot are great, no one has anything bad to say basically. Cool, let’s do it. The community has taken that a little bit to heart and is like “Cool, let’s go. Let’s do it, let’s turn it on.” The how to turn it on is sadly maybe also just as important as the actual design. At the end of the day you have to write consensus level code, code that describes how Bitcoin functions as a part of the activation method. The activation method of a soft fork is a consensus change in of itself. It describes a consensus change that activates this much larger consensus change but it describes a consensus change. So it needs just as much care as anything else. To wax a little more philosophically Bitcoin in my view, most Bitcoiners and a lot of people have invested in Bitcoin because it represents this conservative system that you can depend upon, that exists and provides you hopefully censorship resistant value transfer and value storage, payments whatever in a way that you can depend on. If you are using it in some specific way today you are going to be able to use it in that specific way in 5 years, in 10 years. The consensus system that is Bitcoin, the technical features available to you in Bitcoin continue to exist in roughly the same way or at least a compatible way as they do today in the long run. And your use case for Bitcoin, there are a million use cases for Bitcoin, whether you are hedging against the Fed printing too much money and you think hyperinflation is happening or whether you are in Venezuela and hyperinflation is happening or whether you are in Nigeria and you want to accept donations because you want to protest against the government being sketchy or you are in Russia, whatever, there are a million reasons to care about Bitcoin and to have a use for it. If you have something like that Bitcoin should continue to serve you. You should be able to invest in and use Bitcoin and invest time into building Bitcoin based solutions feeling safe and secure that it will continue to exist as it exists today. No one is going to come in and change it out from under you, decide to change the cap because that will help certain users but hurt certain other users. Or no one is going to come and out from under you change materially the fact that there are transaction fees because you invested a tonne of money into buying a mining farm. At the end of the day because there are so many different legitimate perfectly valid use cases for Bitcoin we as a community have to make sure that changes happen in such a way that Bitcoin continues to work for all of those use cases. That has always been my theory on soft forks. I wrote a whole long blog post on February 28th 2017. It is the last blog post I wrote.
MB: I like you writing code instead of blog posts, it is better time spent.
MC: Probably. I have this whole long thing where I wax philosophically about there being different use cases of Bitcoin. That is important and that is what is so cool about Bitcoin. I have my interests in Bitcoin and you have your interests in Bitcoin and they are fairly different. We care about Bitcoin for fairly different reasons, obviously it overlaps a lot but certainly I care about Bitcoin for many different reasons than a lot of other Bitcoiners. There are some people down the street here in New York City who are trading Bitcoin who are Bitcoiners. They care about using Bitcoin as a hedge against the Fed or whatever monetary policy or whatever crazy market things. They are still Bitcoiners even though they are never on Bitcoin Twitter but they have a use for Bitcoin and we should make sure that exists and that use case is still supported. If we take this as an important key value proposition of Bitcoin, that there are so many value propositions and that we care about all of them, we have to be very, very careful about not just about the consensus changes we make, Taproot is very carefully done and most importantly if you don’t want to use it there is not really any reason to care about it. It is not going to negatively impact you. Maybe fees will drop a little bit but probably not a lot. There is no reason to worry about if you aren’t going to use it. But also and more importantly the activation method sets the stage for how we activate soft forks. That activation methods themselves describe a set of rules technically and in code but also socially of what bar we hold changes to. Because Taproot is this thing that has been going for a while, it has been cooking forever, it is super carefully designed and it is really well implemented. There’s code and it is great and it is ready to go. There are a lot of people who are like “Let’s just do it. Last time we did this UASF thing.” They view history through some rose colored glasses maybe. Let’s just do it, we’ve got this thing, let’s just turn it on, the last UASF came on and activated in a few weeks, let’s just do it. We’ve got this. I think that does Bitcoin a disservice. I think if our approach to changes is that we as a very small community on Twitter or whatever just ship code that turns on a soft fork whether the network is fully upgraded to it, whether we’ve actually made sure that we’ve talked to as broad a community as we can, that doesn’t set up Bitcoin for a win. It doesn’t set Bitcoin up to be this conservative careful thing that changes only when people aren’t going to be hugely negatively impacted by the change. Most importantly, flag day activations in general and UASF is another term for it, a more cool term now, they don’t have this backout. “Here’s a release of Bitcoin Core with the change in it. We’ve shipped it and the change is going to happen in a year, six months whatever and that’s it.” That doesn’t send a good image of Bitcoin to anyone. No one wants a Bitcoin where a release of Bitcoin Core decides the consensus rules in of itself. Developers shouldn’t be deciding these things. Sure it is the case that Bitcoin Core could release software and people could look at it and say “I’m not going to run that because there is some soft fork I’m not signing up for.” Certainly in the case of Taproot that is probably not going to happen because the change is great, why would we not upgrade to it? But that’s also the way the community learns how changes should be made. You have this Taproot thing, it is great, it is in this release of Bitcoin Core, it has got a flag day activation, a release of Bitcoin Core happens and in a year Taproot turns on and that is it. How can someone who is just passively observing Bitcoin, maybe they care about Bitcoin but they probably don’t have the time to actively participate in the conversations on Twitter or Clubhouse or Reddit or what have you, how can they take away a message from that anything other than Bitcoin Core decides consensus and maybe a small group of users? It is a perfectly reasonable conclusion based on just looking at that. There are many ways to solve it, don’t get me wrong. Flag days aren’t inherently evil, we can’t never do flag days. But it needs a resolution in some way. It needs to be very clear that so much work has been done. This passive observer who maybe in the future will be a Bitcoiner who is learning about how changes to Bitcoin get made shouldn’t be bombarded with people on Twitter saying “Yes we’re activating SegWit, f*** miners.” I’ve seen a lot of people recently on Twitter and wherever talking about how basically UASF is good because it beats miners over the head and tells them they have no control.” It is not useful. Miners are in fact a part of the Bitcoin community, also pools. No more so than anyone else, no more so than any other large business that is made up of a bunch of people who bet their careers on Bitcoin. They should be treated as valued parts of the community no more or less so than anyone else. Certainly if you have as was the case with SegWit one large company or one large pool that is probably acting in bad faith and trying to block a consensus change that was otherwise fairly broadly agreed to they should be ignored and overruled. But that shouldn’t be our first go to, let’s just do this flag day. Also flag days have a lot of other technical risk. When we were talking about UASF and BIP 148 especially because of the timeline if you don’t have really broad node upgrades both on the mining pool level and just across the network, most importantly at the transactor level, people who are making transactions, enforcing these new rules by the time the flag day happens you can very easily end up in cases where you have forks. Maybe light clients or maybe people who forgot to upgrade or one of their nodes didn’t upgrade or whatever may get double spent. You don’t want a risk to that on the Bitcoin network. It doesn’t make sense to risk that on the Bitcoin network unless you really really have to. Unless there is really this case of “Here is a mining pool that is acting clearly in bad faith and they need to be overruled.” It is very clear to all involved, it is blown up into this whole big drama across the Bitcoin community and thus everyone is painfully aware of where all the sides are and how different people feel. In that case fine, whatever. Otherwise you risk and we saw this in very related circumstances but not quite the same as a flag day, it wasn’t a flag day it was actually a BIP 9 activation, but similar circumstances to the soft fork activation where there was a fork. There was a several block fork that was invalid with invalid blocks but that light clients would have accepted payments on and various mining pools extended this invalid chain.
MB: That was March 2013 right?
MC: It was a way before SegWit. I don’t think it was that far back. March 2013 was a different bug. It was only a year or two before SegWit.
MB: March 2013 was a flag day soft fork that caused a chain split.
MC: That was a separate issue. There was one a little later. In any case you can have these flag days, flag days require a much higher level of making sure everyone is upgraded than these miner readiness signaling soft forks where you take advantage of soft forks really activate when everyone on the network has upgraded but that doesn’t mean you can’t derisk the possibility of forks. We should certainly as much as we can derisk the possibility that there exists two chains, that some people who are running light clients might be on one chain and get double spent or what have you. A great way to do that is to say “We are going to make sure that almost all the hash power is ready and running new code.” Version bits is ok for that but it represents that, it represents miners indicating that they are ready and running the code. For flag days there is technical risk, I think there is really high social risk of the culture around Bitcoin changes and holding ourselves to a high bar. Some of it is technical but a lot of it is the discourse and the discourse around doing a UASF or a flag day soft fork activation for Taproot is in my view really negative. People are saying we are just going to do it and we’re going to activate it and that’s just how it’s going to be. That to me sounds like New York Agreement, SegWit2x. It is a broader set of people, it was planned in public instead of in private, sure and that is great, that is an improvement, but it is still this discourse that sets Bitcoin up for not being this community that takes itself very seriously and is very careful.
MB: I can certainly see that. For this particular situation with Taproot, Schnorr, people have been eagerly awaiting this and I guess it is just trying to find that balance between urgency and complacency.
MC: It is totally understandable. It has been forever.
MB: In many conversations with you and others precedents matter and we should be thinking about precedents that are set. Do these nuclear options even need to be put on the table yet?
MC: I am really afraid of this normalization of them. Yes there exist options where we can just go to a full on market referendum and say “Here are two different softwares. They are going to split into two different chains at this date and we think the market is going to strongly prefer to stay cohesive because that is how everyone maximizes their value. Here’s the two chains, everyone figure it out and let the market decide.” We can do that, that is an option and that is basically what happened with SegWit2x and what might have happened with UASF and BIP 148 had the two sides not come together in a more technical way. It is such a mess. It is a mess for everyone. No one holding Bitcoin going into the SegWit activation deadline and the UASF activation timeline was super comfortable. I went into the office at I think 11pm, midnight, right before it was going to activate and planned on staying up all night just to make sure something didn’t catch fire. Every exchange had people doing that, everyone who was meaningfully transacting paused transactions. We shouldn’t have to do that. There are technical reasons for it and there are social reasons for it. But those technical reasons, we can derisk those technical reasons so why are we putting these things on the table?
MB: So let’s describe the table right now for Taproot. What is it looking like?
MC: I have taken some time off from some of those discussions because I got a little frustrated. My understanding is that it has come around, the folks working on it, there is the broad Twitter universe of people who are regularly commenting and there are some public discussions that are a little more structured that some people have put together, I think those public discussions that are more structured have come around to the idea that there is some risk in doing these flag day activations. I think the latest terminology you might see is BIP 8(true) which is just a flag day, there are some other technical features but it is largely a flag day activation. There are some technical risks with this and most importantly there is no one against this thing. Mining pools have even started signaling that they’re in favor of it and they’re ready for it so why are we having these debates? Let’s just do something more akin to BIP 9 but with some of the technical nuance issues fixed that you might now see referred to as BIP 8(false). Especially because it is pretty clear there is not going to be any mining pools that try to play shenanigans to try to block it for their own personal reasons, I think people have come round to that as probably the approach. I still remain very worried that we are normalizing these things. We are normalizing a discourse around changes that is “We are just going to do it. We are normalizing an activation around changes where “Look it is in the same BIP that described the last activation method to describe how we do a flag day activation that not only forces a consensus change but forces miners to indicate preference for this consensus change.” To slap them in the face while we are at it. These designs, people are legitimately frustrated from miners still after years since 2017, since the SegWit mess as they should be. People should be frustrated with miners for that or mining pools specifically.
MB: Jihan is gone. F2Pool had some f***ery with switching BIP 9 off and on and confusing people with their signaling but outside of that the only hostile miner that I can recall was Bitmain being driven by Jihan. He’s gone.
MC: He’s gotten pushed out because he bet the company on Bcash and that didn’t go very well. It should be focused on healing and doing the best and most careful design. I think it is also important to talk up and realize how much work has gone on in the background that I think is critical for consensus changes and should be critical for consensus changes in the future that hasn’t been sufficiently talked up or publicized. There were a number of meetings driven by the Bitcoin Optech folks between large businesses just talking about all the technical details of Taproot. Really getting into the nitty gritty and saying “Here is the proposed change. You are a big user of Bitcoin. What do you think? Are you happy with this? Are there some issues with it that maybe impact you in some way? Can you integrate this? Are you excited about this? Is this interesting?” All these kinds of things. Obviously it has been publicly decided at this point for years, it has been maybe a bit of a slower process for various reasons but these things happened in a way that Bitcoin has really grown up because of work by a few people in the Optech group. I think that should be the face of Bitcoin consensus changes, not the debates over specific activation methods and people saying “We need to force miners to signal at the end of a year because that is how we get this quicker.” The face really needs to be look at all the work some of these developers put in, people at Chaincode and the Optech group and Bitcoin Core contributors funded at this point by various groups, all the work they’ve put in to making sure this is carefully designed and talking to everyone they could and making sure no one in the community is going to be negatively impacted by this and it is going to really help some stuff like Lightning and some other systems and then going ahead with it. That needs to be the face of consensus changes.
MB: To put forth the user activated soft fork argument for this particular case. Again I don’t think it is going to get to that point, I don’t think it needs to, I don’t think it should because of precedence, focusing on the scars from SegWit2x, that battle, there does seem to be a bit of apprehension from a large part of the developer community to put forth an activation path. People are like “Who is going to put something forward?” The UASF crowd has been “If no one is going to do it we can do it and this is the way we think it is best to do it because we want this.” There is not a rush to get it. It is sort of a rush to get it but do we have to put this ball into motion?
MC: It has been years. Nothing is really happening, what is going on? Not so much a rush as it would be nice to get it eventually. I honestly can’t fault that argument. There are some folks who worked on Taproot who don’t have any desire to work on activation mechanisms because of basically SegWit, the mess of the activation debate there and because activation mechanisms in Bitcoin, there is no good answer. The right answer is we find a way to have changes only activate once it is clear that no one in the community is going to be negatively impacted. The changes must not be blocked by someone who is saying they are going to be negatively impacted when they are not. There is no perfect technical solution to that. There is not a way to capture that so it is ultimately a little subjective. There are some folks that don’t want to work on that kind of stuff. There are folks who do want to work on that kind of stuff. I think that conversation got started maybe only, I think I kickstarted it but I immediately stopped working on it.
MB: I feel like it was this time last year.
MC: Let me check my email. I sent an email on January 10th of last year describing what I think are good technical requirements to have for an activation method and kickstarted a little bit of a discussion. I got some responses, not from many people. That discussion only started around then and I think for a while there were only a few people involved in it and then more recently more developers have got involved in those discussions, Anthony Towns and a few other people leading the charge on that. It has been a slow process and doubly so because there is a lot of acrimony. Over time no one has really wanted to talk about SegWit and that mess because it was a painful time for a lot of people. I think over time different people have started remembering it slightly differently. It has been 3 years, that is a normal thing for human brains to do. And so I think once that conversation got started I quickly realized and I think a few other people realized that people are on some very different pages in terms of how we should think about soft forks. It has taken time but it sounds like there is a little more agreement, a little more “There’s debate over whether we should do flag days and it looks like it won’t even be an issue so maybe we should just do a normal 95 percent miner readiness signaling thing. We’ll do that and if it doesn’t work out we can revisit it and do a flag day, fine, whatever.” Not many people are going to say that is bad. They are just going to say they’d rather do a flag day maybe. There is some legitimate complaints about precedent on the other side saying that miner readiness signaling should not be viewed as a vote for or against a consensus change. Consensus changes aren’t decided by miners and there is an issue with setting precedent that miners decide consensus changes based on this signaling mechanism. That is a very valid point. I think these two opposite points about the different options on the table, flag day UASF or not, both have interesting points about precedent and drawbacks of the other side. Thus it has been a long conversation of hashing it out. That is to be expected.
MB: It is good to see people meeting on IRC. There is another meeting next Wednesday on IRC about it. I’m pulling up Michael Folkson’s notes from the first IRC meeting. Overwhelming consensus that 1 year is the correct timeout period, unanimous support for BIP 8 except for Luke Dashjr (see notes for exact wording), no decision on start time but 2 months was done for SegWit and that didn’t seem too objectionable. It seems like good conversation from Michael’s notes.
MC: I just have Michael’s notes as well. It seems like people are coming round to just doing the miner readiness signaling thing.
Comparing the SegWit and Taproot soft fork changes
MB: It is important to think about this precedent and it is why I love having you on because you are one of the most adversarial thinkers I’ve met in this space. I do think people have very high time preference about this stuff. I want Schnorr and Taproot as well but again precedents matter. We throw the fact that precedents matter at other projects that we like to critique. It would be a bit hypocritical if we didn’t exercise this type of caution and patience for a massive upgrade. Do you think this is bigger than SegWit?
MC: In terms of code, no. In terms of cryptographic changes, yeah. It is also a big upgrade in terms of new things you can do with it, debatable, you could argue either way. It is big but it is also not going to make or break Bitcoin. It is big, it is going to improve privacy on Lightning, it is going to improve the ability for people to use multisig significantly, especially larger multisig policies, it is going to over time improve privacy onchain. All of these things are important and cool and awesome but also not going to make or break Bitcoin. But in my view how the community views changes and how the change process happens is going to make or break Bitcoin.
Precedence of soft fork activation mechanisms
MB: I can agree there. There is a slippery slope maybe. You effectively do a flag day soft fork this time around but then it is jammed down people’s throats at some point in the future.
MC: I think the pro UASF argument would be that largely SegWit didn’t have any material detractors who would be harmed by SegWit directly and thus UASF was ok that it got jammed through in a month or two. But also UASF was itself a consensus change on its own. Still years later people are running round today holding on to a consensus change that was incredibly rushed, it was about as rushed if not more than the SegWit2x and New York Agreement. “Here’s code and here’s binaries. Run it and we are going to create our own chain and fork off in 3 weeks” or 2 months or whatever it was. That is also this really heavy risk and people are holding that up as a gold standard for how we should think about doing activations in Bitcoin. And that worries me.
MB: I appreciate that you are worried. Somebody has got to worry about this s***. I think sanity is going to prevail here, hopefully patience prevails.
MC: The good news is that the market isn’t always right but it is true that people in Bitcoin generally are at least vaguely aware that if they screw Bitcoin up then the market is going to punish them eventually and that there are certain things about Bitcoin that must not go wrong in order for its value to remain. That above all else people understand because a lot of people have millions and millions invested in Bitcoin, whether their business or personally.
MB: 1.5 billion for Tesla. The severity and the importance of making sure this network survives in perpetuity is so grave that caution should not be thrown to the wind. Precedence should be very seriously considered and you should lower your time preference. But that being said I am very optimistic about what has been going on recently in these IRC meetings.
Consensus forming
MC: Yeah it seems like there is a bit more consensus forming which is really good.
MB: Give a shout out to the pools, to Poolin, I think that may have given confidence for some in the developer community to begin having these types of conversations and sticking their necks out with specific activation paths. Obviously users on Twitter and other platforms signaling that they want to use some of the functionality that will be provided by this upgrade.
MC: I would love to see it more from the business community as well but all that stuff is really great to see. At least during the SegWit debacle, the 3 or 4 main groups, you’ve got business community, you’ve got pools and miners, you’ve got individual users and you’ve got developers, as much as we can get all 4 of those groups to be vocal that a change is acceptable and meets their requirements. Maybe it is useful to them, maybe it is not but at least it is acceptable and not a negative to them the better off we will be for future changes. Even if this change is minor and a lot of people don’t really need to care about it having them say “I looked at that change and I don’t care about it” is a great outcome.
MB: At the end of the day they don’t have to use it if they don’t want to because it is all backward compatible?
MC: Right. The change was made very carefully to make sure it is not risking other people’s coins with crazy new cryptographic assumptions. It is not going to massively change the market dynamics of Bitcoin or the fee market or whatever. It is a pretty straight up and down, backwards compatible, if you use it you use it, if you don’t you don’t care kind of change. It is important that that is stated as broadly as it can be. That is the gold standard for Bitcoin changes and that is how Bitcoin changes should look.
MB: Bitcoin is beautiful. It feels weird, maybe people will be affected by this conversation and that will have a little effect on whether or not this gets activated.
MC: Hopefully.
Taproot code in Bitcoin Core
MB: The Taproot code has officially been merged into Core, version 0.21.0. What is the technical thing that happens that takes it from being merged to being activated and used? The code is in the codebase technically.
MC: You can have code but there is no way to reach the code on mainnet. That code can’t be used on mainnet. Once there is an activation method, that code is there but for all intents and purposes it is not part of the Bitcoin consensus, at least not the mainnet Bitcoin consensus protocol, once there is an activation method, once there is a way to reach that code in mainnet Bitcoin that code is now merged and activated, whatever you want to call it.
MB: That was one of the questions I had in my mind for the last year. It is merged but you can’t use it. I am pumped that people can use it on Signet. Maybe businesses can mess around with some proof of concepts to be convinced to or not to support this.
MC: People can use it yeah. That is a reason to merge it first. Historically in Bitcoin Core it has always been you merge the bulk of the code changes in a major release, on testnet, signet or whatever, on your own regtest networks, you can test it out, play with it, use it in a live system and then the actual activation parameters, in essence the formal proposal of this fork from the Bitcoin Core developer community takes the form of its own minor release version that does nothing, maybe it fixes a few minor bugs, but in large part it is just a proposal and it just contains those activation parameters to make a cohesive soft fork change. “Here is a series of consensus changes in code that can be reached on mainnet in a version of Bitcoin Core. You can run this version or you can stay on a previous version, there are little code changes, there isn’t a lot of features you’re missing out on by running this new version. Run this version and now you are on the hopefully new soft fork, the activation rules will kick in.”
LDK and rust-lightning
MB: I learned a lot today, I always learn a lot when I speak to you Matt. How are things going with the LDK?
MC: Things are going great. I have been working, for those of you who are unaware, for a few years now building out a Lightning library. Not yet another Lightning node, lnd and c-lightning and whatever work great, a lot of people use them, a lot of people are really happy with them. They are robust, they are well tested, they have got a lot of users. But what there isn’t is a library that lets you integrate a Lightning node into your project really tightly. Instead of “I’m going to spawn lnd, it is going to run, it is going to download the chain itself and have its own onchain wallet” it is “Here’s a library, you integrate it, you plug in the chain, you plug in onchain keys and onchain funds to create channels and then you have a Lightning node that is in your application, it is not some separate thing that you’re controlling or talking to.” I started that maybe a year and a half ago now, Square hired a bunch of us at Square Crypto and after a bunch of back and forth this was the project we decided to work on. I wasn’t actually the one who proposed it but I think we all saw a lot of value for this potentially especially in the domain of existing Bitcoin wallets that haven’t integrated Lightning or existing Bitcoin applications that have wallets that haven’t integrated Lightning and hopefully will in the future but building a Lightning node from scratch is a lot of work. Making sure it handles every possible edge case is a lot of work. We’ve got this thing that lets you integrate Lightning into your application. I think everyone on the Square Crypto team looked at that and was like “This could have a big impact on Bitcoin down the road.” We got started working on it, the new folks were getting spun up on how all the bits and pieces worked and then Covid hit and all of a sudden we weren’t in the office together. It slowed things down a little bit but we have spent a year really digging into what was there and cleaning up. The core of the code was pretty good, works pretty well, it is super well tested, the actual APIs that it exposed were fine but could use some work. We spent the last year really cleaning up those APIs and making it really easy to integrate. Instead of just having an API where you have to download the blockchain yourself we have options. You can take it and say “I want you to download the blockchain and here is where you get it from. I am going to do my own onchain wallet.” Or vice versa you can say “You do that work”, a bunch of different sample batteries, sample implementations of things. It is now not entirely a batteries not included Lightning node, it has some batteries in it. We’ve cleaned up that a lot. We have spent a tonne of time on building language bindings so you can use it in different languages. It is written in Rust, that’s great because we can compile it for hardware wallets or you can run it in the browser but only if you call it from Rust. We actually had to build our entirely own language bindings generation utility, there was nothing out there as far as we were able to find that in any way is able to take an existing library that has complicated object oriented semantics and just spit out language bindings in a bunch of different code. All the language binding stuff that exists is really all about “You have one simple function and you just want to stub it out into a different language so that is faster.” Not like “You have this whole library that has a bunch of different things and a bunch of different interactions and you want that in language bindings.” We had to build top to bottom our own language bindings generation stuff so we’ve got that. We’ve got good C, C++ bindings if you want to use it at a very low level. We’ve got some Java bindings that people can use. We’ve got samples of using it in Swift and we are getting there on the Javascript end. You will be able to call it directly from Javascript in a web browser. If you ask “Why run a Lightning node in a web browser?” I’m not sure why you would but you can. It is this really nice cross platform thing. So we’ve spent the last year building out language bindings and we are really rounding the corner now. We have what is a rather cohesive product, it is lightningdevkit.org if you are interested, join our Slack, reach out to us and we are happy to work closely with people. We are an open source team hired to build this out so we are happy to help people out any way we can in terms of integrating and getting Lightning in as many places as we can. It is going great and we really turned the corner on having a cohesive thing that people can use now. We are really happy with it.
MB: I am pumped to see that come out. We had you, Val and Matt Odell in that episode describing what you guys were embarking on, attempting to attack this LDK project, an incredible update. I have been learning a lot from… on Clubhouse. The way he can describe the potential for the Lightning Network and break down Taproot, why that’s important, gets into cryptography, point time locked contracts something I am very excited about, he explained that for people as well.
MC: Big privacy improvement.
MB: Rendezvous routing with PTLCs seems like a game changer.
MC: There are going to be some interesting trade-offs coming up in terms of how people do routing, privacy trade-offs in Lightning. If I am honest it does worry me a little bit because existing academic research already shows that Lightning today, the privacy against middle nodes inferring who is sending money where is pretty weak and they have a lot of visibility into what is going on. Having Taproot and Schnorr specifically for point time locked contracts is going to improve that, hopefully significantly but there are a lot of other structural issues. Then a lot of especially the mobile wallets, oftentimes calculating a route right now can take a little bit of time and also importantly if you send a route and then it fails halfway there then you have to calculate another route and you have to send it again, the payment. That can take some latency and nobody wants payments latency. Downloading the graph can take a little bit of time especially if you are on a mobile phone, you open the app and can’t send for a minute while you download the graph so you can calculate a route. All these UX paper cuts. The way to solve them is to take a privacy trade-off so different routing methods, having a server calculate a route or whatever. There is a lot of really exciting research there and really exciting ways to do routing and rendezvous is really awesome. Rendezvous is less of a trade-off than some of the other work. Rendezvous is great because you can have payee privacy from the payer. You have hidden service privacy, like Tor, where the payer doesn’t necessarily know where the money is ending up which is really huge. But you also have to have that in a context where your routing algorithm considers privacy really carefully and you’re not leaning too much on middle nodes to do a lot of your work for you. It will be interesting to see where all that ends up and whether people can build a good enough UX on top of really privacy optimized Lightning routing.
MB: I’m bullish on the Lightning Network, I know I’m a fanatic but I think people are sleeping on it.
MC: People are sleeping on it in part because it is not integrated anywhere. I think a lot of the Lightning folks across different parts of the Lightning ecosystem are really excited. This year looking towards more exchange integration and institutional integration of Lightning which hopefully is going to take some volume of transactions off the blockchain itself, give people some instant transacting ability and then hopefully that also translates a little bit into mobile wallets. It shouldn’t be the case that you ever download a Bitcoin wallet that doesn’t support Lightning. That is where we are at today. You download a Bitcoin wallet and it probably doesn’t support Lightning and that sucks. Or if it does there are a few wallets, non-custodial Bitcoin wallets but then custodial Lightning because the only good way to integrate Lightning today is custodial. That shouldn’t be the case.
MB: Even better if you can abstract so you don’t even know you are using Lightning versus main chain.
MC: Right. Nor should a user ever be aware of Lightning, they should just know that their payment cleared instantly. That is what you should have. I am really bullish on it, that’s why I’m working on it full time but also I’m really bullish on integrations into existing Bitcoin wallets and new Bitcoin wallets that support it. Today a lot of Bitcoin stuff is really tightly integrated with the application level. People aren’t just downloading and running Bitcoin Core and using Bitcoin Core’s wallet to power their big exchange. Some people use Bitcoin Core but most people don’t use its wallet. Those are the options for Lightning today. You can run c-lightning, it has a great plugin system, you can do a tonne of hooking and editing it but it is still downloading and running a binary. A little less so for lnd. lnd has you download Bitcoin Core and you get the RPC API, that is what you have. It is great for many use cases, a lot of people use Bitcoin Core very successfully as a wallet on their server, whatever and same for lnd. But it is just not going to get us there in terms of mobile wallets everywhere and it is not going to get us there… I am really bullish on it, I hope we can have a really positive impact too.
MB: Thank you for all the work you do, thank you for reaching out. Like I told you, you don’t have to say thank you for having you on, you have an open invite in perpetuity until I croak or you croak or until this podcast croaks.
MC: Next time I’ll make you bribe me with beer.
MB: Yes we need to do that. I’ll drive up for that. Anything you want to end this on? Any particular note or message?
MC: I am super pumped for Bitcoin, I am super excited for it, I only worry about it because I love it.
MB: I love you Matt, thank you for coming back on, it was a great conversation, it was a great history lesson, great perspective, I hope you enjoy the rest of your night. If there is anything else you ever want to talk about in the future just let me know.