diff options
| author | Johnson Lau <jl2012@xbt.hk> | 2018-05-25 18:14:48 +0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-05-25 10:15:00 +0000 |
| commit | 9f79b78c94e1c1cc8caaa96059dec8fb90ac8a8e (patch) | |
| tree | 7a2ab1b351b84e8f3c07c25721d8c1ea6766d9ff | |
| parent | 31229b506148eb06f7e2bcd13072ba7cf994cfb9 (diff) | |
| download | pi-bitcoindev-9f79b78c94e1c1cc8caaa96059dec8fb90ac8a8e.tar.gz pi-bitcoindev-9f79b78c94e1c1cc8caaa96059dec8fb90ac8a8e.zip | |
Re: [bitcoin-dev] Should Graftroot be optional?
| -rw-r--r-- | be/00251b70b1727febaa66f6a70dcab913e1f3ad | 99 |
1 files changed, 99 insertions, 0 deletions
diff --git a/be/00251b70b1727febaa66f6a70dcab913e1f3ad b/be/00251b70b1727febaa66f6a70dcab913e1f3ad new file mode 100644 index 000000000..b743604d4 --- /dev/null +++ b/be/00251b70b1727febaa66f6a70dcab913e1f3ad @@ -0,0 +1,99 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 46FCCD80 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 25 May 2018 10:15:00 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86EC86D3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 25 May 2018 10:14:59 +0000 (UTC) +Received: from [10.8.0.101] (n218103136198.netvigator.com [218.103.136.198]) + by mx.zohomail.com with SMTPS id 1527243292402928.8070189995224; + Fri, 25 May 2018 03:14:52 -0700 (PDT) +Content-Type: text/plain; + charset=utf-8 +Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) +From: Johnson Lau <jl2012@xbt.hk> +In-Reply-To: <CAAS2fgRXYtTyqqQp8Ehs_q_KsT7usA+vYSmngStnndd1rWNVNw@mail.gmail.com> +Date: Fri, 25 May 2018 18:14:48 +0800 +Content-Transfer-Encoding: quoted-printable +Message-Id: <D996F4E8-ACC6-4A49-B841-0F3285344DF6@xbt.hk> +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> +To: Gregory Maxwell <greg@xiph.org>, + bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> +X-Mailer: Apple Mail (2.3445.5.20) +X-ZohoMailClient: External +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE + 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 <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: Fri, 25 May 2018 10:15:00 -0000 + + + +> On 24 May 2018, at 10:08 AM, Gregory Maxwell via bitcoin-dev = +<bitcoin-dev@lists.linuxfoundation.org> wrote: +>=20 +> On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev +> <bitcoin-dev@lists.linuxfoundation.org> wrote: +>> Thanks everyone who commented so far, but let me clarify the context +>> of this question first a bit more to avoid getting into the weeds too +>> much. +>=20 +> since the signer(s) could have signed an arbitrary +> transaction instead, being able to delegate is strictly less powerful. +>=20 + + +Actually, we could introduce graftroot-like delegation to all existing = +and new P2PK and P2PKH UTXOs with a softfork: + +1. Define SIGHASH_GRAFTROOT =3D 0x40. New rules apply if (nHashType & = +SIGHASH_GRAFTROOT) + +2. The third stack item MUST be at least 64 bytes, with 32-byte R and = +32-byte S, followed by a script of arbitrary size. It MUST be a valid = +signature for the script with the original public key. + +3. The remaining stack items MUST solve the script + +Conceptually this could be extended to arbitrary output types, not just = +P2PK and P2PKH. But it might be too complicated to describe here. + +(We can=E2=80=99t do this in P2WPKH and P2WSH due to the implicit = +CLEANSTACK rules. But nothing could stop us to do it by introducing = +another witness structure (which is invisible to current nodes) and = +store the extra graftroot signatures and scripts) + +A graftroot design like this is a strict subset of existing signature = +checking rules. If this is dangerous, the existing signature checking = +rules must be dangerous. This also doesn=E2=80=99t have any problem with = +blind signature, since the first signature will always sign the = +outpoint, with or without ANYONECANPAY. (As I pointed out in my reply to = +Andrew, his concern applies only to SIGHASH_NOINPUT, not graftroot) + + +=3D=3D=3D=3D=3D=3D + +With the example above, I believe there is no reason to make graftroot = +optional, at the expense of block space and/or reduced privacy. Any = +potential problem (e.g. interaction with blind signature) could be fixed = +by a proper rules design.= + + |