Segregated witness is a change in the architecture of transactions that allows signatures to be in a separate attached data structure and not 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 is an opt-in feature, meaning you can use Segregated Witness if you want to, but you don’t need to use Segregated Witness if you don’t want to use it.
With Segregated Witness, signatures are placed in a separate Merkle tree in the block; those signatures are called “witnesses” and the tree is called the witness Merkle tree.
What that means is that the transaction IDs are no longer affected by the signatures, which fixes a big problem in original Bitcoin implementation called transactions malleability, which allowed people to mess around with signatures and call calls transactions to change transaction IDs.
This is an important problem to solve because it affects our ability to implement various types of smart contracts, including payment channels and interesting things like that.
Now, Segregated Witness addresses are different than traditional Bitcoin addresses. There are two formats.
One is Segregated Witness wrapped inside of pay-to-script-hash (P2SH). Those addresses begin with a ‘3’ and they look very much like Bitcoin 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 ‘3,’ and they look like traditional Bitcoin addresses.
There is also a new format for SegWit addresses defined in BIP-173, which is called “Bech32.” This format starts with the letters ‘bc1’ and the rest uses lowercase, alphanumeric characters.
‘bc1’ or Bech32 addresses are full native Segregated Witness addresses, without being wrapped in P2SH, and we are gradually seeing more wallets, exchanges, and merchant providers switch to that.
One of the reasons why you want to use Segregated Witness for transactions is because it reduces a costs of fees by giving a discount because they use less data that are in signatures compared with traditional bitcoin transactions.
That was one way to increase the capacity of each block without doing a hard fork. So Segregated Witness also improves capacity.
How would you know that you are using Segregated Witness?
It depends. Your wallet may have added a special function in order to use Segregated Witness. Keep in mind that Segregated Witness has two different types of addresses.
There are SegWit addresses wrapped in P2SH, which start with a ‘3’ and look like multi-sig addresses, because multi-sig addresses are also wrapped in P2SH.
Or, you might see one of the new native SegWit addresses, which starts with ‘bc1.’ If you see that ‘bc1,’ it is a Segregated Witness native address.
The reason we still have the P2SH addresses is because those are backwards-compatible, allowing wallets which don’t yet understand the new format to still be able to send to a SegWit-enabled wallet without having to migrate to the native addresses.
Again, that backwards-compatible address starts with a ‘3,’ which is more broadly accepted by all wallets today.
If your wallet is sending from a SegWit address, then the signature will be in a separate part of the transaction. You may not see that, but your wallet is capable of handling Segregated Witness addresses.
It also means that when you produce a receiving address for someone else to send bitcoin to you, that receiving address either starts with a ‘3’ or ‘bc1.’
If it starts with ‘bc1,’ you are definitely using SegWit. If it starts with ‘3,’ you are using SegWit or a multi-sig address, or some other script.
If the address starts with a ‘1,’ you are using a traditional, old style Bitcoin address and definitely not using SegWit.
What type of malleability and scalability issues can Bitcoin present without using Segregated Witness?
If you make a transaction without using Segregated Witness, a third-party can maleate that transaction. They can modify it in unauthorized ways and re-transmit it with a slightly modified signature, such that the transaction is still valid, but its transaction ID has changed.
This causes number of problems if you have other transactions that depend on it and the transaction ID has changed before it has been mined, then those other transactions will be invalid and need to be changed too.
You couldn’t create unbroadcasted transactions and know that they will remain valid. You can’t create a chain of many dependent transactions together; because until each of them is confirmed, the transaction ID could be changed by a third party and re-broadcasted as a separate transaction.
Malleability is quite a significant problem when it comes to smart contracts and more advanced functionality.
If you send transactions that do not have Segregated Witness, then they are still susceptible to malleability. By using the SegWit addresses and data structure with your transactions, you ensure they are not malleable. That means that second-layer protocols that do smart contracts on Bitcoin, chain transactions together, or create payment channels… use only SegWit, to make it impossible for third parties to maleate those transactions.
Why is nobody exploiting the malleability bug in Bitcoin or Bitcoin Cash, if you can interject a change with the signatures, pay a higher fee, and broadcast it again?
With traditional addresses, you can change the signature and it will be slightly different but still valid.
You can’t change who is getting paid, you can’t change the amount or where the money is coming from.
So you can’t steal money with transaction malleability, all you can confuse system by changing transaction IDs. There is not much point to exploiting this bug. You would use malleability as an attack for denial-of-service or creating issues for certain types of smart contracts. But since 2013, every single exchange and merchant provider accounts for, and knows about transaction malleability, and they don’t allow you to make double withdrawals or cause other problems with transaction malleability.
“If we are making two different blocks, a transaction and witness block, are they still the same size? Please elaborate on Segregated Witness.”
There are not two different blocks. The transaction data and witness data are part of the same block. One block would have both data sets in it: two Merkle trees, committed in the Coinbase transaction, and the Merkle root in the header of the block.
The witness (signature) section and the transaction section are in the same block, but not mixed together. The witness part is not inside each of the transactions, but in a separate part of the data structure. The witness part has its own Merkle tree, so if the witness changes because of transaction malleability, the transaction ID and Merkle root don’t change.
How is the witness part included in add-on blocks and verified in the Coinbase transaction?
Since the beginning, every single transaction is hashed to produce a transaction identifier/hash.
That transaction hash is put in the bottom of the Merkle tree, and all the transactions create the Merkle tree; and the Merkle root of that tree, one hash that summarises the entire tree, which is stored in the header of the block.
The witness parts are also stored in exactly the same way, just in a different tree.
Every single witness from every single transaction is put into the bottom of a Merkle tree, the Merkle tree summarises all of the witnesses into a Merkle root, and this one is the witness Merkle root. The witness Merkle root is incorporated into the Coinbase transaction.
Validation of the block requires validating that the Merkle roots of transactions and witnesses is correct, including all transactions and witnesses. Every witness is validated against every transaction.
So validation hasn’t changed at all, and there are no “add-on” blocks necessary for the witness part.
“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?”
This is question about what happens if people decide to not store the witness part, only the transaction part. Is there a potential increase in the number of invalid blocks propagated?
Not really.
Ultimately, miners and non-mining nodes validating the witness data ensure that invalid blocks don’t propagate very far, because they will be orphaned.
Don’t forget that the block reward is an incentive to keep miners honest; they must validate witness data. Otherwise, if they produce invalid blocks, those will be rejected by the majority of the network.
If I don’t store signature data on my node, could I not verify previous transactions? If that is the case, should large transactions remain off SegWit or the Lightning Network, insofar as you not personally storing signature data?
No.
Signature data is part of block and transaction validation, whether you choose to store it or not.
As Bitcoin works today, most nodes validate signature data only once and then they stop validating it. They don’t necessarily have to store it in the future.
If you decide to have a node that is not validating witness data, or not storing witness data, those are two very different things.
You can’t configure your node to not validate witness data; you can only configure your node to not store it. What does that mean?
When your node receives a transaction, you will validate the witness data. You may choose to not store it on your blockchain database long-term. You don’t need to store it once you have validated it.
But if you choose to not validate witness data at all, you are not running a validating node. If you are not running a validating node, you are operating in Simple Payment Verification (SPV) node, which means you are relying on the miners to do validation for you; that is not independent authoritative validation.
You have a range of choices. You can validate and store, or validate but not store.
If you choose not to validate either, then you might as well run a light client since you are not validating transaction data, you are running an SPV node.
You always have the opportunity to run an SPV node. But an SPV node offers less security for verifying your own transactions than a fully validating node.
The only difference now is that you can have a fully validating node, but not fully store all of the data long-term. Just like you can prune the blockchain to reduce its disk space, and not store witnesses.
Add Comment