[bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

Christian Decker decker.christian at gmail.com
Wed Nov 21 11:20:44 UTC 2018

Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Given this implementation, NOINPUT effectively implies ANYONECANPAY,
> I think. (I think that is also true of BIP 118's NOINPUT spec)

I mentioned this in my reply to Pieter, but this may not be true if we
remove the blanking of the `hashSequence` field. Anyonecanpay would
allow changing the number of inputs in an arbitrary fashion, while
`noinput` without the blanking would (in a weird roundabout way) still
commit to the number of inputs. Maybe we want to make that more explicit
by also hashing the number of inputs? But I can't think of a good
usecase for keeping that, with noinput.


More information about the bitcoin-dev mailing list