diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2018-06-21 03:09:14 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-06-21 07:09:25 +0000 |
| commit | 3a5e3d063d223f21801b5ba3853128d07df50b6b (patch) | |
| tree | 2e976cd3fd0404f0de606a564453b8f807e0f62d | |
| parent | c02ecbc2b6889295e3f118d19382f0c6397a1f85 (diff) | |
| download | pi-bitcoindev-3a5e3d063d223f21801b5ba3853128d07df50b6b.tar.gz pi-bitcoindev-3a5e3d063d223f21801b5ba3853128d07df50b6b.zip | |
Re: [bitcoin-dev] Should Graftroot be optional?
| -rw-r--r-- | 3c/f6eab61a07de9e193a1d5a4a3318fc330a8046 | 121 |
1 files changed, 121 insertions, 0 deletions
diff --git a/3c/f6eab61a07de9e193a1d5a4a3318fc330a8046 b/3c/f6eab61a07de9e193a1d5a4a3318fc330a8046 new file mode 100644 index 000000000..bd6eba2fe --- /dev/null +++ b/3c/f6eab61a07de9e193a1d5a4a3318fc330a8046 @@ -0,0 +1,121 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 02C46D2F + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <greg@xiph.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <rDrVW1mai6zBTyuv-8ElgFBYr213ewiG-5DdBnZIi_QC1hosefWYWq6-oqmK72bP7NxOAXiQvwDiQS_JEgaPPcmXywBU4nhqVhrt7HtlsMo=@protonmail.com> +In-Reply-To: <CAAS2fgQihGNvOsRVyr6xN_K0PPse1URKKWH06N7HpcR=OowYYw@mail.gmail.com> +References: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com> + <CAPg+sBh4CESPV_5TpPn0H3Zpv2Ump_0txxS63W_S2f3Lxezq1A@mail.gmail.com> + <CAAS2fgRXYtTyqqQp8Ehs_q_KsT7usA+vYSmngStnndd1rWNVNw@mail.gmail.com> + <D996F4E8-ACC6-4A49-B841-0F3285344DF6@xbt.hk> + <CAPg+sBgEUV5KNFi1L4MhR-3KAX9gbQKdzWneaEzF+QsKSXYu8A@mail.gmail.com> + <f5c0012e55242d85ec2cc740cc8d081ef5da9145.camel@timruffing.de> + <CAPg+sBhYkQdjDcKvxUiGZCs220N0dqRMYoweCbOB2dgzD9UpzA@mail.gmail.com> + <01976660b06809ea27af7db4bbceb08220ea2568.camel@timruffing.de> + <7nh2F_OPfoHDxrXVG8Dlu51iJ4nnlLFo962B7gI1cN3nyLupsjjlZF9-2nO525E5ENlhMSXprJWkHty8AAxe7W7FRZZpv00C0BptZZcvzK8=@protonmail.com> + <CAAS2fgQihGNvOsRVyr6xN_K0PPse1URKKWH06N7HpcR=OowYYw@mail.gmail.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 <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + + |