Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: > 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. Cheers, Christian _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
