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 07AA7D98 for ; Wed, 12 Dec 2018 23:49:16 +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 D9E3F782 for ; Wed, 12 Dec 2018 23:49:14 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 43FYS906BBz9s7T; Thu, 13 Dec 2018 10:49:12 +1100 (AEDT) From: Rusty Russell To: Johnson Lau , bitcoin-dev In-Reply-To: References: <87ftv3xerx.fsf@rustcorp.com.au> Date: Thu, 13 Dec 2018 10:19:02 +1030 Message-ID: <87pnu6s3v5.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: Thu, 13 Dec 2018 22:09:29 +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, 12 Dec 2018 23:49:16 -0000 Johnson Lau writes: >> On 12 Dec 2018, at 5:42 PM, Rusty Russell via bitcoin-dev wrote: >>=20 >> Pieter Wuille via bitcoin-dev wr= ites: >>> 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. >>=20 >> Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always >> perform mask-removal for signing? > > Because a hardware wallet may want to know what exact script it is signin= g? OK, removing OP_MASKs unconditionally would introduce a hole without some explicit flag to say they've been removed (the "real script" could be something different with OP_MASKs). We could have the signature commit to the outputscript, but that's a bit meh. > Masked script has reduced security, but this is a tradeoff with > functionality (e.g. eltoo can=E2=80=99t work without masking part of the > script). So when you don=E2=80=99t need that extra functionality, you go = back > to better security > > However, I=E2=80=99m not sure if there is any useful NOINPUT case with un= masked script. This is *not* true of Eltoo; the script itself need not change for the rebinding (Christian, did something change?). So, can we find an example where OP_MASK is useful? >> If you're signing arbitrary scripts, you're surely in trouble already? >>=20 >> And I am struggling to understand the role of scriptmask in a taproot >> world, where the alternate script is both hidden and general? > > It makes sure that your signature is applicable to a specific script bran= ch, not others (assuming you use the same pubkey in many branches, which is= avoidable) If I'm using SIGHASH_NOINPUT, I'm already required to take care with key reuse. Without a concrete taproot proposal it's hard to make assertions, but if the signature flags that it's using the taproot script, it's no less safe, and more general AFAICT. Thanks! Rusty.