From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7F57EF4B for ; Thu, 20 Dec 2018 23:17:54 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [203.11.71.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C362800 for ; Thu, 20 Dec 2018 23:17:53 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 43LSNH2T33z9sDN; Fri, 21 Dec 2018 10:17:51 +1100 (AEDT) From: Rusty Russell To: Johnson Lau In-Reply-To: <2302A26C-FB9C-47D2-AF6C-4D2EF02FFAC0@xbt.hk> References: <87ftv3xerx.fsf@rustcorp.com.au> <87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au> <20181214093002.p2nvfrlaycqblww3@erisian.com.au> <87mup4hmq5.fsf@rustcorp.com.au> <2302A26C-FB9C-47D2-AF6C-4D2EF02FFAC0@xbt.hk> Date: Fri, 21 Dec 2018 09:47:15 +1030 Message-ID: <87y38jn5z8.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 21 Dec 2018 03:43:51 +0000 Cc: bitcoin-dev 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: Thu, 20 Dec 2018 23:17:54 -0000 Johnson Lau writes: >> On 17 Dec 2018, at 11:10 AM, Rusty Russell wrote: >> My anti-complexity argument leads me to ask why we'd support >> OP_CODESEPARATOR at all? Though my argument is weaker here: no wallet >> need support it. > > Because it could make scripts more compact in some cases? > > This is an example: https://github.com/bitcoin/bitcoin/pull/11423#issueco= mment-333441321 > > But this is probably not a good example for taproot, as it could be more = efficient by making the 2 branches as different script merkle leaves. Thanks, I hadn't seen this before! That's also the first time I've seen SIGHASH_NONE used. >> But I don't see how OP_CODESEPARATOR changes anything here, wrt NOINPUT? >> Remember, anyone can create an output which can be spent by any NOINPUT, >> whether we go for OP_MASK or simply not commiting to the input script. >>=20 > > Let me elaborate more. Currently, scriptCode is truncated at the last exe= cuted CODESEPARATOR. If we have a very big script with many CODESEPARATORs = and CHECKSIGs, there will be a lot of hashing to do. > > To fix this problem, it is proposed that the new sighash will always comm= it to the same H(script), instead of the truncated scriptCode. So we only n= eed to do the H(script) once, even if the script is very big Yes, I read this as proposed, it is clever. Not sure we'd be introducing it if OP_CODESEPARATOR didn't already exist, but at least it's a simplfication. > In the case of NOINPUT with MASKEDSCRIPT, it will commit to the H(masked_= script) instead of H(script). > > To make CODESEPARATOR works as before, the sighash will also commit to th= e position of the last executed CODESEPARATOR. So the semantics doesn=E2=80= =99t change. For scripts without CODESEPARATOR, the committed value is a co= nstant. > > IF NOINPUT does not commit to H(masked_script), technically it could stil= l commit to the position of the last executed CODESEPARATOR. But since the = wallet is not aware of the actual content of the script, it has to guess th= e meaning of such committed positions, like =E2=80=9Cwith the HD key path m= /x/y/z, I assume the script template is blah blah blah because I never use = this path for another script template, and the meaning of signing the 3rd C= ODESEPARATOR is blah blah blah=E2=80=9D. It still works if the assumptions = hold, but sounds quite unreliable to me. My question is more fundamental. If NOINPUT doesn't commit to the input at all, no script, no code separator, nothing. I'm struggling to understand your original comment was "without signing the script or masked script, OP_CODESEPARATOR becomes unusable or insecure with NOINPUT." I mean, non-useful, sure. Its purpose is to alter signature behavior, and from the script POV there's no signature with this form of NOINPUT. But other than the already-established "I reused keys for multiple outputs" oops, I don't see any new dangers? Thanks, Rusty.