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 02C46D2F for ; Thu, 21 Jun 2018 07:09:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-1857040130.protonmail.ch (mail-1857040130.protonmail.ch [185.70.40.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1F4084DA for ; Thu, 21 Jun 2018 07:09:24 +0000 (UTC) Date: Thu, 21 Jun 2018 03:09:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1529564961; bh=bocvGLS/Wqr1zF6xyDfFmD0EvCGhVORaygUqEGGBKxM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=mzkEeu/nZOlyDZtbOpodxqVevmaUZhyDD8tOko7e0uEJ3iUCQd4hB84D+ZzjvBV8/ 0UuKIzmsSuzW6R4mWjLanrfdLknnlLurVN3jhFKJG4oxsa78pLvKp5IE7rfCxKH2Zl E88kxGqi6nrQ6+yU0gbzWiRJ1DBIE2BdbYlhcs+o= To: Gregory Maxwell From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <01976660b06809ea27af7db4bbceb08220ea2568.camel@timruffing.de> <7nh2F_OPfoHDxrXVG8Dlu51iJ4nnlLFo962B7gI1cN3nyLupsjjlZF9-2nO525E5ENlhMSXprJWkHty8AAxe7W7FRZZpv00C0BptZZcvzK8=@protonmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, 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: Thu, 21 Jun 2018 12:25:58 +0000 Cc: Bitcoin Protocol Discussion 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: Thu, 21 Jun 2018 07:09:25 -0000 Good morning Greg, > On Wed, Jun 20, 2018 at 12:12 PM, ZmnSCPxj via bitcoin-dev >=20 > bitcoin-dev@lists.linuxfoundation.org wrote: >=20 > > This has the advantage that the Graftroot signature commits to a single= outpoint and cannot be used to spend all outpoints that happen to pay to t= he same `P` public key. >=20 > If it isn't possible to make a graftroot signature independent of the >=20 > outpoint then the functionality is greatly reduced to the point of >=20 > largely mooting it-- because you could no longer prepare the grafts >=20 > before the coins to be spent existed, and meaning you must stay online >=20 > and sign new grafts as coins show up. In my view graft's two main >=20 > gains are being able to delegate before coins exist and making the >=20 > conditional transfer atomic (e.g. compared to just pre-signing a >=20 > transaction). Making outpoint binding optional, so that you could >=20 > choose to either sign for particular outputs or in a blanket way would >=20 > be a lot more useful. >=20 Perhaps `SIGHASH_NOINPUT` can do this? One can argue that the option to not= commit a signature to refer to a specific outpoint is orthogonal to the op= tion to Graftroot, so having a separate flag for that makes sense. The proposal could then be: 1. Define a transaction `nVersion` reserved for Graftroot. Transactions wit= h that `nVersion` are disallowed in blocks. 2. If a next-SegWit-version P2WPKH (or P2WPK) is spent, and the top witness= stack item is a signature with `SIGHASH_GRAFTROOT` flag, then this is a Gr= aftroot spend. 3. The signature signs an imaginary 1-input 1-output tx, with the input cop= ied from the spending tx, the output value being the entire output being sp= ent, and the output `scriptPubKey` being the Graftroot script (second to to= p witness stack). The imaginary tx has the Graftroot-reserved `nVersion`. 4. The Graftroot signature has its other flags `SIGHASH_NOINPUT` evaluated = also when verifying it signs the imaginary tx. 5. The Graftroot signature and the Graftroot script are popped and the scri= pt executed in the context of the original Graftroot-spending tx. This lets users select whether committing to a specific outpoint is needed = or not, independently of Graftroot. Regards, ZmnSCPxj