Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: > On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev > wrote: >> Given the general enthusiasm, and lack of major criticism, for the >> `SIGHASH_NOINPUT` proposal, [...] > > So first, I'm not sure if I'm actually criticising or playing devil's > advocate here, but either way I think criticism always helps produce > the best proposal, so.... > > The big concern I have with _NOINPUT is that it has a huge failure > case: if you use the same key for multiple inputs and sign one of them > with _NOINPUT, you've spent all of them. The current proposal kind-of > limits the potential damage by still committing to the prevout amount, > but it still seems a big risk for all the people that reuse addresses, > which seems to be just about everyone.
If I can convince you to sign with SIGHASH_NONE, it's already a problem today. > I wonder if it wouldn't be ... I'm not sure better is the right word, > but perhaps "more realistic" to have _NOINPUT be a flag to a signature > for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead, > so that it's fundamentally not possible to trick someone who regularly > reuses keys to sign something for one input that accidently authorises > spends of other inputs as well. That was also suggested by Mark Friedenbach, but I think we'll end up with more "magic key" a-la Schnorr/taproot/graftroot and less script in future. That means we'd actually want a different Segwit version for "NOINPUT-can-be-used", which seems super ugly. > Maybe a different opcode maybe makes sense at a "philosophical" level: > normal signatures are signing a spend of a particular "coin" (in the > UTXO sense), while _NOINPUT signatures are in some sense signing a spend > of an entire "wallet" (all the coins spendable by a particular key, or > more accurately for the current proposal, all the coins of a particular > value spendable by a particular key). Those are different intentions, > so maybe it's reasonable to encode them in different addresses, which > in turn could be done by having a new opcode for _NOINPUT. In a world where SIGHASH_NONE didn't exist, this might be an argument :) Cheers, Rusty. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
