Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 45E0688A for ; Wed, 21 Nov 2018 17:55:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C52C2D4 for ; Wed, 21 Nov 2018 17:55:35 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1542822928; cv=none; d=zoho.com; s=zohoarc; b=nlBq9gfQQvAF5p+2lO7knMEz4yidxdbE/tzpSbUThrbpAtTayA91CzCqArxz02c518iN68RDolrO0cyprOwxOYgXRjSYooFBPnpW9LCXK3upd/6JI9P1LiO83RRKSPYo9fyoxWzIkTuA91EVLMSFiDhHh7l3QGkVdjLympR+p+4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1542822928; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=XySCUQLTjkJn1NrSqATnmCSwcvwDfvp2f8laC7NdTH4=; b=aXvgveQri7lMgmjQdjv0kofV5mNDDk0ieo9OMnnyAFlAa2zU/w7ddnY+mHzTlYfbgUCKlpqQ84Iw1JoaDwLwnkqmnBOVqYy3slRtT2hxAVDslupInp531GfpPrzqQXEtBReZ+ddwszjrLZ/2v+zjOdIZrrBnztjsh1d1SltmcMs= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118]) by mx.zohomail.com with SMTPS id 1542822927669137.6294812894621; Wed, 21 Nov 2018 09:55:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Johnson Lau In-Reply-To: <20181120202904.gmbg5ebegvsgqfys@erisian.com.au> Date: Thu, 22 Nov 2018 01:55:22 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2FCAFF04-2449-42C9-9613-EF0F8272259D@xbt.hk> References: <20181120202904.gmbg5ebegvsgqfys@erisian.com.au> To: Anthony Towns , bitcoin-dev X-Mailer: Apple Mail (2.3445.100.39) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 22 Nov 2018 14:08:02 +0000 Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 17:55:37 -0000 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=E2=80=A6=E2=80=A6. 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. =E2=80=A6... 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=E2=80=99t 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=E2=80=99t = 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=E2=80=99m not = sure who would actually need NOINPUT with KNOWNSCRIPT > On 21 Nov 2018, at 4:29 AM, Anthony Towns via bitcoin-dev = wrote: >=20 > 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). >=20 > Current flags are {ALL, NONE, SINGLE} and ANYONECANPAY, and the BIP143 > tx digest consists of the hash of: >=20 > 1 nVersion > 4 outpoint > 5 input scriptCode > 6 input's outpoint value > 7 input's nSeq > 9 nLocktime > 10 sighash >=20 > 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 >=20 > The fee is committed to by hashPrevOuts and hashOutputs, which means > NOFEE is only potentially useful if ANYONECANPAY or NONE or SINGLE is = set. >=20 > For NOINPUT, (2),(3),(4) are cleared, and SCRIPTMASK (which munges = (5)) > is only useful given NOINPUT, since (4) indirectly commits to (5).=20 >=20 > Given this implementation, NOINPUT effectively implies ANYONECANPAY, > I think. (I think that is also true of BIP 118's NOINPUT spec) >=20 > Does it make sense to treat this as two classes of options, affecting > the input and output side: >=20 > 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 >=20 > 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 >=20 > combo: (flag, bit 6) > * NOFEE -- don't commit to the fee >=20 > 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. >=20 > (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) >=20 > FWIW, OP_MASK seems a bit complicated to me. How would you mask a = script > that looks like: >=20 > OP_MASK IF

ENDIF ... >=20 > or: >=20 > IF OP_MASK ENDIF

... >=20 > 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?) >=20 > I don't have a reason why, but committing to the scriptCode feels to = me > like it reduces the "hackiness" of NOINPUT a lot. >=20 > Cheers, > aj >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev