 And then you don't even know that there was a five clause script with sub options and alternative spending paths behind this. All you see is the route the tap route. Taproot activation is coming fast with ninety five percent of minor support needed and more than ninety one percent currently flagging for activation this long in the works protocol improvement has implications around scalability privacy and more. I'm Adam be Levine and this is speaking of Bitcoin for today's session I'm joined by the other host of the show Stephanie Murphy. Hi, Andreas M. Antonopoulos. Hello, and Jonathan Mohan. Hey, so in this episode we're going to discuss very briefly in as accessible terms as we could get to what taproot is why it matters and what it means in the bigger picture of Bitcoin's evolution as prices for the token it will eventually power hit all time highs. So, Andreas, can you just start giving us a quick rundown of what taproot actually is? Sure. Taproot is a package of changes being proposed for the Bitcoin protocol. And taproot is also the name of one of those changes, the other two being a change called tap script and a change called Schnorr signatures. All together Schnorr signatures, tap script and taproot together have been bundled in order to get the maximum effect in terms of privacy in a single proposal called taproot. This is planned for introduction into the Bitcoin protocol sometime in twenty twenty one. OK, so what do these proposals actually do? So these proposals do three main things. They improve the scalability of the Bitcoin system. They massively improve the privacy of the system. And they also set up some foundational scaffolding, if you like, for future improvements and new developments that can be built on top of them. When I hear taproot, I always hear the phrase scriptless scripting sort of in the same topic. Are they related? Does taproot enable that? And what the heck is a script with that script? Yes, they are related. So here's the bottom line. It all starts with Schnorr signatures and Schnorr signatures are a signature protocol that is different from the elliptic curve digital signature algorithm that is used in Bitcoin. The reason that Sadochi didn't use Schnorr signatures, even though they were invented in the seventies, is because they were in patent until two thousand eighteen, I believe. Oh, the least cypherpunk thing I've ever heard. Oh, it's patented. This anonymous cypherpunk can't use patented cryptography. Well, it certainly makes it difficult for anybody else to implement any libraries that would work with this system. So we're going to go into a bit of detail about this. And it gets a little bit wonky for people who are newer to kind of the world of Bitcoin and cryptocurrency. But the basic idea here is that when improvements come to Bitcoin or any chain out there, oftentimes they come in the form of a new type of address. Right. So an address that does one thing might be different visually. Like it might actually look different and you might be able to tell when you're looking at a transaction, what kind of transaction it is. One of the big things that this technology or at least part of this technology does is it makes it so that those things are impossible to tell apart. They all look the same. Now, at first, that's going to not work terribly well because it's a new standard and it'll just be another one of the many different types of ways that people can identify things. But as time goes on and as implementation of it becomes more ubiquitous around the different parts of the ecosystem, different wallets, different exchanges, things like that, then that problem will actually condense into just this single new type of address that will make it much easier at least to do these sorts of things privately without necessarily people knowing exactly what you're doing. The other thing is that a lot of the ways that we do things right now, as far as like if you want to have, you know, a multi-party lockbox, right? Where it's Bitcoin that are controlled by a bunch of different people or on a bunch of your different devices. Not only does that look different, but it takes up a lot of space on the blockchain and that makes it more expensive and it makes it so that fewer people can fit those types of transactions into the blockchain without pushing up the price of what it's going to take to do that. This also solves that because just as it'll make all of these different types of transactions look the same, well, it can actually take multiple types of transactions or multiple individual transactions and combine them into a single transaction, which, again, has very positive privacy implications and also has scalability implications is better for that. Now you can fit more in there and it makes it cheaper for everybody, too. So now let's get into kind of the detail of this. So Schnur signatures like elliptic curve digital signatures are basically a mathematical way of proving that you have control over a private key by producing a digital signature, which is a number that is derived from applying your private key together with a message fingerprint to say, here, this message has been signed, the message often being a transaction. Now Schnur signatures are interesting because they have a couple of very, very useful properties that elliptic curve digital signatures do not have. To put it simply, one of the really interesting properties is that you can aggregate them in such a way that the sum of a set of signatures is the same as the signature of the sum of the private keys, meaning that instead of presenting five signatures for five private keys that can be verified against five public keys, you can present one signature that is the sum of the five signatures. That can be verified against the five public keys summed together as one public key to prove that whoever signed this was in control of the sum of the five private keys as one private key. The advantage of this is that if you're presented with a single signature against the single public key that proves ownership of a single private key, you can't tell that there was actually five people who composed that together. And in that you get two effects. One has to do with scalability. It has to do with the fact that you could produce and verify one signature for five different parts of a transaction or even potentially five different transactions in a block. So that's an aggregation capability. The other is that you can hide complex scripts as a single signature on a single public key, which makes it look like a simple payment. Let's take a specific example. Let's say you're closing a lightning channel. A lightning channel is a two of two multi-seg. If you sign that as a two of two multi-seg, everybody can see it. Everybody knows it's a lightning channel. It's kind of obvious, right? But if instead you aggregate those two signatures as you're closing the channel and you present it as a single signature on a single public key, no one can tell that this is a channel. It just looks like a straightforward payment the one person signed for. And that massively increases what's called the anonymity set. It makes every payment look like a simple payment, even if it's a channel, even if it's a multi-seg, even if it's a complex script. Now, just like we saw with the implementation of SegWit several years ago, once this goes into effect, if it goes into effect, but presumably it will, you would have to move coins into a Taproot-compatible address in order to be able to do these kinds of transactions or is that incorrect? Yes. First of all, Taproot introduces a new address type. It actually uses the versioning capability of SegWit. So what we have today as native SegWit addresses is SegWit version zero, which was introduced in 2017. And Taproot will be SegWit version one. So today, addresses start with BC1Q and SegWit V1 addresses, I believe, start with BC1P. And what that means is that we will see a slightly different address format. And to get the full benefits, you have to start using Taproot in your wallet, which means your wallet has to implement Taproot. So we're going to see a hodgepodge of wallets implementing this over time after it gets implemented in the Bitcoin protocol. Yes. So like the previous changes, this is backwards compatible. You don't have to use it. It will become available. Once it becomes available, it's a valid type, and then you can use it. If you decide to use SegWit V1 type scripts and addresses, then you can use all of the different functionalities. Now, so far, I've only talked about Schnorr signatures and the aggregating scalability and privacy capabilities of that. There's a couple of other changes happening here. So another big part of it is this idea of scripts. So scripts are basically like Bitcoin's version of smart contracts, right? You can build actual smart contracts at higher layers built on top of Bitcoin, but Bitcoin itself does support something that feels and works a lot like simple smart contracts in the form of these scripts, right, Andreas? That's correct. A script is a very simple type of program. And in Bitcoin, the programs only do one thing. They give you a true or false answer. True means you are allowed to spend this. False means you are not allowed to spend this. So if you can produce from the script an answer that is true, that means you fulfilled all of the conditions and you can spend it. So Bitcoin has a scripting language that allows you to specify conditions to spend something. And the most obvious condition is show a signature that proves you have the private key and then you can spend this. That's obvious. And it's a fairly simple short script. It gets even shorter with Snore signatures and Tapper. But that's not really the big scalability improvement. The big scalability improvement comes from more complex scripts. So if you have a complex script that says, here are 10 keys. If three of these keys sign, then you can spend it. Or if two of these keys sign, but 90 days have passed, then you can spend it. Or if this key signs while producing a hash of this other message and also 120 days have passed, then you can spend it. So that's three or four different conditions. And these conditions are specified in a script. Now, if you wanted to spend with the script, you would have to present the entire script and then show which part of it you're using and provide all of the prerequisites. So you could say, here's the entire script, all of the conditions that are required. And also I'm using the second clause and I have two keys and 90 days have elapsed and therefore I can spend it. Great. And the Bitcoin network will recognize that and allow you to spend it. The problem is, that's a very, very long transaction. And if you're signing lots of inputs, it gets longer and longer and longer. What this Tapper enhancement does is it hides all of these different conditions in a tree using a technology called Merkle trees, which is also used in compressing all of the transactions into a block. And so instead of providing a list of conditions through a long script, instead you provide a tree and you say, is this tree specifies all of the conditions? I'm only going to show you the hash of the top of the tree. And when you want to spend it, you say, I'm going to use the second clause in the tree. Here's a proof that shows that that clause was part of the tree, but I'm not telling you what other clauses exist. The first, third, fourth, fifth and sixth clause that exists, you will never know about. I don't even need to show you. And therefore the proof I provide is very, very short. That concept was first introduced as a concept I believe in 2014. It was called Merkleized Abstract Syntax Trees. We talked about it on the show many times. We talked about it extensively in 2016 and 17 in the run up to Segwit and Tapper finally makes it a reality. So this feels kind of zero knowledge proofy where you can demonstrate that something is correct without having to disclose what the something you're proving correct is. Is that sort of in the same ballpark? Somehow, yes. Essentially, you're shielding all of the parts of the script that you're not exercising to spend. And that's the Merkleized Abstract Syntax Tree part of Tappered. But there's an even better one, which is that in the example I gave before, you say, here's 10 keys. If three of them sign, then you can spend. If two of them sign and you have 90 days, then you can spend. If one of them signs and you have a hash and 120 days, then you can spend. But in almost all of these types of scripts, there's also the case where everyone agrees. This is called the K of K, the unanimous option. And that is simply all 10 keys agree. And in many of the protocols that you construct over Bitcoin or corporate spending environment or other types of situations, it's actually always possible to get a unanimous consent instead of the individual spends. And you might be able to make the vast majority of spends with the unanimous consent option. With Tappered, the unanimous consent is produced as a single signature that is aggregated from all 10 keys, for example, against a single public key that is aggregated against all 10 public keys. And that appears to everyone on the network as a simple payment. And then you don't even know that there was a five clause script with sub-options and alternative spending paths behind this. All you see is the root, the Tappered. And that's why it's called Tappered. And so how this gets to being more privacy focused is if we compare Bitcoin to ACH, the world we're in right now is the Ethereum world and the Bitcoin world, where if ACME wants to pay Warner Brothers, you not only see the payment occurring, but you see the entire contract and the negotiation and the agreement and all of that gets disclosed. But what Tappered's going to allow you to do is when ACME and Warner Brothers has a deal, you just see the end of the deal, which is, hey, some money went from ACME to Warner Brothers. And in fact, you might not even see that, because if ACME and Warner Brothers are represented by some kind of aggregating payment channel, like through a lightning channel, you'll see an aggregated signature that looks like some other party that's unnamed has signed for this. But what you don't see is that behind the scenes, that's actually 10 different payments being made. So you get all of these aggregation capabilities and aggregation also means privacy. So that's one of the big capabilities. Now, all of this is immensely technical. For most Bitcoin users, what this will mean is that their wallet will be able to do an upgrade to the current address format. It's a relatively simple upgrade for wallets that have already implemented SegWit, implementing SegWit v1 as opposed to just SegWit v0 is not a huge upgrade. The code is already integrated in the test libraries. It's running on the test networks and the liquid network. And it's already incorporated in all of the application level libraries that build on top of Libsecp. And so it should be a fairly easy upgrade for wallets. And once that's done, the obvious thing that's going to happen for most users is simply their transactions are going to get cheaper. That's it. But what's happening for more sophisticated users is that all of their scripts that used to be a needle in a haystack now become a needle in a needle stack. I guess I was wondering, like, if there's any good reason that this should not be implemented, like, why would someone oppose this? Or what have the mice just not, like, done their research on it? Or is there any kind of security concern as Bitcoin gets more complex and potentially adds more features? There's always, like, a trade-off between, you know, security and complexity? Stephanie, my gosh, I never took you for a status. There's no such thing as one solution in the free market. There's 50 solutions. One of the issues with Taproot is it's the Ben and Jerry's delight of which flavor do you go for? I think Jonathan's correct in one way, which is that there have been several rounds of review and improvement on the whole set of the proposals. And we're getting to the finish line where the code is getting to stability. The proposals are stable. The address format is stable. In fact, the latest address format was only proposed last week. Now, the next part is difficult. The next part is activation of this on the Bitcoin network. And in the past, we have seen, to the shock and horror of those involved, that what should have been a relatively non-political scalability improvement became very, very hotly debated, became a lightning rod for a political battle of power, and eventually became a very difficult activation. I think a lot of the Bitcoin Core developers and wallet developers do not want to repeat of that scenario. So this is being approached very, very carefully to make sure that it does not become a fight. A lot of consideration, a lot of review, a lot of testing, and an activation process that gives everyone a lot of time to decide. Now, contrary to what Adam hinted at the beginning, we do not have an activation process yet. The activation process itself is still being debated. One possibility is what's called a BIP9 activation, which is an activation where you have to reach a threshold of 95% to which point it gets locked in, and two weeks later, it's activated. But there's no deadline. This can be below activation forever. This is what was used for Segwit. It's not a very popular option because of the opportunity to politicize that decision. An alternative is called BIP8. BIP8 is a threshold activation with a flag day, which means miners have the opportunity to signal their approval for this change. And if 95% of the miners approve of this change and signal that in their blocks, then the change gets locked in, and two weeks later it gets activated. But if they don't, then at a certain date, it gets locked in and gets activated anyway. So they can activate it sooner, but they cannot postpone it. And so that's being looked at as a better approach. So recently, in order to decide how best to activate it, one of the developers did a poll. It's a very, very old-school approach. They posted on various forums and said, hey, if you are interested in telling me as a miner what you think we should do, send me your opinion. Do you think we should go BIP9? Do you think we should go BIP8? Or some other combination? And are you in favor or not of Taproot? And eventually, they got more than 90% of the miners by hash power to signal privately by messages or through public postings and tweets that, yes, we support Taproot and we would prefer BIP8, or we would prefer BIP8 with a one-year threshold, or we would prefer BIP9 modified this way. And from that poll, that informal poll, I expect over the next few months, we're going to see an actual activation plan be put in the code and the possibility of activation sometime in 2021 or 2022. This is not imminent. This is not coming to a blockchain near you in the next few months, but we are on the final stretch. Okay, that's really interesting, just like you brought up the activation of previous changes was controversial, to say the least. But this time, it seems like there's been more of an effort to build consensus before anything happens, and that's interesting. We could do a whole show about that. Well, we're definitely going to do a whole show all about that. And let's be real, the reason why that particular one was contentious is because there were two narratives about what Bitcoin was going to be. And different priorities came along with those narratives. And really, what we saw was a battle of narratives where one was a winner and we moved on from there. I think it was more fundamental than that, which is it was a battle of wallets because at the end of the day, it was the miners that signaled. And Jihan had access to a technology called ASIC Boost, which if he used, if Seguin didn't exist, could make him more money, but he was never going to use it. So don't worry about it, guys. Well, that's another angle too. But like I said, this is a complex topic, and I don't think we can simplify it for the end of this episode. So let's save it for one in a week. Let's fight the scaling debate again now. In the last show, we talked about big banks and behemoth institutions that want to make changes to Bitcoin. And Tapper as a package seems like a change that upholds privacy. Ding, ding, ding, ding, ding. Yeah, which is something that big institutions wouldn't necessarily support. This is where it gets complicated. This actually, in some ways, it throws down the gauntlet. This is a proposal to improve privacy in Bitcoin in a way that also opens the door for future privacy improvements on top of it in such a way that it will make it challenging for regulators to keep up in a game of whack-a-mole against decentralized innovation. So there is a possibility, and we are already seeing pressure for miners to conform to expectations of regulators about what does and doesn't go into a block, and to do various kinds of surveillance and control of block contents. Now, that may start putting miners a bit more in the crosshairs of regulators, and we'll see. Hopefully, this isn't the fight. Hopefully, this one just sails through over the next year or year and a half. And we get to a more private situation with Bitcoin. We get better privacy. We get better scalability. And then we live on to fight another day. And so with all of that said, that is all the time we have for this episode of Speaking of Bitcoin. Thanks to all of you listening and to my fellow hosts for sitting in on today's session. Stay tuned for our next episode where we'll be digging into the good, the bad, and the ugly of blockchain voting. We'll see you next time.