 Robin asks, why have different flavors of Segwit addresses? My wallets now give me the option to pick from either legacy, batch 32, or P2SH addresses. As I understand it, I want to have private keys to be Segwit-enabled addresses, so that less data needs to be paid forward to publish on the blockchain. Now that both have been implemented for a while, is there a winner yet, or what is the benefit of being different and incompatible? It's not really a matter of winner or better, it's really a historical progression. Legacy addresses, meaning those that start with a one, are not Segwit-enabled, meaning that you cannot use a segregated witness signature in order to publish a transaction from an address that begins with one. That's going to increase the fees that you have to pay to make a transaction, pay a transaction from an address that starts with one. The second class of addresses you mentioned are P2SH. P2SH are addresses that start with a three, and these are scripts wrapped in a pay-to-script hash. Addresses that start with a three can be a variety of things. You may have heard of them being referred to as multi-sig addresses in the past, that's because that was the main use for three addresses with multi-sig. The most common script used, but they can be anything. They can be lightning endpoints, which can also be expressed as P2SH addresses, of course. They can also be Segwit scripts. If they are Segwit scripts, that particular formulation is called P2SH-wrapped, P2WPKH, or to break that up a bit, that's a pay-to-witness public key hash, which is a native witness address or Segwit address, wrapped inside a script and expressed as a pay-to-script hash. Which is why it has a three, and it looks like an old multi-sig address. These are kind of a bridge. These are addresses that can be recognized by any wallet without any upgrade. They give you the benefit of spending with a Segwit transaction, or spending the input with a Segwit signature, which reduces your fees, but are accepted by any wallet as a destination address, because they are P2SH, so old wallets don't need to know anything about Segwit in order to pay to them. That makes it easier to upgrade to Segwit transactions without having to expect everybody to upgrade their wallet. But that comes at a price. The price is because you have the script wrapping, the P2SH wrapping, it makes the signatures a bit larger, quite a bit larger in fact than native Segwits. It's better than legacy, but not as good as native Segwits. Betch32 addresses that begin with BC1 are the ultimate goal. Those are native Segwit addresses, they don't have any of the fluff around them, they're basically just a Segwit V0 script. That Segwit V0 script is the shortest, most compact way to express a Segwit address. It allows you to spend using segregated witness signatures, which reduces your fees. It takes up less space than a P2SH wrapped Segwit address. However, in order to get paid to a BC1 address, the person paying you needs to have a wallet that has been upgraded to identify native Segwit addresses as valid Bitcoin addresses. That means you have to wait for people to upgrade. I would say we're probably at about 50% coverage right now, and that's just a wild guess based on my experience. About half the wallets I see out there now support paying to a Betch32 address, which makes it easier to use a Betch32 address nowadays. But it still means that some of the customers you might have, or some of the people you may want to get payments from, will have a problem. Their wallet will not be able to pay to a Betch32 address because it hasn't been upgraded. So, what should you do? You should gradually try to upgrade all of your interactions to using native Segwit Betch32 addresses. They're easier to read, they're easier to transcribe. They have better error correction and error detection capabilities than base 58 and coded traditional addresses. They have more compact signatures and more compact scripts. They save you on fees, but you have to wait for the wallet manufacturers to upgrade. So, this is a difficult decision. It depends on how broad of an audience you have for making payments. So, if you're running an e-commerce store, for example, and you're selling stuff to the general public, and you expect people to come with a hundred different wallets, then you may want to stick to P2SH-wrapped Segwit addresses. Just to ensure that everybody will be able to make a purchase on your store, they don't need an upgraded wallet. If you're dealing with a smaller circle of people, most of whom are more advanced, early adopter users, who have more sophisticated wallets, then you may be able to upgrade to native Segwit Betch32 addresses sooner. I have a combination. I have some wallets that are Betch32. I have some wallets that use P2SH-wrapped Segwit. I even have some wallets that use legacy addresses still, and that way I use the right wallet for the right job. George asks about the space gain of Schnorr signatures. What is the percentage space gain that we should expect with Schnorr signatures? It actually depends on the number of different factors, because there are two places in which Schnorr signatures create space gains. The first one is the signature itself. Schnorr signatures are simply shorter than ECDSA signatures. You automatically get, and I think it's somewhere between a 15-20% reduction in the space required to encode Schnorr signatures. Furthermore, most of the proposals for Schnorr signatures also include a change in the way the signature is encoded. Today, on the Bitcoin blockchain, signatures are encoded using a DER encoding. That's not space efficient, because it doesn't matter in most of the applications for digital signatures, space walls and the consideration. On a blockchain, it is. It's a very big consideration. The DER encoding we use for ECDSA already has some room for improvement. Schnorr signatures are more compact. Those two efficiencies together, with an introduction of Schnorr signatures, we changed the encoding and the signature itself is shorter. 15-20% gain from there. But there are additional gains, because one of the things you can do with Schnorr signatures is signature aggregation. Instead of, for example, having a signature on every input in your transaction, if you have a transaction that has two or three inputs, now you need three signatures, one per input. Each of those signatures will take up 30-some bytes of signature space. With Schnorr, what you can do is produce one signature that is an aggregate signature for all three inputs. That is a 66% reduction in space, because you have now replaced three signatures by one. That signature can be computed by yourself, if you have three inputs that all belong to you. You can also do some forms of multi-party computation in order to produce an aggregate signature for inputs that are not owned by the same person, for example, in the case of a coin join or other multi-party transaction. Then there is a possibility of doing aggregation across transactions, which is an even more ambitious goal. Theoretically, at least, you could do one aggregated signature for an entire block. That has its own complications, not easy to implement. That would be a huge space gain. So, it depends how Schnorr signatures are applied. At minimum 15% in space savings, probably close to 30%, and with just transaction-level aggregation, another 50% or 60% reduction in space because of Schnorr signatures. The follow-up question from George would be, would you vote to lower the block size when you have the implementation of Schnorr? I think not. I think that this gives us an opportunity to effectively increase the capacity of the blockchain without increasing the base block size. I don't want to go backwards in that, but that is a personal opinion. It is not a very strong personal opinion. It is one that I am open to persuasion. I don't currently buy the argument that the reason people are not running more full-notes is because of the bandwidth and disc costs of the current one-megabyte base block size, or four-megabyte block weight that exists in Bitcoin's blockchain. Therefore, I don't think that is a huge problem today. Therefore, I don't think we need a radical solution like a reduction in the block size. Most people who propose this are talking about a temporary soft fork. Still, I don't really see the need for that, but I could be persuaded otherwise. Santiago asks, what is taproot? A code change designed to increase Bitcoin's privacy? I would like to know more about the taproot soft fork upgrade proposed by Peter Wolk. How does it work, and what are its differences compared to zero-knowledge proofs or other approaches being explored, for example, by Ethereum? Taproot is very different from a zero-knowledge proof. It is not really a direct privacy solution, as zero-knowledge proofs are. What it does is it erases the distinction between a payment to a public key and a payment to a script. At the moment, on the Bitcoin blockchain, you can distinguish between payments to public keys or public key hashes, pay to PKH, as they're called, because they start with a one. One addresses are simple Bitcoin public key addresses, or double hashes of public keys. Addresses that start with a three are a script. That might be a multi-sig, which is the most common example. A lot of people think that's a multi-sig. It might be a segwit wrapped in a script, or it might be some other script, like, for example, a lightning channel. But you can tell the difference between a script and a public key. What taproot does is it erases that distinction. It makes all script and public key payments look the same when they're submitted on the network. When you try to spend them, you can either choose to spend with a public key or a script. Not just a script, but a merkle tree of multiple script clauses, of which you only reveal one. You can either spend it as a public key with a regular signature, or you can spend it by revealing part of a script that's in a merkle tree. This is really interesting, because it creates a situation where all payments look the same. You no longer distinguish between scripts and public keys. There's a very interesting fact here that, because of the way Schnorr signatures work, which is combined in this proposal, or which has been proposed simultaneously with taproot, with Schnorr signatures, you can do additive signatures. What that means is, let's say you have a three-of-three multi-sig, and all three people agree to spend it. In traditional terms, you would have to do a three-of-three multi-sig spend, which is a script, presenting three public keys and three signatures for everybody to see. Everybody knows it's a three-of-three. When you spend it, it's going to be very visible. With Schnorr signatures, what you can do is take the three public keys, collaboratively join them together, essentially adding them together, and create a master public key, if you like, and then add all of the signatures together, and create a master signature. The three parties can sign the public key of their joint public keys with a signature that is their joint signature. Then it looks like a straightforward payment to a public key. You don't know it's a three-of-three multi-sig, because they all agree to spend it. There are many, many scripts in which you have various thresholds or conditions. If all of the participants agree, you can just do a joint signature like that, and make it look like a simple payment to a public key with a simple signature. The combination of these Schnorr-additive signatures and TAP routes then makes it for very interesting obfuscation technology. It's not directly related. It's not a direct-solution privacy. It's an indirect-solution privacy. It allows you to do other things to enhance your privacy, too. That's a very exciting proposal. Another typical example here would be closing a lightning channel and making a payment to the two participants. A lightning channel is a two-of-two multi-sig, but in most cases, the two parties that are participating in the lightning channel close it cooperatively. Instead of closing it with this massive script that says, This was a lightning channel and we're exercising the cooperative closed script. What they do is they just join their signatures, present it as a TAP route public key, and a signature. Then it looks like somebody just spent that input with a regular signature to two addresses. You can't even tell it's a lightning channel. That's what TAP route is. It's part of a bundle of proposals. TAP script, which is an upgrade to the scripting language, and Schnorr signatures that have been proposed to be launched together. The BIPs were written by Peter Woollah, but they actually are the effort of multiple developers. Peter Woollah did the reference implementation to demonstrate how it would work. This would be a software upgrade as Segwit v1. Segwit v0 was the one that was launched in August of 2017, the first version of Segwit. We always start indexing from zero in this case. The second version of Segwit would be Segwit v1, maybe launched in the next couple of years. It would be something along the lines of TAP route, TAP script, and Schnorr signatures. On the side, if you're interested in hearing more about that, we just recorded a great podcast with Let's Talk Bitcoin, with guests Jonas Snick and Peter Woollah. We talked extensively about what TAP route is, what TAP script is, what Schnorr is, and the impact these proposals will have on both scaling and privacy. You can catch that in episodes 401 of the Let's Talk Bitcoin podcast. We won't put that in the Q&A, but for the people watching the live, you might enjoy listening to those a lot more. You spent an hour talking about this topic. Privacy timelines. Craig asks, it sounds like, fortunately, Bitcoin will become anonymous once different upgrades are made. Could you give us the timelines of when Schnorr signatures, confidential transactions, TAP routes, and graph routes will go online in Bitcoin? Will this give total anonymity or further upgrades be necessary, and if you know, when will they come about? Craig, I wish I could share your optimism. It takes a lot of different approaches to achieve privacy, and privacy is an ever-moving target, because you've got to think about this in terms of an adversarial arms race. Meaning that, while people are building privacy-defeating technologies, developers in Bitcoin are building privacy technologies. And, of course, in many other open blockchains, especially those that are privacy-focused. So, if we have better privacy technology in Bitcoin, then that then gives all of the incentives for the surveillance companies and the analytics companies to continue to violate the privacy of millions of people by escalating their capabilities. And, of course, when they invent something new, that then becomes the new state-of-the-art, which very quickly leaks or gets shared, so that, of course, you can't have just the good guys using surveillance technology. In fact, the bad guys are the ones using surveillance technology, but that goes from the bad guys to the worse guys, to the even worse guys, to the dictators and murderers and brutal regimes. So, one of the problems with this is that the arms race causes this escalation of technology that falls into worse and worse hands. So, yes, we're looking at a number of technologies to improve the privacy of Bitcoin, nor signatures is a bit helpful, especially with threshold signing, as I mentioned in the previous answer. Taproot and Grafroot. Taproot is likely to be implemented sooner, Grafroot maybe a bit later. Confidential transaction is not currently scheduled for an implementation. It hasn't been finalized as a bit. It currently is being tested on the elements sidechain, but not on Bitcoin. So, will this give total anonymity? No, absolutely not. And you would need to combine these techniques with various forms of coin join and other privacy techniques, like for example, how wallets use change addresses, how they order outputs, what fingerprints they leave as to the transactions they're constructing, preferably avoiding leaving any fingerprints, how they do things like deterministic signing, and things like that. All of these activities increase privacy. The more you do, the fewer fingerprints you leave in the transaction, the harder it is to identify what kind of wallet was used, which means you can do less statistical analysis. And of course, if you can use various forms of confidential transactions, encryption, coin join, etc., it makes it even better. I expect that there will be a fair degree of pushback against strong privacy in Bitcoin. I think it's a big battle that we need to fight. And I think that we need to win that battle, because if we don't have a stronger privacy in Bitcoin, that gives many different attackers a way to attack Bitcoin users by violating their privacy and punishing them for using Bitcoin by revealing their identities, which weakens, of course, Bitcoin. So I hope we'll see more and more upgrades in the future, but this is not going to be easy. And more importantly, it's not going to end. We're going to need to keep increasing the privacy efforts as we learn more, and as the attacks against privacy become more sophisticated. This is a continuous arms race.