Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E085F8A6 for ; Wed, 6 Jun 2018 12:48:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8E9874F for ; Wed, 6 Jun 2018 12:48:06 +0000 (UTC) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id E99464651B for ; Wed, 6 Jun 2018 14:48:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id j-0qmK1cOi6l for ; Wed, 6 Jun 2018 14:48:02 +0200 (CEST) Message-ID: From: Tim Ruffing To: bitcoin-dev@lists.linuxfoundation.org Date: Wed, 06 Jun 2018 14:48:01 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW 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: Wed, 06 Jun 2018 12:49:47 +0000 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, 06 Jun 2018 12:48:08 -0000 I haven't read the original Graftroot thread, so maybe all of this has b een discussed already or is just wrong... Please correct me if this is the case. On Thu, 2018-05-31 at 17:25 -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.". I'm trying to get a more abstract view of the problem. One issue with Greg's argument is the following: If g-script is a script (containing a public key) that allows for Graftroot spending, then the following "flow" of coins is valid: g-script --g-sig--> script1 ---tx2---> script2 Here, g-sig is a Graftroot signature on script1 and tx2 is a transaction that fulfills script1 and sends to script2. In other words, the only transaction involved here is tx2; it provides g-sig, script1, and a solution for tx1, and it spends to script2. Now Greg's argument (as I understand it) is that this can be already done without Grafroot with two transactions, namely a normal transaction tx1 that spends g-script normally and tx2 that spends tx1 to script1. g-script ---tx1---> script1 ---tx2---> script2. So far, so good. A difference however is that g-sig *alone* can't be committed to the chain but tx1 alone can be committed to the chain. That means g-script --g-sig--> script1 (*) is "incomplete" but g-script ---tx1---> script1 (**) is a perfectly valid transaction that can be committed to the chain. So I think Graftroot delegation is not "strictly less powerful" than just using a normal transaction: Graftroot enables to delegate in a way such that the delegation itself cannot be fixed in the chain. I think this is not possible currently. (Okay, you can just pass around the secret keys but has other problems obviously). Does this have practical implications? I don't see any but maybe this helps someone to identify an undesirable implication. One way to be on the safe side and probably make Greg's argument go through is to just define the semantics such that (*) is allowed, i.e., call g-sig a "Graftroot transaction" and give it transaction semantics. This provides a new perspective on Graftroot: Then Graftroot does not introduce new semantics but (*) is just an optimized version of (**) that uses fewer bytes and may be better for privacy. Interestingly Andrew's blind-sig example and Johnson's fix (g-sig signs the outpoint) are just a special case. If g-sig has transaction semantics, it must sign the outpoint (and other stuff). Now you can say that this is not really useful: if g-sig is essentially a full transaction that can committed to the blockchain, then it needs to specify inputs, outputs etc. So all the optimizations are lost and those were the reason we want to introduce Grafroot in the first place. But one observation here is that g-sig only needs to be a full transaction if it's used standalone as in (*). If we want to have g-script --g-sig--> script1 ---tx2---> script2 (and this should be the common case) then just the bare signature and script1 suffices, as in the Graftroot proposal. In some sense, inputs and outputs of the Graftroot transaction are just implicit in this case. Another way to look at this that instead of providing a transaction with g-sig, script1, and a solution for script1, you can also choose to provide a transaction with only g-sig and script1 (and don't solve script1), which then just sends to script1. I'm not saying that it's worth the hassle to add this possibility without being aware of a problem that arises if we don't add it -- but maybe my thoughts provide another perspective on the issue. Best, Tim