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 UTXOs to miners > I think NONE without NOFEE doesn't make much sense……. We might refuse to sign weird combinations like NOFEE|ALLINPUT|ALLOUTPUT. But to keep the consensus logic simple, we should just validate it as usual. > OP_MASK seems a bit complicated to me. …... Yes, it looks complicated to me, and it improves security only in some avoidable edge cases in SIGHASH_NOINPUT: The common case: the exact masked script or address is reused. OP_MASK can’t prevent signature replay since the masked script is the same. The avoidable case: the same public key is reused in different script templates. OP_MASK may prevent signature replay is the masked script is not the same. The latter case is totally avoidable since one could and should use a different public key for different script. It could be made much simpler as NOINPUT with/without SCRIPT. This again is only helpful in the avoidable case above, but it doesn’t bring too much complexity. > I don't have a reason why, but committing to the scriptCode feels to me like > it reduces the "hackiness" of NOINPUT a lot. OP_MASK is designed to preserve the hackiness, while provide some sort of replay protection (only in avoidable cases). However, I’m not sure who would actually need NOINPUT with KNOWNSCRIPT > On 21 Nov 2018, at 4:29 AM, Anthony Towns via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Mon, Nov 19, 2018 at 02:37:57PM -0800, Pieter Wuille via bitcoin-dev wrote: >> Here is a combined proposal: >> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, >> and SIGHASH_SCRIPTMASK. >> * A new opcode OP_MASK is added, which acts as a NOP during execution. >> * The sighash is computed like in BIP143, but: >> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode >> the subsequent opcode/push is removed. >> * The scriptPubKey being spent is added to the sighash, unless >> SIGHASH_SCRIPTMASK is set. >> * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set. >> * hashPrevouts, hashSequence, and outpoint are set to null when >> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode). > > Current flags are {ALL, NONE, SINGLE} and ANYONECANPAY, and the BIP143 > tx digest consists of the hash of: > > 1 nVersion > 4 outpoint > 5 input scriptCode > 6 input's outpoint value > 7 input's nSeq > 9 nLocktime > 10 sighash > > 2 hashPrevOuts (commits to 4,5,6; unless ANYONECANPAY) > 3 hashSequence (commits to 7; only if ALL and not ANYONECANPAY) > 8 hashOutputs > - NONE: 0 > - SINGLE: {value,scriptPubKey} for corresponding output > - otherwise: {value,scriptPubKey} for all outputs > > The fee is committed to by hashPrevOuts and hashOutputs, which means > NOFEE is only potentially useful if ANYONECANPAY or NONE or SINGLE is set. > > For NOINPUT, (2),(3),(4) are cleared, and SCRIPTMASK (which munges (5)) > is only useful given NOINPUT, since (4) indirectly commits to (5). > > Given this implementation, NOINPUT effectively implies ANYONECANPAY, > I think. (I think that is also true of BIP 118's NOINPUT spec) > > Does it make sense to treat this as two classes of options, affecting > the input and output side: > > output: (pick one, using bits 0,1) > * NONE -- don't care where the money goes > * SINGLE -- want this output > * ALL -- want exactly this set of outputs > > input: (pick one, using bits 4,5) > * PARTIALSCRIPT -- spending from some tx with roughly this script (and > maybe others; SCRIPTMASK|NOINPUT|ANYONECANPAY) > * KNOWNSCRIPT -- spending from some tx with exactly this script (and > maybe others; NOINPUT|ANYONECANPAY) > * KNOWNTX -- spending from this tx (and maybe others; ANYONECANPAY) > * ALL_INPUTS -- spending from exactly these txes > > combo: (flag, bit 6) > * NOFEE -- don't commit to the fee > > I think NONE without NOFEE doesn't make much sense, and > NOFEE|ALL|ALL_INPUTS would also be pretty weird. Might make sense to > warn/error on signing when asking for those combinations, and maybe even > to fail on validating them. > > (Does it make sense to keep SIGHASH_NONE? I guess SIGHASH_NONE|ALL_INPUTS > could be useful if you just use sigs on one of the other inputs to commit > to a useful output) > > FWIW, OP_MASK seems a bit complicated to me. How would you mask a script > that looks like: > > OP_MASK IF <p> ENDIF <q> ... > > or: > > IF OP_MASK ENDIF <p> ... > > I guess if you make the rule be "for every OP_MASK in scriptCode the > *immediately* subsequent opcode/push is removed (if present)" it would > be fine though -- that would make OP_MASK in both the above not have > any effect. (Maybe a more explicit name like "MASK_PUSH_FOR_SIGHASH" > or something might be good?) > > I don't have a reason why, but committing to the scriptCode feels to me > like it reduces the "hackiness" of NOINPUT a lot. > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev