 Sally asks, can you explain how transaction malleability can implement it? I felt that the transaction ID cannot be changed even in a very small way. That is a great question, Sally. The transaction ID cannot be changed because it represents the hash of the transaction. That is the theory. Here is the practice. The transaction ID represents the hash of every part of the transaction, except for the signatures. In the past, the transaction ID included the signatures. That is a problem. The reason it is a problem is because the only part of the transaction that is not signed is the signature itself. As a result, anyone can change the signature in such a way that it affects the transaction ID. Essentially, I take a transaction, I produce a copy of it, an identical copy, before it is confirmed. I make a copy of the transaction that I find on the blockchain being propagated in the mempool. I look at that transaction and I find the signature within it. I modify the signature. Since I don't have the private keys, I can't change the signature to sign something else. I can't change the inputs or outputs, because those are signed, and I don't have the private keys to forge that signature. I can add something to the signature that doesn't change its function. The signature is a number. Think of the signature as a number. Let's say the signature is the number five. It is not. Let's use that as a simple arithmetic example. It is the number five. If I change that and how it is encoded in the transaction, instead of five, I write it so that it is zero five. Zero five arithmetically is the same as five, but when you write it inside a transaction serialized in binary, that extra zero changes the data that goes into the transaction ID, which produces a different transaction ID. If you validate that signature arithmetically, zero five is the same as five, so it doesn't really matter. You can think of it as doing arithmetic, but it doesn't change the outcome. You could rewrite the signature as five plus one minus one. You can imagine various tricks, and these are arithmetic tricks. That's not exactly how they work. We're dealing with binary. We're dealing with a strictly serialized format. The developers kept finding ways that you could modify a signature without changing its actual value, modify how it was written, not what number it was. Therefore, when someone validates it, it validates the same way, because five was a valid signature for that transaction, the user sign. Because it is written differently, zero five instead of five, for example, when you calculate the transaction ID on this new copy of the transaction, it is a different transaction ID. What you've produced is the second transaction that signs the same amount to the same destination address, spends the same, everything is the same, except the transaction ID has changed. That can cause a lot of problems, because if any other transactions were referred to the original, and you managed to get the copy confirmed, it breaks that chain, which affects things like lightning and other things like that. How is this fixed? Very simply, the signature was taken out of the transaction ID, so now the transaction ID is not calculated on the signatures. In a segway transaction, the place in the transaction where the signatures were is empty. Well, it has a specific fixed format, which is segway. As a result, you can't modify it, because the actual signature is outside, it's been segregated. Because it's outside, you can't modify it to modify the transaction ID. If you try to modify it, you modify the part of the transaction that is signed, and therefore it invalidates the transaction. When Joe asks, can you please clarify why segway makes it easier for lightning network to run? Regarding lightning network, is it always the case that two parties need to reserve the same amount of funds for a payment channel? Let's break that into two parts. Why does segway make lightning network work? The simple answer is that the fundamental feature introduced by segway is the fix to transaction malleability. Segway fixes transaction malleability. It makes it impossible for a third party to malleate a transaction, to produce a transaction with a different transaction ID, but the same spendable amount. The reason this is important is that, in the case of lightning network, the parties are exchanging signed bitcoin transactions, called commitments, which are not broadcast to the network, and which depend on transactions that are broadcast to the network, and build upon each other. Which means that you need to make sure that the transaction ID of the previous transaction cannot be changed, even though it hasn't been confirmed. This means that you cannot have transaction malleability. Transaction malleability makes lightning network much more difficult to implement, which is why we don't see lightning implemented on bitcoin forts that have not fixed transaction malleability. Transaction malleability was a primary reason for segway, and once you have transaction malleability fixed, then you can chain transactions together in a series of smart contracts and know that you can't break that chain, and cause problems in the validation of those smart contracts through transaction malleability. The second question by Wenjo is, is it always the case that two parties need to reserve the same amount of funds for a payment channel? No, in fact, you can't even do that today. In order to do that, you would have to have the ability to create the channel funding transaction jointly through a multi-party transaction. That actually is a feature that is expected to be introduced in the Bolt Specifications 1.1 coming towards the end of 2019. Today, when a payment channel is open, it is created by one party and signed by one party, and it is funded asymmetrically, meaning that there is balance only on the side of the payment channel belonging to the party that initiated the channel. So, if I open a channel for someone else, all of the balance is on my side. The other party puts zero on their side of the channel, which means that if we want to have capacity in the other end, they have to open a channel to me. Ideally, we would like a situation where we can both commit the same amount of funds, so I can say, I'll put half a Bitcoin on my end, you put half a Bitcoin on your end. Let's make a channel that is balanced on both ends. That's not how it works today. It's planned for the future, and it will make balancing channels easier. But for now, channels are in one direction when they start. The capacity is all on one side. Once you make a few payments, the balance starts moving to the other side, so it's more balanced. But that also means that from a practical perspective, when you start and you node all of the channels are funded on your side, because you open them, and you have to wait or ask other spoken channels back to you so that you can start receiving payments, meaning you cannot receive payments on Lightning until someone opens a channel to you with balance on their side. Stefano asks, as I understand it, Segwit transactions are seen as a transaction spendable by anyone for nodes that have not been updated to Segwit. Is this a problem? It's a problem for those nodes because they may make assumptions about what is usable on the blockchain, but it's not a problem for the rest of the network. Stefano, you might be able to configure those nodes to try to spend these transactions because they are operating under the assumption that they are spendable, which is incorrect. The consensus rules in effect on the network today, and the consensus rules that are being enforced by every node and every miner with few exceptions, are that those transactions are not spendable by anyone. Those transactions are spendable with a segregated witness signature. Now, what that means is that if you took your node and you used it to produce a transaction that attempts to spend these points, you then transmit that transaction to anyone who is following the current rules of the network. Not only will they reject that transaction and refuse to propagate it to anyone else, they will also disconnect your node from lying. They will ban your node from the network, so everyone you send it to will go silent as they banned your node. Then you will be cut off from the network for trying to propagate lies because the idea that Segwit is a transaction spendable for anyone under the consensus rules on the network today and for the future is a lie, and that lie will not be propagated. You might as well assume that a node that pretends that Satoshi's mined coins from the first block are spendable by anyone and presents a fake signature from Satoshi. According to the rules of the network, there is no difference. One is invalid, the other is invalid. There is no difference in terms of whether you choose to violate the rules by pretending that Segwit coins are spendable by anyone. They are not according to the current rules. They require a witness. Or you pretend that Satoshi's original coins from the first block are spendable by you without a signature. They are not because that violates the consensus rules. There is no such thing as half violating the consensus rules or kind of violating the consensus rules. You can configure your node to believe any rules it wants, including that Satoshi's coins are spendable without a signature, just as much as you can leave your nodes in an incorrect configuration to believe that Segwit transactions are spendable by anyone. They are not. If you try to propagate these lies on the network against the rules of consensus, either one of those lies will ban you, and your transaction won't go anywhere. There were a lot of people saying that storing funds in Segwit carried additional risk, and that was proven to be false. It was proven to be false resoundingly by the fact that there are plenty of coins stored in Segwit. I can tell you that all of my cold storage savings are stored in Segwit multi-sig addresses, and anybody who wants to try and pretend those are spendable by anyone, be my guest, see how the network reacts. I'm quite comfortable putting my money where my mouth is, and I think that's all I need to say about that. Marcel asks, Segwit improves Bitcoin scalability, but is it enough for a possible future mass adoption? Is scalability not one of the main issues of cryptocurrency, and how can it be solved? Marcel, Segwit improves scalability, but it is not enough for a future mass adoption, and the reason for that is because we cannot solve scalability permanently. There is no such thing as a final solution in scalability. Scalability is solved differently at different scales. You have to have a scalability solution for each scale that you're trying to achieve, meaning that the problems we need to solve now for this scale of Bitcoin are different from the problems we need to solve for the next scale, and you never solve them completely. We see this on the internet, too. The problems you needed to solve in order to scale email were the different from the problems you needed to solve the scale email with attachments and images, were different from the problems you needed to scale the internet to do voice, and different from the problems you need to scale for the internet to do 4K HD ultra Netflix videos for everyone. At each level, when you solve one scaling problem, you open the door for new applications, which means you now have to solve a different scaling problem, and you can't in the beginning solve the problem for the end. There is no end. Also, if you prematurely optimize, if you try to solve scale problems for a scale that doesn't yet exist, you shift the problem somewhere else. In the case of cryptocurrencies, what you do is you damage decentralization today to solve a scaling problem you don't yet have. For example, if we introduce 32 megabyte blocks today in order to solve the scalability problem of the future for transactions that don't exist yet, we end up with a blockchain that is mostly empty, that solves a scaling problem that doesn't exist yet, at the expense of making denial of service easier, and shifting a lot of power to miners and centralized nodes by damaging decentralization. You don't want to solve scaling through the problem. So, can you solve it? Yes, Segwit is just the first step. There will be dozens and dozens of optimizations. The likely next step is Schnorr signatures, which introduces a 25-30% improvement in capacity by optimizing signatures and builds upon Segwit. Then we can look at signature aggregation, which is not going to be implemented in the first iteration of Schnorr, but can be implemented in future iteration. That can create a massive increase and optimization, because it allows you to have one signature per transaction instead of one signature per input, and potentially in the future even one signature per block for all of the transactions by aggregating them together. So, scalability gets solved again, and again, and again, and again with different optimization. Some of these optimizations, in my opinion, will probably involve increasing the base block size, but you don't start with that in my opinion. So, is scalability one of the main issues of cryptocurrencies, and how can it be solved? It's not one of the main issues of cryptocurrencies. It depends on what you're trying to achieve. Effectively, right now, Bitcoin, for example, has enough capacity to handle all of the transactions that people need to send at reasonable fees without any problems. And it did, as well, when it wasn't being jammed by miners with fake transactions in order to dry fees up. So, we did have some aberrations in fees, but these aberrations were mostly deliberate spamming of the network with fake transactions. I think in the future we are going to see problems with fees again, and we are going to see capacity crudges again, which will force people to design more smart fee management, better transaction management within wallets, use technologies like per place by fee and child pay for parent, and various fee management techniques, so that the people who are willing to pay for transactions can signal that intent to miners, and you can have a fee market that is somewhat healthier than just shifting that cost to nodes. So, that is one of the problems, but a lot of the problem of scalability, in my opinion, can be solved by building second-layer networks like Lightning Network, and even above and beyond third-layer networks beyond that. And the problems we need to solve in layer one are more on the privacy side, in my opinion, than on the scaling side. Hi, Andreas. At the end of the December Q&A, you said we have a limited window of time left to get Bitcoin to be completely anonymous. If not, it goes to layer two and won't work. You also said that 100% anonymity will become table stakes in all of crypto. Do you think we are going to get it in time before the window of anonymity closes? So, I have been talking since 2013 about this idea that protocols ossify from the Latin word also, which means bone. Basically, they gradually get harder and harder until they turn to bone. What does that mean? That means that when you have a protocol like Bitcoin, or as we have seen with other protocols like TCPIP in the past, that protocol becomes successful and is broadly used. People start building software, and then they start building hardware around the protocol. They start embedding the software and the protocol into various devices. For example, already we have a number of companies making software that goes in nodes. That means that every time something changes in the protocol, all of these nodes need to be updated. Over time, we are going to see the Bitcoin protocol get embedded deeper and deeper in hardware. Eventually, you will see it as firmware on chips. In that case, it becomes much more difficult to update. Think about your Wi-Fi router, for example. Its implementation of TCPIP is embedded in firmware. In order to update it, you need to basically load the new firmware file and reboot your router and all of that. There are so many other devices around you that have embedded protocols in them. The idea here is that the longer a protocol survives, the more mainstream it becomes, the more useful it is, the more likely it is to gradually become more and more difficult to change. To me, that means the window of opportunity for making changes to the core protocol, to the base layer of Bitcoin, is beginning to close. That means that it is going to get more and more difficult to make change, especially controversial changes. I think privacy is going to be a controversial change. Consider, for example, the fact that changes to privacy are going to affect many of the organizations that currently have obligations under the law to do know-your-customer and anti-money-longing reporting and regulations like that. Can they support a Bitcoin protocol that has strong privacy protections in it when they can't know everyone who is participating in a transaction or they have even more limited access? I expect companies like that are going to resist the introduction of privacy features. We may see difficulty in introducing these features in anything other than a soft fork. Fortunately, I think most of the interesting features for privacy can't be introduced by a soft fork in the base layer. The protocol can still be extended by a soft fork, thanks to a very important change that happened in 2017. That was the introduction of Segwit. With the introduction of Segwit, one of the very critical features that was introduced was a thing called Segwit versioning. With Segwit versioning, the scripting language that is used within a transaction in Bitcoin now has a version number. That version number can introduce new functionality without doing a hard fork. The first version of Segwit introduced in 2017 was Segwit version zero, because we can't think from zero. It's actually in the protocol as the prefix of a Segwit script is the number zero. We can upgrade that by adding a new version. You can have Segwit version one. The proposed changes to Segwit version one include some important new technologies that can introduce new privacy techniques. For example, Schnur signatures, tap roots, graft roots, Merkleized Abstract Syntax trees, and things like that. I expect we're going to see those introduced before the end of 2020 in Bitcoin as a soft fork. I'm hoping that's not the end, and that we will also see other changes that further enhance privacy. Fortunately, one of the things that works the benefit of Bitcoin is that the introduction of other cryptocurrencies that are privacy-focused allows for extensive research to be done across the entire ecosystem that benefits Bitcoin as well. For example, we've discovered some potential bugs that I'll be talking about in one of the next questions in ZK Snark implementation in Zcash. That is quite a big challenge, but it's been done in such a way that everybody in the ecosystem learns from mistakes and bugs like that. I expect we're going to see more features in privacy, and I don't think we're going to have a problem with introducing those features in Bitcoin, but we'll see. This is a big challenge.