1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
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.=
|
