Can you explain transaction malleability?

"Can you explain transaction malleability?" "I thought 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 a hash of the transaction. That is the theory. Here is the practice. The transaction ID is a hash of every part of the transaction, except for the signatures. In the past, the transaction ID included signatures. That was a problem, because the only part... of the transaction not signed is the signature itself. As a result, someone could change the signature in such a way that it affects the transaction ID. So I [could] produce an identical copy of a transaction before it is confirmed, being propagated to [the network]. I [can] then modify the signature. Since I don't have the private key, I can't change the signature... to sign something else. I can't change the inputs or the outputs because they are signed. I can't forge the signature. But I can add something to the signature that doesn't change its function. Keep in mind, the signature is a number. Think of the signature as the number '5.' It is not, but let's use that as a simple arithmetic example. If I change how it is encoded in the transaction and write '05.' Arithmetically, it is the save as '5.' But when written inside a transaction and serialized in binary, that zero changes the data in the transaction ID, which will produce a different transaction ID. If you validate that signature arithmetically, '05' is the same as '5.' It doesn't really matter. It doesn't change the outcome, like re-writing the signature as '5+1-1.' [Arithmetic variations]. But that is not exactly how they work because we are dealing with binary, a strictly serialize 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 validated it, '5' was a valid signature for that transaction. But because it was written differently, when you calculate the transaction ID, this new copy has a different transaction ID. You have produced a second transaction that signs the same amount, to the same destination address, and everything is the same, except the transaction ID has changed. That can cause a lot of problems. If any other transactions referred to the original, but [a slightly modified] copy is confirmed [instead], it breaks that chain. This affects things like the Lightning Network. How is this problem fixed? Very simply. You can take the signature out of the transaction ID. The transaction ID is not calculated with the signatures. In a SegWit transaction, the place where the signatures used to be is empty. It has a specific fixed format in [a separate witness data structure]. As a result, you can't modify it. The signature has been segregated. Because it is outside, you can't modify it in order to modify the transaction ID. If you try to modify it, you will modify the part of the transaction which is signed and therefore invalidate it.

Can you please clarify why SegWit makes it easier for the Lightning Network to run?

"Can you please clarify why SegWit makes it easier for the Lightning Network to run?" "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 SegWit make Lightning work? The simple answer is, the fundamental feature introduced by SegWit was to fix transaction malleability. It makes it impossible for a third-party to malleate a transaction to produce a different ID, for the same spendable amount. This is important because, in the case of Lightning, parties are exchanging signed bitcoin transactions... called commitments, which are not broadcast to [the first layer Bitcoin] network. They depend on [being able to] build transactions upon each other. You need to make sure that the transaction ID of the previous transaction cannot be changed, even [when] it hasn't been confirmed [yet]. You cannot have transaction malleability. It would make the Lightning Network more difficult to implement. This is why we don't see Lightning implemented on Bitcoin forks that have not fixed transaction malleability. [Fixing] transaction malleability was a primary reason for [adding SegWit]. Once you have fixed transaction malleability, you can chain transactions together in a series, knowing that you can't break that chain due to problems in the validation [of those transactions].

Is it always the case that two parties need to reserve the same amount of funds for a payment channel?

