<p>Schnorr (bip-340) signatures have been introduced as part of v1 Segwit outputs with the <code>CHECKSIGADD</code> opcode. Therefore bip-340 signatures are part of the witness and are not part of the hash forming the <code>txid</code>.</p>
<p>Script malleability is only <a href="https://bitcoincore.org/en/2016/01/26/segwit-benefits/" rel="nofollow noreferrer">a single among a lot of benefits brought by Segwit</a>, and we shouldn't drop all the others (and encourage using legacy transactions) because part of the proposal does not need one of them.</p>
<p>For example, one of these benefits is simpler Script versioning and rolling out the <code>CHECKSIGADD</code> behaviour using the legacy versioning (<code>NOP</code> ops) would be a bit &quot;dirty&quot; (in addition to adding the incentive to use legacy transactions that are more expensive for the network to process).</p>

CC BY-SA 4.0
2021-06-11T19:13:05.963Z
Furthermore, script malleability is a wider problem than signature malleability. Segwit in general fixes all types of script malleability, which includes the ones cause by signature malleability, but also others.
Pieter Wuille
CC BY-SA 4.0
2021-06-12T12:07:20.890Z
Added to the answer (s/Signature malleability/Script malleability/).
Antoine Poinsot
CC BY-SA 4.0
2021-06-11T15:06:01.500Z
2021-06-12T12:06:49.953Z
2021-06-12T12:06:49.953Z
Antoine Poinsot
<p>SegWit fixed transaction malleability by just moving the signature out of the block of data that's being hashed to form the transaction id.</p>
<p>However, Schnorr does not suffer from signature malleability (<a href="https://medium.com/digitalassetresearch/schnorr-signatures-the-inevitability-of-privacy-in-bitcoin-b2f45a1f7287" rel="noreferrer">https://medium.com/digitalassetresearch/schnorr-signatures-the-inevitability-of-privacy-in-bitcoin-b2f45a1f7287</a>):</p>
<blockquote>
<p>Non-malleability: ECDSA signatures are inherently malleable, which may
enable a third party without access to the private key to alter an
existing valid signature and double-spend funds. This issue was
formally discussed in BIP62. In comparison, Schnorr signatures are
provably non-malleable.</p>
</blockquote>
<p>Consequently, is a Schnorr signature still segregated from the data that's being hashed, and if yes, why?</p>

CC BY-SA 4.0
2021-06-11T15:38:03.477Z
True, but also not what Dalit Sairio said. The question states "out of the block of data that's being hashed to form the transaction id", which is correct.
Murch
<segregated-witness><transaction-malleability><schnorr-signatures>
Are the witnesses segregated with Schnorr signatures?
Dalit Sairio
# Are the witnesses segregated with Schnorr signatures?

(Asked by: username_0 on 2021-06-11)

SegWit fixed transaction malleability by just moving the signature out of the block of data that's being hashed to form the transaction id.

However, Schnorr does not suffer from signature malleability (<https://medium.com/digitalassetresearch/schnorr-signatures-the-inevitability-of-privacy-in-bitcoin-b2f45a1f7287>):

> Non-malleability: ECDSA signatures are inherently malleable, which may
> enable a third party without access to the private key to alter an
> existing valid signature and double-spend funds. This issue was
> formally discussed in BIP62. In comparison, Schnorr signatures are
> provably non-malleable.

Consequently, is a Schnorr signature still segregated from the data that's being hashed, and if yes, why?

**Tags:** segregated-witness, transaction-malleability, schnorr-signatures

> **Comments:**
> **username_1**: True, but also not what username_0 username_0 said. The question states "out of the block of data that's being hashed to form the transaction id", which is correct.  

---

## 1 answers

### Answer by username_2 on 2021-06-11. Score: 7 | Accepted answer

Schnorr (bip-340) signatures have been introduced as part of v1 Segwit outputs with the `CHECKSIGADD` opcode. Therefore bip-340 signatures are part of the witness and are not part of the hash forming the `txid`.

Script malleability is only [a single among a lot of benefits brought by Segwit](https://bitcoincore.org/en/2016/01/26/segwit-benefits/), and we shouldn't drop all the others (and encourage using legacy transactions) because part of the proposal does not need one of them.

For example, one of these benefits is simpler Script versioning and rolling out the `CHECKSIGADD` behaviour using the legacy versioning (`NOP` ops) would be a bit "dirty" (in addition to adding the incentive to use legacy transactions that are more expensive for the network to process).

> **Comments:**
> **username_3**: Furthermore, script malleability is a wider problem than signature malleability. Segwit in general fixes all types of script malleability, which includes the ones cause by signature malleability, but also others.  
> **username_2**: Added to the answer (s/Signature malleability/Script malleability/).  

---

