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 EDE23C77 for ; Wed, 27 Jun 2018 07:29:17 +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 7E05F17E for ; Wed, 27 Jun 2018 07:29:17 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1fY4t7-0002m1-Pm; Wed, 27 Jun 2018 17:29:15 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Wed, 27 Jun 2018 17:29:09 +1000 Date: Wed, 27 Jun 2018 17:29:09 +1000 From: Anthony Towns To: Pieter Wuille , Bitcoin Protocol Discussion Message-ID: <20180627072909.5hqnl4kfrnqfvhc4@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Subject: Re: [bitcoin-dev] Should Graftroot be optional? 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, 27 Jun 2018 07:29:18 -0000 On Thu, May 31, 2018 at 05:25:04PM -0700, Pieter Wuille via bitcoin-dev wrote: > The best argument for why Graftroot does not need to be optional I > think was how Greg put it: "since the signer(s) could have signed an > arbitrary transaction instead, being able to delegate is strictly less > powerful.". This seems persuasive to me. I think you could implement graftroot in a way that makes this explicit: * A graftroot input has >=2 items on the witness stack, a signature, a script (S), and possibly witness elements for the script. The signature has a SIGHASH_GRAFTROOT bit set. * To validate the signature, a virtual transaction is constructed: nVersion = 1 locktime = 0 inputs = [(txhash, txoutidx, 0, "", 0xffffffff)] outputs = [(txvalue, len(S), S)] locktime = 0 The signature is then checked against the virtual transaction. * If the signature is valid, the virtual transaction is discarded, and the script and witness elements are checked against the original tx. I think this approach (or one like it) would make it clear that graftroot is a simple optimisation, rather than changing the security parameters. Some caveats: * You'd presumably want to disallow signatures with SIGHASH_GRAFTROOT from being used in signatures in scripts, so as not to end up having to support recursive graftroot. * Checking the script/witness against the original transaction instead of the virtual one cheats a bit, but something like it is necessary to ensure locktime/csv checks in the script S behave sanely. You could have the virtual transaction be treated as being confirmed in the same block as the original transaction instead though, I think. * You would need to use SIGHASH_NOINPUT (or similar) in conjuction to allow graftroot delegation prior to constructing the tx (otherwise the signature would be committing to txhash/txoutidx). BIP118 would still commit to txvalue, but would otherwise work fine, I think. Cheers, aj