Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-21 📝 Original message:Anthony Towns via ...
📅 Original date posted:2018-11-21
📝 Original message:Anthony Towns via bitcoin-dev <bitcoin-dev at 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
📝 Original message:Anthony Towns via bitcoin-dev <bitcoin-dev at 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