<blockquote>
  <p>The data of the scriptSig is mooved from TransactionInput to RawTransaction, so the Raw transaction doesn't is malleability? maybe I can't imagine what really happened to non-witness transactions during malleability, can you give me an example?</p>
</blockquote>

<p>The transaction ID is a hash of the entire transaction data structure (the version, inputs, outputs, signatures, number of inputs and outputs, locktime, everything). Elliptic Curve signatures, such as the ones used by Bitcoin, contain a random number as part of the signature. Using another random number will also lead to a valid, but different signature. If the signature changes, the hash of the entire transaction object would also change.</p>

<p>In segregated witness transactions, this signature data is not part of the base transaction data structure - this means that changing the signature will no longer change the txid, since the rest of the transaction has not been altered.</p>

<blockquote>
  <p>Why the witness data is stored outside the block? what do you mean? I think I don't understand the sense of this space-saving because the witness data is present inside the blk file</p>
</blockquote>

<p>Moving the witness data outside the block allows Bitcoin to effectively pack more transactions into a block - The space previously used by all the signatures is now available to add more transactions.</p>

<blockquote>
  <p>How (If I understand correctly) bitcoin core use the Merkle-tree for verifying the signature? (this question is related to the first, I don't think I understood the phenomenon of malleability as it happens)</p>
</blockquote>

<p>Merkle trees having nothing to do with signature verification. Merkle trees are used to build a commitment to which transactions are included in a block, which is then placed in the block header and locked in using the proof of work system. Transaction malleability affected this, since altering a transaction ID within the transactions selected for the block would alter the merkle tree - this is no longer possible for the reasons stated above.</p>

CC BY-SA 4.0
2019-08-19T15:06:02.147Z
Thank so much for your answer but I don't understand because Is defined that the witness data is to extern of the block, What is meant outside the block? why then if the data is deserialized inside the block?
vincenzopalazzo
CC BY-SA 4.0
2019-08-19T15:07:46.597Z
Segregated witness data is still part of the block, and even committed to it. It's just in an area that (a) doesn't contribute to txids (to fix malleability) and (b) is not seen by old nodes, thus bypassing the existing size limits.
Pieter Wuille
CC BY-SA 4.0
2019-08-19T15:22:18.840Z
Ah, ok thanks, on the problem of the existing size limits exist a BIP? if yes what is your name?
vincenzopalazzo
CC BY-SA 4.0
2019-08-19T15:37:39.190Z
Another question @PieterWuille on the malleability of the transaction id, if I create a new transaction not witness and I send to the network bitcoin, how this transaction id change? What is the way in which txid was calculated allows anyone to make small changes to the transaction
vincenzopalazzo
CC BY-SA 4.0
2019-08-19T15:38:38.470Z
BIP62 lists a number of known ways to malleate transactions.
Pieter Wuille
CC BY-SA 4.0
2019-08-19T14:53:53.887Z
2019-08-19T14:53:53.887Z
Raghav Sood
<blockquote>
  <p>Why the witness data is stored outside the block? what do you mean? I think I don't 
  understand the sense of this space-saving because the witness data is present inside the blk file.</p>
</blockquote>

<p>The signatures are in the block. All signatures of a block form another merkle tree and are keeping in an output of the coinbase tx. I think this refers to the "UTXO set" that it's like a ledger where the miners record and verify the UTXO's. Segwit TX's don't keep the signatures in the TXID so the witness it's stored in the block, but not in the "UTXO set"</p>

CC BY-SA 4.0
2019-08-20T02:59:01.503Z
This is correct, but confusing. Transaction inputs do not ever make it into the UTXO set either, yet they are not segregated.
Pieter Wuille
CC BY-SA 4.0
2019-08-19T19:54:12.610Z
2019-08-19T19:54:12.610Z
mengeroshi
<p>I have some question on how segregated witness work.</p>

<p>I'm reading <a href="https://bitcoin.stackexchange.com/questions/41764/what-is-segregated-witness-and-how-can-it-improve-network-scalability">this post</a> and in the answer exist this phrase </p>

<blockquote>
  <p>Since signature data (witness data) is stored outside the transaction (and outside the standard block), it means that that data doesn't have to be counted towards the block size. </p>
</blockquote>

<p>Now I have three questions on this argument</p>

<ol>
<li>The data of the scriptSig is moved from TransactionInput to RawTransaction, so the RawTransaction doesn't have malleability? Maybe I can't imagine what really happened to non-witness transactions during malleability, can you give me an example?</li>
<li>Why is the witness data stored outside of the block? What do you mean? I think I don't understand the sense of this space-saving because the witness data is present inside the blk file</li>
<li>How (If I understand correctly) does Bitcoin Core use the Merkle tree for verifying the signature? (this question is related to the first, I don't think I understood the phenomenon of malleability as it happens)</li>
</ol>

<segregated-witness><transaction-malleability><witness-data>
How does storing the witness outside of the block prevent malleability?
vincenzopalazzo
# How does storing the witness outside of the block prevent malleability?

(Asked by: username_0 on 2019-08-19)

I have some question on how segregated witness work.

I'm reading [this post](https://bitcoin.stackexchange.com/questions/41764/what-is-segregated-witness-and-how-can-it-improve-network-scalability) and in the answer exist this phrase

> Since signature data (witness data) is stored outside the transaction (and outside the standard block), it means that that data doesn't have to be counted towards the block size.

Now I have three questions on this argument

1. The data of the scriptSig is moved from TransactionInput to RawTransaction, so the RawTransaction doesn't have malleability? Maybe I can't imagine what really happened to non-witness transactions during malleability, can you give me an example?
2. Why is the witness data stored outside of the block? What do you mean? I think I don't understand the sense of this space-saving because the witness data is present inside the blk file
3. How (If I understand correctly) does Bitcoin Core use the Merkle tree for verifying the signature? (this question is related to the first, I don't think I understood the phenomenon of malleability as it happens)

**Tags:** segregated-witness, transaction-malleability, witness-data


---

## 2 answers

### Answer by username_1 on 2019-08-19. Score: 2 | Accepted answer

> The data of the scriptSig is mooved from TransactionInput to RawTransaction, so the Raw transaction doesn't is malleability? maybe I can't imagine what really happened to non-witness transactions during malleability, can you give me an example?

The transaction ID is a hash of the entire transaction data structure (the version, inputs, outputs, signatures, number of inputs and outputs, locktime, everything). Elliptic Curve signatures, such as the ones used by Bitcoin, contain a random number as part of the signature. Using another random number will also lead to a valid, but different signature. If the signature changes, the hash of the entire transaction object would also change.

In segregated witness transactions, this signature data is not part of the base transaction data structure - this means that changing the signature will no longer change the txid, since the rest of the transaction has not been altered.

> Why the witness data is stored outside the block? what do you mean? I think I don't understand the sense of this space-saving because the witness data is present inside the blk file

Moving the witness data outside the block allows Bitcoin to effectively pack more transactions into a block - The space previously used by all the signatures is now available to add more transactions.

> How (If I understand correctly) bitcoin core use the Merkle-tree for verifying the signature? (this question is related to the first, I don't think I understood the phenomenon of malleability as it happens)

Merkle trees having nothing to do with signature verification. Merkle trees are used to build a commitment to which transactions are included in a block, which is then placed in the block header and locked in using the proof of work system. Transaction malleability affected this, since altering a transaction ID within the transactions selected for the block would alter the merkle tree - this is no longer possible for the reasons stated above.

> **Comments:**
> **username_0**: Thank so much for your answer but I don't understand because Is defined that the witness data is to extern of the block, What is meant outside the block? why then if the data is deserialized inside the block?  
> **username_2**: Segregated witness data is still part of the block, and even committed to it. It's just in an area that (a) doesn't contribute to txids (to fix malleability) and (b) is not seen by old nodes, thus bypassing the existing size limits.  
> **username_0**: Ah, ok thanks, on the problem of the existing size limits exist a BIP? if yes what is your name?  
> **username_0**: Another question @PieterWuille on the malleability of the transaction id, if I create a new transaction not witness and I send to the network bitcoin, how this transaction id change? What is the way in which txid was calculated allows anyone to make small changes to the transaction  
> **username_2**: BIP62 lists a number of known ways to malleate transactions.  

---

### Answer by username_3 on 2019-08-19. Score: 1

> Why the witness data is stored outside the block? what do you mean? I think I don't
> understand the sense of this space-saving because the witness data is present inside the blk file.

The signatures are in the block. All signatures of a block form another merkle tree and are keeping in an output of the coinbase tx. I think this refers to the "UTXO set" that it's like a ledger where the miners record and verify the UTXO's. Segwit TX's don't keep the signatures in the TXID so the witness it's stored in the block, but not in the "UTXO set"

> **Comments:**
> **username_2**: This is correct, but confusing. Transaction inputs do not ever make it into the UTXO set either, yet they are not segregated.  

---

