I do have some concerns about SIGHASH_NOINPUT, mainly that it does
introduce another footgun into the bitcoin protocol with address reuse.
It's common practice for bitcoin businesses to re-use addresses. Many
exchanges [1] reuse addresses for cold storage with very large sums of
money that is
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
Good morning lists,
Let me summarize concerns brought up:
* Chris concern, is that an ordinary UTXO that is not allocated for
`SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`.
* My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is
*indeed* used with
On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote:
> Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,
> `OP_CHECKSIG_WITHOUT_INPUT`.
I don't think there's any meaningful difference between making a new
opcode and making a new tapscript public key type; the
> 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
Good morning Christian,
> > - A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction
> > Output, confirmed onchain
> > - A "translator transaction" spending the above and paying out to a
> > SegWit v16 output-tagged output, kept offchain.
> > - Decker-Russell-Osuntokun update
ZmnSCPxj writes:
> To elucidate further ---
>
> Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,
> `OP_CHECKSIG_WITHOUT_INPUT`.
>
> This new opcode ignores any `SIGHASH` flags, if present, on a
> signature, but instead hashes the current transaction without the
> input references,
ZmnSCPxj writes:
> I rather strongly oppose output tagging.
>
> The entire point of for example Taproot was to reduce the variability
> of how outputs look like, so that unspent Taproot outputs look exactly
> like other unspent Taproot outputs regardless of the SCRIPT (or lack
> of SCRIPT) used
>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
Good morning aj,
> On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote:
>
> > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,
> > `OP_CHECKSIG_WITHOUT_INPUT`.
>
> I don't think there's any meaningful difference between making a new
> opcode and making a new
On Mon, Sep 30, 2019 at 03:23:56PM +0200, Christian Decker via bitcoin-dev
wrote:
> 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
Good morning lists,
Let me propose the below radical idea:
* `SIGHASH` flags attached to signatures are a misdesign, sadly retained from
the original BitCoin 0.1.0 Alpha for Windows design, on par with:
* 1 RETURN
* higher-`nSequence` replacement
* DER-encoded pubkeys
* unrestricted
12 matches
Mail list logo
