If we sign the txids of all inputs, we should also explicitly commit to their
values. Only this could fully eliminate any possible way to lie about input
value to hardware wallets
> Does it make sense to keep SIGHASH_NONE?
SIGHASH_NONE should be kept. ANYONECANPAY|NONE allows donation of dust UT
On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> So my question is whether anyone can see ways in which this introduces
> redundant flexibility, or misses obvious use cases?
>
Hopefully my comment is on-topic for this thread:
Given
Anthony Towns via bitcoin-dev
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. Any
Hi Pieter,
great proposal, I think this may address some of the (perceived)
downsides of BIP118, by committing to the script when possible
(always?). One minor thing that I noticed a while ago and that I meant
to fix on BIP118 is that `hashSequence` does not need to be blanked for
eltoo to work (s