The second question: "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 [yet]. You would need the ability to create... the channel funding transaction jointly, through a multi-party transaction. That feature is expected to be introduced in the BOLT specification 1.1, coming towards the end of 2019. Today, when a payment channel is opened, it is created, funded, and signed by one party asymmetrically. There is balance only on one side, belonging to the party that initiated the payment channel. If I open a channel to someone else, the balance is on my side; the other party has [nothing] on their side. If we want to have capacity on the other end, they must open a channel to me. But ideally, we would both commit the same amount. You put half on your end, I put half on my end. That would make a channel that is balanced on both sides. That's not how it works today, but it is planned for the future. It will make balancing channels easier. For now, channels are one-sided with the starting capacity. Once you make a few payments, the balance will move to the other side. From a practical perspective, when you start a new node, all of the channels are funded on your side, so you must wait or ask other nodes to open channels back to you, so you can start receiving payments. You cannot receive on Lightning until someone opens a channel to you, with balance on their side. "As I understand it, SegWit transactions are seen as 'anyone-can-spend' by nodes that are not updated." "Is this a problem?" It is a problem for those nodes, because they are making assumptions... about what is [spendable] on the blockchain, but it is not a problem for the rest of the network. You might try to configure those nodes to spend these transactions, operating under the assumption that... they are spendable, which is incorrect. The consensus rules in effect on the network today, being enforced by every node and miner... with few exceptions, are that those transactions are not spendable by anyone [except the signer]. They are spendable by a Segregated Witness signature. If you tried to produce a transaction that spends these coins and transmit it to the network, anyone following the current rules would not only reject that transaction and refuse to propagate it, but they will also disconnect from your node for lying. Everyone you send it to will ban your node. You will be cut off from the network for trying to propagate lies. The idea that SegWit transactions are spendable by anyone, under the [current] consensus rules, is a lie. That lie will not be propagated. A node that pretends Satoshi's coins from the first blocks are spendable... by anyone, while presenting a fake signature from Satoshi, is no different. [They are both] invalid. You can [try] to violate the rules by pretending that SegWit transactions are spendable... by anyone, but they are not according to the current rules. They require a witness. [You can] pretend that Satoshi's original coins from the first block are spendable by you, without the signature, but they are not according to the consensus rules. There is no such thing as half violating the rules. You can configure your node with any rules you want, including that Satoshi's coins are spendable without a signature, just as you can leave your node with... an incorrect configuration to believe that SegWit transactions are anyone-can-spend. They are not. If you try to propagate these lies against the rules of consensus, the network will ban you. Your transaction won't go anywhere. A lot of people claimed that storing funds with SegWit carried additional risk, and that was proven false. Resoundingly, by the fact that there are now plenty of coins stored with SegWit. I can tell you that all of my cold storage savings are inside multi-signature SegWit addresses. If anybody wants to pretend those are anyone-can- spend, be my guest. See how the network reacts. I am quite comfortable putting my money where my mouth is. I think that is all I need to say about that.

SegWit improve scalability, but is it enough for the future of mass adoption? Is scalability not one of the main issues with cryptocurrency? How can it be solved?

"SegWit improve scalability, but is it enough for the future of mass adoption?" "Is scalability not one of the main issues with cryptocurrency? How can it be solved?" SegWit improves scalability, but it is not enough for future mass adoption. We cannot solve scalability permanently. There is no such thing as a final solution. Scalability is solved differently at different [milestones]. You need a scalability solution for each [progression]. The problems we need to solve now, for this scale, are different from the problems we will need to solve... for the next scale, and you never solve them completely. We saw this on the internet. The problems we solved in order to scale for email were different... from the problems for scaling attachments and images, which were different than those for quality voice, which are different from the problems in scaling the internet for 4K HD Ultra quality videos on Netflix. At each level, when you solve one scaling problem, you are opening the door for new applications. Now you must solve a different scaling problem. There is no end [scaling solution]. Also, if you prematurely optimize and scale for problems that don't yet exist, you will shift the problem somewhere else. In the case of cryptocurrencies, [often] damaging decentralization to solve a problem you don't have yet. For example, if we introduced 32 megabyte blocks today as a scalability solution for the future, for transactions that don't exist yet, we end up with a blockchain that is mostly empty, makes denial-of-service attack easier, shifts a lot of power to miners, and centralizes nodes. Damaging decentralization. You don't want to solve scaling prematurely. Can you solve it? Yes. SegWit is just the first step. There will be dozens and dozens of optimizations. Likely, the next step is Schnorr signatures, which will introduce a 25-30% improvement in capacity. It builds upon SegWit. Then signature aggregation, which will not be in the first iteration, but can be implemented in a future iteration. That could be a massive increase in capacity, because it allows you to have one signature per transaction... instead of one signature per input. Potentially in the future, we could even have one signature per block for all aggregated transactions. Scalability is solved again and again with different optimizations. In my opinion, some of these optimizations will probably involve increasing the base block size, but we don't need to start with that.

