<p>The differences between SIGHASH_NOINPUT (<a href="https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki" rel="nofollow noreferrer">BIP 118</a>) and SIGHASH_ANYPREVOUT (<a href="https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki" rel="nofollow noreferrer">proposed update to BIP 118</a>) were discussed at the Sydney <a href="https://btctranscripts.com/sydney-bitcoin-meetup/2020-07-21-socratic-seminar/#bip-118-and-sighash_anyprevout" rel="nofollow noreferrer">Socratic Seminar</a> in July 2020.</p>
<blockquote>
<p>There is not a real conflict between the proposals apart from the
naming. The NOINPUT original proposal was we want to have this
functionality and we’ll do it when the next version of SegWit comes
along. The next version of SegWit is hopefully Taproot. The original
way it was proposed meant that eltoo would’ve had to have been a
CHECKMULTISIG script path rather than key aggregation Schnorr key path
potentially. It is not technically any worse than what the original
concept was by having to go through the script path. It is just the
next progression now that we have some idea what the next version of
SegWit should look like.</p>
</blockquote>

CC BY-SA 4.0
2023-02-21T19:11:01.770Z
Clarification: SIGHASH_NOINPUT effectively _became_ SIGHASH_ANYPREVOUT. The change was a change in a name to reflect that certain parts of the input  were committed still being committed to [nSequence], just not the signature.
Paul Kania
CC BY-SA 4.0
2021-03-14T14:47:42.587Z
2021-07-29T10:11:17.433Z
2021-07-29T10:11:17.433Z
Michael Folkson
<p>I understand the motivation for SIGHASH_NOINPUT - it would help with offchain payment channels. It was proposed already in the Lightning paper but Eltoo will effectively work just with something like that. But what exactly is the ANYPREVOUT BIP about? It seems like some extension to be used with taproot scripts. But I don't seem to get why you need a special public key type and chaperone signatures. Can anyone explain this part in plain english please?</p>

CC BY-SA 4.0
2019-12-26T10:40:52.000Z
I guess this is some sort of additional opt-in as it could be dangerous to not commit to at least one previous tx, preventing replay of known signature. But what I am struggling with is why isn't the special sighash flag enough for this - if you specify it you probably know what you are doing, no? Probably I'd also need a bit of explanation on taproot scripts - I believe taproot is meant so that unless the special condition is used everything looks like a normal P2(W)PKH spend. How does different public key fit into this?
fiction
CC BY-SA 4.0
2021-09-24T12:20:49.237Z
Perhaps just an update, there is another similar solution Inherited IDs https://github.com/JohnLaw2/btc-iids/blob/main/iids13.pdf
fiction
<sighash><eltoo><bip118-sighash-anyprevout>
BIP118 (SIGHASH_NOINPUT) vs. ANYPREVOUT
fiction
# BIP118 (SIGHASH_NOINPUT) vs. ANYPREVOUT

(Asked by: username_0 on 2019-12-24)

I understand the motivation for SIGHASH\_NOINPUT - it would help with offchain payment channels. It was proposed already in the Lightning paper but Eltoo will effectively work just with something like that. But what exactly is the ANYPREVOUT BIP about? It seems like some extension to be used with taproot scripts. But I don't seem to get why you need a special public key type and chaperone signatures. Can anyone explain this part in plain english please?

**Tags:** sighash, eltoo, bip118-sighash-anyprevout

> **Comments:**
> **username_0**: I guess this is some sort of additional opt-in as it could be dangerous to not commit to at least one previous tx, preventing replay of known signature. But what I am struggling with is why isn't the special sighash flag enough for this - if you specify it you probably know what you are doing, no? Probably I'd also need a bit of explanation on taproot scripts - I believe taproot is meant so that unless the special condition is used everything looks like a normal P2(W)PKH spend. How does different public key fit into this?  
> **username_0**: Perhaps just an update, there is another similar solution Inherited IDs https://github.com/JohnLaw2/btc-iids/blob/main/iids13.pdf  

---

## 1 answers

### Answer by username_1 on 2021-03-14. Score: 1

The differences between SIGHASH\_NOINPUT ([BIP 118](https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki)) and SIGHASH\_ANYPREVOUT ([proposed update to BIP 118](https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki)) were discussed at the Sydney [Socratic Seminar](https://btctranscripts.com/sydney-bitcoin-meetup/2020-07-21-socratic-seminar/#bip-118-and-sighash_anyprevout) in July 2020.

> There is not a real conflict between the proposals apart from the
> naming. The NOINPUT original proposal was we want to have this
> functionality and we’ll do it when the next version of SegWit comes
> along. The next version of SegWit is hopefully Taproot. The original
> way it was proposed meant that eltoo would’ve had to have been a
> CHECKMULTISIG script path rather than key aggregation Schnorr key path
> potentially. It is not technically any worse than what the original
> concept was by having to go through the script path. It is just the
> next progression now that we have some idea what the next version of
> SegWit should look like.

> **Comments:**
> **username_2**: Clarification: SIGHASH_NOINPUT effectively _became_ SIGHASH_ANYPREVOUT. The change was a change in a name to reflect that certain parts of the input  were committed still being committed to [nSequence], just not the signature.  

---

