 Okay, a lot of people are asking about segregated witness. Segregated witness is a change in the architecture of transactions that allows the signatures to be in a separate attached data structure... and not be computed as part of the transaction hash or transaction ID. Segregated witness has a number of advantages over the traditional transaction architecture. But most importantly, it's an opt-in choice, meaning that you can use segregated witness if you want, and you don't have to use segregated witness if you don't want to use segregated witness. With segregated witness, signatures are placed in a separate tree in the block. Those signatures are called witnesses, and the tree is called the witness-mercle tree. What that means is that the transaction IDs are no longer affected by the signatures. This fixes a big problem in the original implementation of Bitcoin, called transaction malleability, which allows people to mess around with signatures and call transactions to change their transaction ID. This is really an important problem to solve, because it affects the ability to implement various types of smart contracts, including payment channels and interesting things like that. Segregated witness addresses are different than traditional Bitcoin addresses. There are two different formats for segregated witness addresses. One is segregated witness wrapped inside of paid-to-script hash, or P2SH. Those begin with a three, and they look very much like multi-sig addresses. Segregated witness when wrapped in P2SH, which is backwards compatible and easy to use for any wallet, whether it understands segwit or not, begin with a three, and they look like traditional Bitcoin addresses. There is also a new format for addresses defined in BIP176, which is called Batch32. This format starts with the letters BC1, and lots of lowercase alphanumeric characters. BC1, or Batch32 addresses, are full-segwit natively without being wrapped in P2SH, and we are gradually seeing more and more wallets, exchanges, and providers switch to that. One of the reasons why you might want to use segregated witness is because it reduces the cost of fees by giving a discount to the data that's in the signatures versus the rest of the data in the transaction. That was one way to increase the capacity of each block without doing a hard fork. Segregated witness also improves capacity. There are some other advantages. You can read about those in mastering Bitcoin, but that's what segregated witness is. How would you know that you are using segregated witness? Well, it depends. Your wallet may have a special function in order to use segregated witness. Keep in mind that using segregated witness has two parts. You can send to a segregated witness address, and there are two different types of segregated witness addresses. There are segregated witness addresses that are wrapped in P2SH, start with a three, and they look like multi-sig addresses from the past, because those are also wrapped in P2SH. Or you might see one of the new native address schemes for segregated witness, where the address you are sending to starts with BC1. If you see BC1, that's a segregated witness native address, so you know that that's a segregated witness. The reason we still have the P2SH or Pay2Script hash addresses that start with a three is because that's backwards-compatible. It allows a wallet that doesn't yet understand the new segregated witness native addresses, to still be able to send to a segregated witness wallet without having to know about it. That would be a three-address, which is accepted broadly by all wallets today. If your wallet is sending from a segregated witness address, then that transaction and the inputs that are from a segregated witness address will have the witness in a separate part of the transaction. You may not really see that. You will probably just know that your wallet is capable of handling segregated witness addresses. It also means that when you produce a receiving address for someone else to send you Bitcoin, then that receiving address either starts with a three, or it starts with BC1. If it starts with BC1, you are definitely using Segwit. If it starts with a three, you may be using Segwit, or you may be using a multi-sig address, or some other script. If it starts with a one, traditional, old-style Bitcoin address, you are definitely not using a segregated witness enabled address. What type of malleability and scalability issues can Bitcoin present without using segregated witness? That's a great question, Yusef. If you make a transaction today without using segregated witness, a third party can malleate that transaction, which means they can modify it in ways that you haven't authorized and retransmit. A competing transaction that has a slightly modified signature, such that the transaction is still valid, but its transaction ID has changed. This causes a number of problems, especially since if you have other transactions that depend on it, and the transaction ID has changed before its mind, then those other transactions are invalid, and they need to be changed, too. Which means you can't create un-broadcasted transactions and know that they will remain exactly the same. You can't create dependent transactions or chain many transactions together, because until each of them is confirmed, the transaction ID can be changed by a third party and re-broadcast as a separate transaction. Malleability is quite a significant problem when it comes especially to smart contracts, more advanced functionality, chains, transactions, and things like that. If you use transactions that do not have segregated witness today, then those transactions are still susceptible to malleability. By using segregated witness addresses and segregated witness structure in your transactions, you ensure that those transactions are not malleable. That means that protocols that want to use smart contracts in Bitcoin or chain transactions together, or create payment channels, use only segregated witness transactions so as to make it impossible to malleate those. Why is nobody making use of the malleability bug in Bitcoin or Bitcoin Cash? If you can interject a transaction, change the signatures, pay a higher fee, and broadcast it again. You can change the signatures so that they are still valid, but slightly different, but you can't change who is getting paid, you can't change the amount, you can't change where the money is coming from, so you can't steal money with transaction malleability. All you can do is confuse the system by changing the transaction ID. There is not much point. The only reason you would use transaction malleability as an attack is for denial of service, and it makes it difficult for certain types of smart contracts. But pretty much since 2013, every single exchange and provider accounts for and knows about transaction malleability, and they don't allow you to double-withdraw or cause other problems with transaction malleability. If we are making two different blocks, transaction and witness block, do we still have the same size on the blockchain, but just two different blocks? Please elaborate on segregated witness. Rohit, no, there are no two different blocks. The transaction data and the witness data are part of the same one block, one block that has both of those data sets in it, and has two Merkle trees, which are committed in the coin-based transaction, and the transaction Merkle roots in the header of the block. So the witness section and the transaction section are in the same block. But they are not mixed together, meaning the witness part is not inside each of the transactions, but it is in a separate part of the data structure, and it has its own Merkle tree. That means that if the witness changes, for example, because of transaction malleability, it doesn't change the transaction ID, and it doesn't change the transaction Merkle root. How is the witness part included in add-on blocks and verified in the coin-based transaction? Since the beginning, every single transaction is hashed to produce a transaction identifier, a transaction hash. That transaction hash is put into the bottom of the Merkle tree, and all of the transactions together create a Merkle tree. The Merkle root of that tree, which is one hash that summarizes the entire tree, is stored in the header of the block. The witness parts are also stored in exactly the same way, just in a different tree. So every single witness from every single transaction is put into the bottom of a Merkle tree. The Merkle tree summarizes all of those things into a Merkle root, and this one is called the witness Merkle root, and the witness Merkle root is incorporated in the coin-based transaction. Validation of the block requires validating that the Merkle root of transactions is correct, and includes all transactions, and the Merkle root of witnesses is correct in the coin-based, and includes all witnesses, and validating, of course, every witness against every transaction. So validation hasn't changed at all. SegWit security, are there any concerns about the potential increase in the number of invalid blocks propagated? If not enough people are storing the unhashed signature data on their nodes? So what Jesse is talking about is the idea that if people decide to not store the witness part, and only store the transaction part, is there a potential increase in the number of invalid blocks propagated? Not really, because ultimately both the miners and those who are validating witness data ensure that invalid blocks won't get propagated very far, because they will be orphaned. And don't forget that there is the mining reward incentive to keep miners honest. They have to validate witness data, otherwise, if they produce invalid blocks, those invalid blocks will be rejected by the majority of the network. Jesse asks a follow-up, if I'm not storing signature data on my node, is there a chance that I could not verify the occurrence of a previous transaction? If that is the case, should large transactions remain off SegWit or the Lightning network, insofar as you're not personally storing signature data? No, Jesse, signature data is part of block and transaction validation. Whether you choose to store it or not. Keep in mind that, as Bitcoin works today, most nodes validate signature data only once, and then they stop validating it, and don't necessarily have to store it in the future. If you decide to have a node that is not validating witness data, or have a node that is not storing witness data, those are two very different things. In fact, you can't configure your node to not validate witness data. You can only configure your node to not store witness data. What does that mean? That means that when you receive a transaction, you will validate the witness data. You may choose not to store it on your blockchain long-term, and in fact, you don't need to store it once you validated it. If you choose not to validate witness data, you are not running a validating node. If you are not running a validating node, you are essentially operating in simple payment verification, SPV mode, which means that you are relying on the miners to do the validation for you. That is not an authoritative validation. You have a range of choices. You can validate, but not store. If you choose not to validate, you might as well simply run a light client, because you are no longer validating transaction data. You are running an SPV node. You have always had the opportunity to run an SPV node. An SPV node has less security than a fully validating node. The only difference now is that you can be a fully validating node, but not fully store all of the data. Just like you can prune the blockchain to reduce its disk space, you can also not store witnesses.