Is scalability one of the main issues of cryptocurrencies? How can it be solved?

"Is scalability one of the main issues of cryptocurrencies? How can it be solved?" It is not one of the main issues. It depends on what you are trying to achieve. Right now, Bitcoin has enough capacity to handle all of the transactions that people need to send, at reasonable fees, without any problems. It did as well when it wasn't being jammed by miners with fake transactions in order to drive fees up. We did have some aberrations in fees, but this was mostly deliberate spamming of the network. In the future, we will see problems with fees and capacity crunches again, which will force people to... design smarter fee management [algorithms] within wallets, and use techniques like replace-by-fee (RBF) and child-pays-for-parent (CPFP). People who are willing to pay [more] for transactions can signal that intent to the miners. We will have a fee market that is somewhat healthier than just shifting the [scaling] costs to full nodes. A lot of the problems with scalability can be solved by building second-layer networks, like Lightning. Even above and beyond that, third-layer networks. In my opinion, the problems we need to solve in the first layer are more on the privacy side.

Do you think Bitcoin will get anonymity in time before that window closes?

"Hi Andreas. At the end of the December Q&A [session], you said that we have a limited window of time left... to make Bitcoin completely anonymous, and second-layer [solutions won't be enough]." "You also said that 100% anonymity will become table stakes in all cryptocurrencies." "Do you think Bitcoin will get anonymity in time before that window closes? I have been talking about this idea since 2013, that protocols ossify. 'Ossify' from the Latin word "os", which means bone. Basically, they become harder and harder [to change]. What does that mean? When you have a protocol like Bitcoin, or as we have seen with others like TCP/IP, which becomes successful and is broadly used, people build software and hardware around it. They start embedding the software into various devices. For example, we already have a number of companies making node software. Every time something changes with the protocol, these nodes need to be updated. Over time, the Bitcoin protocol will be embedded deeper and deeper in hardware, in the firmware of chips. In that case, it becomes more difficult to update. Think about your Wi-Fi router, for example. Its implementation of TCP/IP is embedded in firmware. To update it, you will need to load the new firmware... and reboot your router. There are so many devices around you that have embedded protocols in them. The idea here is, the longer the protocol survives, the more mainstream and useful it becomes. it will gradually become more difficult to change. That means the window of opportunity for making changes to the core protocol, the base layer of Bitcoin, is beginning to close. It will become more difficult to make changes, especially the controversial changes. I think privacy [enhancements] will be a controversial change. Consider that changes to [add] privacy will affect many organizations which currently... have obligations under the law, like Know-Your-Customer and anti-money laundering reporting regulations. Can they support a Bitcoin protocol with strong privacy protections in it, where they can't know everyone... who is participating in a transaction, [and] they have even more limited access [to data]? I expect those companies will resist the introduction of privacy features. We may see difficulty in introducing these features [by any other method] than a soft fork. Fortunately, I think that most of the interesting privacy features can be introduced by a soft fork. The protocol can still be extended by soft forks thanks to a very important change in 2017. That was the introduction of SegWit. One of the critical features was versioning. With SegWit versioning, the scripting language used within a transaction 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 version 0, because we count things from zero. It is actually in the protocol as the prefix of a SegWit script, the number zero. We can upgrade that by adding new versions. The proposed changes for SegWit version 1... include some important new privacy techniques: Schnorr signatures, Taproot, Graftroot, and Merkilized Abstract Syntax Trees (MAST). I expect we will see those introduced in Bitcoin before the end of 2020, as a soft fork. I am hoping that is not the end, that we will see other changes that further enhance privacy. Fortunately, what works to the benefit of Bitcoin is the introduction of other cryptocurrencies... that are privacy-focused, which allows for extensive research to be done. For example, we have discovered some potential bugs. I will talk about that in one of the next questions. The zk-SNARK implementation in Zcash is quite a big challenge. But everybody in the ecosystem learns from mistakes and bugs like that. I expect we will see more privacy features. I don't think we will have problems introducing them in Bitcoin, but we will see. This is a big challenge ahead.