Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 71FA81487 for ; Thu, 20 Dec 2018 19:35:01 +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 B77062C4 for ; Thu, 20 Dec 2018 19:35:00 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1545334485; cv=none; d=zoho.com; s=zohoarc; b=XgiWopQgEEIrVRlWfva20Pl4HJC2eTk9BEbKFeMNIsn9j6D/uhP0hnw1H7RV2UZfFQEeGKt1bOLzz+5cT6OE6yKODGoHE1p0N/DYQKM5SIgcIWEt1iqDH0pHEuhzPbqgIffu7ynDWgEXSJiaYHn2j6inD6UIrIIlv7kIVjJTDzo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1545334485; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=FJKZBVi+TGDtp5qZtrd/RfhG05JipUr5io3nI31mm8M=; b=TvMzddPvP3ejT994frzbR3zQGl5lC+0RpZ6kz7vf0I+DRkOlFVRrT5x8+E5CXB4Z6WUPOFn5G3ND9eXf2gz2REQmAUmCG+VxPPSo/f8TCQu85ovYjV+xH3zzl79yNnRjT0JAx0gpuX2xOKK4stxY2WHPR/YAEJ7caz126XXef8A= 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 1545334485135358.68313382752854; Thu, 20 Dec 2018 11:34:45 -0800 (PST) From: Johnson Lau Message-Id: <2302A26C-FB9C-47D2-AF6C-4D2EF02FFAC0@xbt.hk> Content-Type: multipart/alternative; boundary="Apple-Mail=_18858869-DFFC-4C17-A3B1-668D72B90E86" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Fri, 21 Dec 2018 03:34:38 +0800 In-Reply-To: <87mup4hmq5.fsf@rustcorp.com.au> To: Rusty Russell 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> X-Mailer: Apple Mail (2.3445.100.39) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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, 20 Dec 2018 21:58:07 +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 19:35:01 -0000 --Apple-Mail=_18858869-DFFC-4C17-A3B1-668D72B90E86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Dec 2018, at 11:10 AM, Rusty Russell = wrote: >=20 > Johnson Lau writes: >> I don=E2=80=99t think this has been mentioned: without signing the = script or masked script, OP_CODESEPARATOR becomes unusable or insecure = with NOINPUT. >>=20 >> In the new sighash proposal, we will sign the hash of the full script = (or masked script), without any truncation. To make OP_CODESEPARATOR = works like before, we will commit to the position of the last executed = OP_CODESEPARATOR. If NOINPUT doesn=E2=80=99t commit to the masked = script, it will just blindly committing to a random OP_CODESEPARATOR = position, which a wallet couldn=E2=80=99t know what codes are actually = being executed. >=20 > 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#issuecomment-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. >=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 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. 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 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 = 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. 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. Johnson --Apple-Mail=_18858869-DFFC-4C17-A3B1-668D72B90E86 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 17 Dec 2018, at 11:10 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:

Johnson Lau <jl2012@xbt.hk> writes:
I don=E2=80=99t think this has been mentioned: = without signing the script or masked script, OP_CODESEPARATOR becomes = unusable or insecure with NOINPUT.

In the = new sighash proposal, we will sign the hash of the full script (or = masked script), without any truncation. To make OP_CODESEPARATOR works = like before, we will commit to the position of the last executed = OP_CODESEPARATOR. If NOINPUT doesn=E2=80=99t commit to the masked = script, it will just blindly committing to a random OP_CODESEPARATOR = position, which a wallet couldn=E2=80=99t know what codes are actually = being executed.

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?


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.



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.


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.

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

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 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.

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.

Johnson

= --Apple-Mail=_18858869-DFFC-4C17-A3B1-668D72B90E86--