Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6D1409BA for ; Thu, 13 Dec 2018 00:24:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6232835 for ; Thu, 13 Dec 2018 00:24:48 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1gXEnz-0006Mj-Bb; Thu, 13 Dec 2018 10:24:45 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 13 Dec 2018 10:24:38 +1000 Date: Thu, 13 Dec 2018 10:24:38 +1000 From: Anthony Towns To: Rusty Russell , Bitcoin Protocol Discussion Message-ID: <20181213002438.r3bylrjcpwit5v2k@erisian.com.au> References: <87ftv3xerx.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ftv3xerx.fsf@rustcorp.com.au> User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 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: Thu, 13 Dec 2018 00:24:49 -0000 On Wed, Dec 12, 2018 at 08:12:10PM +1030, Rusty Russell via bitcoin-dev wrote: > Pieter Wuille via bitcoin-dev writes: > > 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. > I'm asking on-list because I'm sure I'm not the only confused one. > Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always > perform mask-removal for signing? The way I'm thinking about it is there's four amounts of knowledge you could have about the input you're spending at the time you generate a signature: ALL: you know everything about every input for this tx SINGLE: you know everything about the input you're signing for, but not necessarily the others SCRIPTPUBKEY: you know the exact scriptPubKey you're trying to satisfy, but don't know the txid SCRIPTMASK: you don't know the txid, don't know the scriptPubKey, don't know the other taproot branches, and maybe don't even know the masked out terms in the script -- but you do know the structure of the script, and the non-masked terms There's no value to masking in any but the final case -- the txid and scriptPubKey commit to the full scriptcode already, so also signing the scriptcode is just belt-and-suspenders protection. (It might be that the "SCRIPTPUBKEY" option isn't very useful in practice; maybe you'll always either know the txid, or need to mask something?) > And I am struggling to understand the role of scriptmask in a taproot > world, where the alternate script is both hidden and general? In a taproot world, your scriptPubKey is a point P=Q+H(Q,S)*G, where S is a merkle root of possibly many scripts, and is spendable either by: sig(P) Q, path(S,script), script, witness(script) SCRIPTMASK lets you prepare a signature for one particular script in advance, even before you've decided what the other scripts are (and even what the base point Q is), let alone built an actual transaction. At least, that's my current understanding; and I think it makes sense... Cheers, aj