Do new SIGHASH types need a hard fork or a soft fork?

Question

There have been a few new sighash types proposed.

• SIGHASH_NORMALIZED : 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 : 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 : 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). 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 or soft fork.

Answer 1

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.