 Together with Taproot, this would mean a significant reduction of the on-chain size of lightning transactions and a significant increase in privacy. All of which is great news for everyone. Hey, folks. I'm Adam B. Levine, and this is Speaking of Bitcoin. As always, I'm joined by the other host of the show, Stephanie Murphy. Hi. Andreas Antonopoulos. Hello. And Jonathan Mohan. Hey, hey. So a couple of episodes ago, we dug into Taproot, the much-anticipated Bitcoin improvement proposal that rolls up Schnorr signatures and a few other seemingly small but collectively major changes to the way that the Bitcoin protocol works. Well, just a couple of months later, we've seen some pretty major moves. Andreas, you've been watching this one pretty closely. What's going on here? Well, at first, things got very, very significantly derailed after what was seemingly a minor point about activation parameters became a huge protracted debate with no compromise. And I started feeling like we're seeing a repeat of Segwit and a very big delay in activation. But now things are back on track. A couple of months back, the original plan proposed was to do a modified BIP 8 activation. And then there was one parameter of that activation, which was whether at the end of the activation period, if the miners voted for or not, whether to lock it in regardless, meaning whether to do effectively a flag day at the end of the voting period. So the way activation works, you start with a proposal, in this case, the TAPRID proposal, and then miners have a period of time to vote by indicating that in the blocks that they mine, and if the voting exceeds a certain threshold that it gets locked in. In the past, that became problematic because the miners got to veto certain features, as happened in Segwit. Then a different way was proposed for TAPRID, which included a flag day activation. Many features in Bitcoin have been implemented this way, where simply on a certain date, once that date passes, or once that block height passes, the feature is activated. The miners don't get to say no. And this was a compromise, where the miners get to say yes early, but if they don't say yes by a certain date, it activates anyway. And the question was, how would that be locked in? And then the compensation derailed. A lot of people were worried that the miners might attempt to veto this again, or to try to extract some kind of concession or something like that. And they wanted to preemptively force the miners' hands and not give them too much power. And others were like, that's unnecessary. If we have the developers preemptively forcing the miners' hand, that gives too much power to the developers. And we went back into the exact same thing that happened during the scaling debates, where it became a question of not what should the decision be, but who should have the power to make a decision. That's when I started feeling like, not again. Yeah, I can imagine. But I mean, it is a kind of important decision. And certainly, I think that we've seen the pendulum swing on this, where it felt like on the early days, developers had sort of the kind of philosophical leader, right? But they weren't the ones that did it. It still relied on action coming from the miners. And then there were perceptions certainly that miners had too much or abused what power they did have. And so things kind of swung back towards the developers. And now we're kind of in this oddly tense spot. I mean, Andreas, is there really anyone who disagrees with that? Is there a concern that the miners will actually reject this, not because of the power dynamic, but because they actually don't like the sort of protocol change that's proposed here? No, not really. I think, first of all, because there have been various forms of polls that have been applied. Now, of course, if you have no skin in the game and you're not activating the actual feature, you can lie when asked whether you would vote for it or not. But so far, more than 95% of the hash rate had agreed to a modified BPAT activation. And there was some disagreement over whether at the end of it it should be locked in or not. Most of the miners did not want to be forced to lock it in for obvious reasons. But there wasn't any concern that TAPRIT was in any way controversial among the miners or that the miners objected to it in any way. Then again, no one thought Segwit was controversial. And that was part of the debate, which is, well, no one thought Segwit was controversial because at the time that we were debating Segwit, we didn't know about ASIC boost and some of the political games that were happening behind the scenes to boost the hash rate of some ASIC manufacturers. Okay, so now that we are where we are, and it feels like there's sort of broad consensus and we have this mechanism that's in place, talk to us a little bit more about that. Has it actually been decided on or does it just now look like there's consensus, but we're still waiting for a moment? So the logjam was broken by a new proposal, and this new proposal was a concept called a speedy trial approach, which is basically fail fast and fail early. Let's give the miners a chance to simply say yes and do it very, very quickly. And if it works, great, we're ready. And if it doesn't, then we can find a different activation mechanism to do afterwards after we've done the speedy trial. So rather than say a two year process where at the end of the miners tried to veto it, we would be left with nothing. This approach says, give the miners a chance to just say yes, but let's do it by August very, very fast. And if they say yes, we activate in November. If they don't activate by August, then we can try other methods afterwards, after August to approach this differently. So the parameters for this are as follows. The start time is April 24, and the end of the voting period is August 11. Anytime after April 24, which is just two days from this recording, but nothing actually has to happen by then, anytime after that, if in any two week period, which is the difficulty retargeting period, 90% of the blocks mined, meaning 1,815 out of 2016 blocks in that period indicates support for TAPRT, then the feature activates. And if by August 11, that threshold has not been exceeded not once in any difficulty period, then the feature failed. If it's activated before August 11, then it goes into activation at a specific block height, and that's been agreed as block 709632, which is estimated to be somewhere around November 2021. So we have a voting period April to August. And if in any part of that voting period, in any two-week length of that, 90% of the miners are signaling support for TAPRT, then in November of 2021, it turns on on Mainnet and can be used by everyone. And if it fails, but will know by August 11th, and then we can try something else. So this is called speedy trial. It is a pull request for Bitcoin Core, and it is currently supported very strongly by the vast majority of core contributors. And it's expected to enter into the 021 pre-release version of Bitcoin Core, so that users and of course, miners can start deploying that version of Bitcoin Core within the next few weeks. So I have a couple of questions. One is that, as we talked about before, once TAPRT gets activated, or once we see the activation of this proposal, it could mean that there's more privacy available in Bitcoin, also more grouping transactions, and it could lower transaction fees and save some space as well. But regular people maybe won't see those benefits right away, because wallet software still has to integrate this just like it did with SegWit. That's correct. However, keep in mind that TAPRT-capable code, Snore signatures-capable code has been part of Bitcoin Core for testing purposes for almost a year now, and the code has been in various stages of testing and review for almost three years now. So this is the end of a long process. Now, it won't exist in wallets quite yet, but you're going to start seeing it implemented in places where the need for some of these improvements are greatest. I'm most excited about what this can do for the Lightning Network, where the efficiencies are huge, and we might also see it in areas where we need more privacy, such as perhaps various privacy mixing technologies or privacy-focused wallets. Okay, so it could be actually accessible to most people in a limited format earlier than it takes for every wallet to catch up. That's correct. In Lightning, in fact, there's been a parallel proposal to be able to upgrade payment channels to use a new form of script called a point-timelocked contract or PTLC that replaces hash-timelocked contracts or HDLCs, and together with TAPRIT, this would mean a significant reduction of the on-chain size of Lightning transactions and a significant increase in privacy, all of which is great news for everyone, really. If you make Lightning more efficient and if you make Lightning more private, it means even more optimization at every layer. That's probably going to get implemented faster than some of the other areas we'll see. But then again, one of the reasons that we want the voting to be done by August, but the feature doesn't get activated until November is so that the various developers have plenty of time to put the feature into their code and test it extensively if they haven't done so already. So I really look speedy trial and it's not even because I think it'll activate, but if everyone's presenting as if they have no problem with it, I think that speedy trial is just a good test for actual activation because it'll give you a year to know who didn't say yes, and then you can discuss with them why they didn't say yes and sort of force the issue of potential drama now rather than wait a year and discover what it is. Because if everyone's saying there's no issue with it, then there really shouldn't be an issue with enabling it through speedy trial versus waiting a year for no reason. Yeah, that's exactly the case. And really, I mean, this is not even three and a half months. So it's one of those fail fast, fail early type solutions. And on the one side, from a practical perspective, it allows us to test the waters. And from a different perspective, it's a put your money where your mouth is. And if you really meant what you said that you support it, now we're going to put that to the test because you haven't allowed us to prove it in a block. And we'll know exactly who does and doesn't support it because obviously, this is going to be a public vote. It's going to be right there in the coin based transaction of a block that's mined. And we'll know precisely which mining pool supported which independent miners supported. I also really like it just in terms of the direction forward for medical consensus, because I feel like one of the things I dislike most about the direction of Bitcoin is just how conservative the development team has gotten to the point where I think it's calcified too much. And I think that anything that's a feature update to medical consensus where you can fail quickly, but harmlessly, that pushes the needle towards feature upgrades is like, I think one of the most sorely missing things that Bitcoin needs to reverse calcification because it's way too young to be the amount of calcified that it's become. And so I really wish that things like speedy trial where failure is an acceptable outcome and nothing is harmed by it is really the direction that medical consensus goes when making these types of decisions. Yeah, I mean, that's a very good point. So from that perspective, maybe we should rename it from speedy trial to CLR or Drano. Oh, I get it. For those who don't know, CLR is a chemical used to remove calcium from pipes. Okay. So I mean, the good part here is that it feels like we're going to get an answer on this relatively quickly. And once we've got that answer, then we'll go into kind of this longer period of time that Stephanie was talking about where ultimately, although it's now in the protocol, well, in order for us to actually use it and for it to be really useful to the protocol, it needs to get implemented in all of these different places that aren't at the protocol level, but are at individual application level. Now, last time we were talking about Segwit, I mean, it took a lot of these exchanges and wallet service providers a long time. Certainly there were enthusiastic ones who kind of jumped on it. I feel like there's some that still aren't Segwit. This is what I'm saying. Yep. So like, is that just normal for like Bitcoin updates and upgrades moving forward is that we'll get like this initial chunk of implementation from like the really ideological or really kind of committed users of it. And then there's like this really long tail that might take like five or 10 years maybe before it really rolls out comprehensively. That's just internet infrastructure and technology. I mean, now that Bitcoin is a trillion dollar economy, a trillion dollar industry that's a consumer facing product. I think it's fair to look at comparable technologies and deployment rollouts there. So if you look at IEEE, look at every time IEEE has a codified standard like USB 3, and then look at just how quickly or slowly it takes to promulgate that out to the edge of actual consumer adoption. And the more Bitcoin gets to be in market's cap in adoption, like just because you come to a feature update doesn't mean the next day everyone's using it. And I don't see two years from feature upgrade to mass adoption in deployment as a bad thing that's actually rapidly adopted in terms of like banking standards or electronic standards. Yeah, there's a big difference between protocol level features and user interface or frontside application features in terms of the calcification or protocol ossification we were talking about earlier, which is that on the back end everybody has to be in lockstep. We're talking about consensus code. We're talking about critical infrastructure. It requires a lot of different constituencies to agree. And that's moving fast, or at least faster than it was a few months ago when it seemed to be a bit stuck. But once that's in place, you don't need lockstep agreement anymore. Those who need it will use it, and they don't have to wait for everybody else to implement it in order to use it. Now, we're not going to get all of the privacy benefits. We're not going to get all of the fee optimization benefits if half the wallet's out there can't send to an address. However, keep in mind the address format isn't changing really here. We've got essentially the same address style as segue addresses. And that was a pretty big front end change, which required a lot of work on the user interface. This isn't such a big change for most wallets to be able to support at least sending, even if they don't do native tapered themselves. And for those who need it, like the Lightning Network, well, that can go ahead and happen very, very fast in the Lightning Network without being affected by what other wallets are doing. So with the economy of this size, with the range of applications and use cases we have, it's normal to not expect everybody to value these capabilities the same and to have the same urgency. But one of the things this does point to is that, as I've said before, and I've said pretty strongly, wallet development and maintenance, ongoing maintenance is still a problem. It's underfunded, it's difficult to monetize, and it's the slowest moving part of the infrastructure. And that's where the bottlenecks move eventually. Okay. So one other element just before we wrap this up, we've talked about taproot in the context of kind of privacy and obfuscation on the blockchain. And that's something that, again, as we're moving into this period of time where it feels like Bitcoin is going to become more or Bitcoin company, I should say, are going to become more regulated. I mean, we flat out know that the big exchanges out there feel like they cannot just send to any address. They have to send to addresses and they have to be receiving coins that they feel like they can trace provenance on in order to do their sort of compliance diligence. Now, taproot makes that potentially a lot harder for them. We've been talking about it earlier, wondering, will this get adopted by the big exchanges out there that are trying to stay legal? Will they actually fight this? And will they push back against this sort of potentially privacy enhancing technology making its way into the protocol in a way that could make their business more difficult? I'm curious if we're still concerned about that, or if we think that this is now happening so fast that maybe it doesn't matter, and we slide in under the wire before perhaps some of these more controversial elements become really recognized. I don't know where the controversy around taproot activation would be other than from potentially a regulator. And I don't know if a regulator would have any issues if that would move any sort of mining signaling related consideration. So the reason why Segwit was such a big deal was that it was proper Bitcoin consensus that had the issue that were particular miners. I don't know if a secondary group having concern would translate then to minor concern in the same way that Segwit so directly did. So I just like everyone's very cautious. It's sort of like you had that one really bad breakup and now you're conflating every potential boyfriend with your ex when it comes to Bitcoin feature updates. But like there's nothing here to think that you know the new guy is anything like the last guy. It's just everyone's still kind of in shell shock. I like to think of taproot as the Luke Jr. of upgrades. People like to complain and say that it is kind of controversial, but at the end of the day they have no problem with it and it's rather useful. Well like I said folks this is a topic that we'll be watching it's another kind of milestone in a somewhat long path but it's pretty good sign and looks like with this speedy trial approach we're going to get to see in real life whether or not this thing is controversial or not. So best case scenario it goes in and we get to start seeing that adoption curve. First case scenario then we figure out you know that it turns out that it was actually controversial and people just didn't want to talk about that until now. So I think that wraps it up for us on this episode of Speaking of Bitcoin. Today's episode featured Andreas Antonopoulos, Stephanie Murphy, Jonathan Mohan and Adam B. Levine. This episode was edited by Jonas and featured music by Jared Rubens. You can send us an email at adam at speakingofbitcoin.show and leave us a review on your favorite podcast player if you like what we're doing. Until next time, we'll see you then.