Chris Stewart writes:
>> I don't find too compelling the potential problem of a 'bad wallet
> designer', whether lazy or dogmatic, misusing noinput. I think there are
> simpler ways to cut corners and there will always be plenty of good wallet
> options people can choose.
>
> In my original
> I don't find too compelling the potential problem of a 'bad wallet
designer', whether lazy or dogmatic, misusing noinput. I think there are
simpler ways to cut corners and there will always be plenty of good wallet
options people can choose.
In my original post, the business that I am talking
>I don't find too compelling the potential problem of a 'bad wallet designer',
>whether lazy or dogmatic, misusing noinput. I think there are simpler ways to
>cut corners and there will always be plenty of good wallet options people can
>choose.
I want to second this. The most expensive part
Thanks Christian for pulling together this concise summary.
1. General agreement on the usefulness of noinput / anyprevoutanyscript /
> anyprevout.
>
I certainly support the unification and adoption of the sighash_noinput and
anyprevoutput* proposals to enable eltoo, but also to make
With the recently renewed interest in eltoo, a proof-of-concept implementation
[1], and the discussions regarding clean abstractions for off-chain protocols
[2,3], I thought it might be time to revisit the `sighash_noinput` proposal
(BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].
(sorry
