<p>It is in fact a hard fork, if it is done natively. However, it can be done through a soft fork if the sighash types are only included in serialized redeemScripts for P3SH (P2SH but with OP_EQUALVERIFY instead of OP_EQUAL), or via re-purposing one of the OP_NOPs to be a new op with similar functionality to OP_CHECKSIGVERIFY.</p>

<p>Source: <a href="http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf" rel="nofollow">http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf</a></p>

<blockquote>
  <p>To mitigate malleability, it requires changing which contents are signed by the participants. This is achieved by creating new Sighash types. In order to accommodate this new behavior, a new P2SH type or new OP_CHECKSIG is necessary to make it a soft-fork rather than a hard-fork.</p>
</blockquote>

CC BY-SA 3.0
2015-04-02T06:11:45.523Z
2015-04-02T06:11:45.523Z
morsecoder
<p>There have been a few new sighash types proposed.</p>

<ul>
<li><a href="http://www.youtube.com/watch?v=8zVzw912wPo&amp;t=20m15s" rel="nofollow noreferrer">SIGHASH_NORMALIZED</a> : Use a 'normalized' TXID in the inputs when serializing for signing. This normalized transaction id is calculated by removing the scriptSigs of the transaction that you are spending from before serializing.</li>
<li><a href="http://www.youtube.com/watch?v=8zVzw912wPo&amp;t=20m15s" rel="nofollow noreferrer">SIGHASH_NOINPUT</a> : Just remove TXIDs from the inputs entirely. Useful for thwarting malleability, but allows funds sent to that same scriptPubKey again to be stolen, so you would only sign an input with this if you are sure you are never going to use that scriptPubKey again.</li>
<li><a href="https://bitcointalk.org/index.php?topic=181734.0" rel="nofollow noreferrer">SIGHASH_WITHINPUTVALUE</a> : Include the input's value when replacing the scriptSig with the previous scriptPubKey, so signers can prove knowledge of exactly what they are giving away (useful for hardware wallets). </li>
</ul>

<p>AFAIK, however, if an unidentified sighash flag is used, then the standard client treats it like SIGHASH_ALL (<a href="https://en.bitcoin.it/wiki/OP_CHECKSIG#Hashtype_SIGHASH_ALL_.28default.29" rel="nofollow noreferrer">source</a>). Isn't introducing a new sighash flag a hard fork, then? The sources linked to above give conflicting statements on whether new sighash flags require a <a href="https://bitcoin.stackexchange.com/questions/9173/what-is-a-hard-fork">hard</a> or <a href="https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork">soft</a> fork. </p>

<signature><blockchain-fork><sighash>
Do new SIGHASH types need a hard fork or a soft fork?
morsecoder
# Do new SIGHASH types need a hard fork or a soft fork?

(Asked by: username_0 on 2015-04-02)

There have been a few new sighash types proposed.

* [SIGHASH\_NORMALIZED](http://www.youtube.com/watch?v=8zVzw912wPo&t=20m15s) : Use a 'normalized' TXID in the inputs when serializing for signing. This normalized transaction id is calculated by removing the scriptSigs of the transaction that you are spending from before serializing.
* [SIGHASH\_NOINPUT](http://www.youtube.com/watch?v=8zVzw912wPo&t=20m15s) : Just remove TXIDs from the inputs entirely. Useful for thwarting malleability, but allows funds sent to that same scriptPubKey again to be stolen, so you would only sign an input with this if you are sure you are never going to use that scriptPubKey again.
* [SIGHASH\_WITHINPUTVALUE](https://bitcointalk.org/index.php?topic=181734.0) : Include the input's value when replacing the scriptSig with the previous scriptPubKey, so signers can prove knowledge of exactly what they are giving away (useful for hardware wallets).

AFAIK, however, if an unidentified sighash flag is used, then the standard client treats it like SIGHASH\_ALL ([source](https://en.bitcoin.it/wiki/OP_CHECKSIG#Hashtype_SIGHASH_ALL_.28default.29)). Isn't introducing a new sighash flag a hard fork, then? The sources linked to above give conflicting statements on whether new sighash flags require a [hard](https://bitcoin.stackexchange.com/questions/9173/what-is-a-hard-fork) or [soft](https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork) fork.

**Tags:** signature, blockchain-fork, sighash


---

## 1 answers

### Answer by username_0 on 2015-04-02. Score: 2 | Accepted answer

It is in fact a hard fork, if it is done natively. However, it can be done through a soft fork if the sighash types are only included in serialized redeemScripts for P3SH (P2SH but with OP\_EQUALVERIFY instead of OP\_EQUAL), or via re-purposing one of the OP\_NOPs to be a new op with similar functionality to OP\_CHECKSIGVERIFY.

Source: <http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf>

> To mitigate malleability, it requires changing which contents are signed by the participants. This is achieved by creating new Sighash types. In order to accommodate this new behavior, a new P2SH type or new OP\_CHECKSIG is necessary to make it a soft-fork rather than a hard-fork.


---

