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 71AC6E89 for ; Fri, 21 Dec 2018 18:55:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E8E9832 for ; Fri, 21 Dec 2018 18:55:05 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1545418490; cv=none; d=zoho.com; s=zohoarc; b=MkeSgpFp2hOZdvIjDby5j/RBLKxRSQbJ7AQZQ75eFPYMTgYvWNoT+Uoiuc8uqU5Cht3lkMusfDmlZLN3EVy8Y1+SK5L2eYOqNwyCVtinYi2CPdODRNNFz1tu/0+CtxWdEyw5Jm6ylfAu/1WFpJ++sPUYDss1LmFK03VlJM12GgU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1545418490; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=Ad7+zE2n5AApMM13qJ6MhB3v4JHOce3DuVbizeuO6Jo=; b=DKrJU8F+ekGzLqlYVwmEXHmvRv6KXPnz1RPPfUty7XEsmlDEDValWUgNIQSHz5+xRkHhp9GOKhNiF0zDaoPsHjbsOH6t1MFgZcxK5z4AspVXVVdB39Q9B/m1RrYjKjGKdgRbEXx7BDPucQ91DCTgOHINa/S7ydZf/Vk4Bjg9HdI= 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 1545418488831772.199390789455; Fri, 21 Dec 2018 10:54:48 -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: <87y38jn5z8.fsf@rustcorp.com.au> Date: Sat, 22 Dec 2018 02:54:42 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <73F32BC6-751E-4F35-BE6D-B31170FC0A54@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> <87y38jn5z8.fsf@rustcorp.com.au> To: Rusty Russell 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: Fri, 21 Dec 2018 23:30:36 +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: Fri, 21 Dec 2018 18:55:06 -0000 > On 21 Dec 2018, at 7:17 AM, Rusty Russell = wrote: >=20 > Johnson Lau writes: >=20 >>> 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 >>=20 >> Let me elaborate more. Currently, scriptCode is truncated at the last = executed CODESEPARATOR. If we have a very big script with many = CODESEPARATORs and CHECKSIGs, there will be a lot of hashing to do. >>=20 >> To fix this problem, it is proposed that the new sighash will always = commit to the same H(script), instead of the truncated scriptCode. So we = only need to do the H(script) once, even if the script is very big >=20 > 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. >=20 >> In the case of NOINPUT with MASKEDSCRIPT, it will commit to the = H(masked_script) instead of H(script). >>=20 >> To make CODESEPARATOR works as before, the sighash will also commit = to the position of the last executed CODESEPARATOR. So the semantics = doesn=E2=80=99t change. For scripts without CODESEPARATOR, the committed = value is a constant. >>=20 >> IF NOINPUT does not commit to H(masked_script), technically it could = still 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 the 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 CODESEPARATOR is blah blah blah=E2=80=9D. It = still works if the assumptions hold, but sounds quite unreliable to me. >=20 > 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." >=20 > 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? >=20 > Thanks, > Rusty. The question I would like to ask is: is OP_CODESEPARATOR useful under = taproot? Generally speaking, CODESEPARATOR is useful only with = conditional opcodes (OP_IF etc), and conditional opcodes are mostly = replaced by merklized scripts. I am not sure how much usability is left = with CODESEPARATOR If no one needs CODESEPARATOR, we might just disable it, and makes the = validation code a bit simpler If CODESEPARATOR is useful, then we should find a way to make it works = with NOINPUT. With H(masked_script) committed, the meaning of the = CODESEPARATOR position is very clear. Without H(masked_script), the = meaning of the position totally relies on the assumption that =E2=80=9Cthi= s public key is only used in this script template=E2=80=9D. Ignore CODESEPARATOR and more generally, I agree with you that script = masking does not help in the case of address (scriptPubKey) reuse, which = is the commonest type of reuse. However, it prevents replayability when = the same public key is reused in different scripts=