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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1ED6F12
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 May 2018 09:44:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 253B76C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 May 2018 09:44:30 +0000 (UTC)
Received: by mail-wm0-f44.google.com with SMTP id o78-v6so3381369wmg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 May 2018 02:44:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=REaGpRIELaUiq0uTR+CvpPtu6yn00fN1xY+VFiwZwOk=;
b=Drtvu5GpheGdsuwi04Rx0oPMM3hdvq8ACjzhoL0lSQYPH+9ETmRPjRf6FhnyPMtj7C
bX6Iid0louBGQZtvgbSNtyOJnCVsftPK2RAgBYvTctEgxJGyo3/T1J1zXjmlzladIk+U
uGz6jGaF9EALn0tRRnPmXBko3tkrTrZBAySzF3SBAoDPX2DoD2TuVhxZ1R9U7bsTUw96
jhUtQOjIL9yjabnrAIeSUVdRFSEdxhIv1++Md5NiTbQwNnCFFfdYmlrQJPdFT2/VW5He
VqFz5aEZ+rVbjqye/tP3DPjNuqrxt4kzk5qup2QEn8bpSi7d8LqnO02xert2hGpL5Ofe
B+ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=REaGpRIELaUiq0uTR+CvpPtu6yn00fN1xY+VFiwZwOk=;
b=ouppzgzyw380DJWq914vBYQaFqtVhJbSLTlCV3rU/pQPTwCBvoNYcLWwePPNIdmkjq
tGcSblFWSRQOS/EMoY2VEiixCGmCvltnjO8Z0CITpr8stC+T2esCANT/IK6oBJAu+81R
NT0MOOWxj1u3b9iUtn0nTbhgHYmipVvJU8oRa/oXDIcX5Ea73mBb0V67oc8R5DIXupe8
V7lH3wJJ1karx3/GwUjlSkII2KujxMH1wLkbf3ZFacpKj/y9R62DkWmaujuOzzR1oZds
gLD2YXFKh3CNDcHzSL2nE2IQPPpMAfMI8zBaqYRM1p3Gb1PODv67MlOKjzA4ttvmH2X+
bY4A==
X-Gm-Message-State: ALKqPwdN5RcxUUE8JnbvUlxA3uG8wKF8tkMdem5n/iKMIfoSBon/TTw3
9KMRZ9/WPLLuFJtxm118RnaydsUOpoOr+lXvlys=
X-Google-Smtp-Source: AB8JxZqx2kh71y6SHq29SBicRUIbJIVDCuLKJDxm4XkWVuHLoNcz8gmSn/Zso1XI8Tj11WftI1K+bAfFUlEo9iWDZhY=
X-Received: by 2002:a50:ed92:: with SMTP id
h18-v6mr11498095edr.102.1527155068798;
Thu, 24 May 2018 02:44:28 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAAS2fgRXYtTyqqQp8Ehs_q_KsT7usA+vYSmngStnndd1rWNVNw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 24 May 2018 11:44:16 +0200
Message-ID: <CAAt2M1_Kc5O062r2KOh2VWMUOv6itegvXwg87Ox+1Y2=mXMw8w@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000648c96056cf07ff2"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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: Thu, 24 May 2018 09:44:31 -0000
--000000000000648c96056cf07ff2
Content-Type: text/plain; charset="UTF-8"
Den tor 24 maj 2018 04:08Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> skrev:
>
> My understanding of the question is this:
>
> Are there any useful applications which would be impeded if a signing
> party who could authorize an arbitrary transaction spending a coin had
> the option to instead sign a delegation to a new script?
>
> The reason this question is interesting to ask is because the obvious
> answer is "no": since the signer(s) could have signed an arbitrary
> transaction instead, being able to delegate is strictly less powerful.
> Moreover, absent graftroot they could always "delegate" non-atomically
> by spending the coin with the output being the delegated script that
> they would have graftrooted instead.
>
> Sometimes obvious answers have non-obvious counter examples, e.g.
> Andrews points related to blindsigning are worth keeping in mind.
>
As stated above by Wuille this seems to not be a concern for typical P2SH
uses, but my argument here is simply that in many cases, not all
stakeholders in a transaction will hold one of the private keys required to
sign. And such stakeholders would want a guarantee that the original script
is followed as promised.
I agree that such flags typically wouldn't have a meaningful effect for
funds from non-P2SH addresses, since the entire transaction / script could
be replaced by the very same keyholders.
I'm not concerned by the ability to move funds to an address with the new
rules that you'd otherwise graftroot in, only that you can provide a
transparent guarantee that you ALSO follow the original script as promised.
What happens *after* you have followed the original script is unrelated,
IMHO.
>
--000000000000648c96056cf07ff2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
Den tor 24 maj 2018 04:08Gregory Maxwell via bitcoin-dev <<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"norefer=
rer">bitcoin-dev@lists.linuxfoundation.org</a>> skrev:</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<br>
My understanding of the question is this:<br>
<br>
Are there any useful applications which would be impeded if a signing<br>
party who could authorize an arbitrary transaction spending a coin had<br>
the option to instead sign a delegation to a new script?<br>
<br>
The reason this question is interesting to ask is because the obvious<br>
answer is "no":=C2=A0 since the signer(s) could have signed an ar=
bitrary<br>
transaction instead, being able to delegate is strictly less powerful.<br>
Moreover, absent graftroot they could always "delegate" non-atomi=
cally<br>
by spending the coin with the output being the delegated script that<br>
they would have graftrooted instead.<br>
<br>
Sometimes obvious answers have non-obvious counter examples, e.g.<br>
Andrews points related to blindsigning are worth keeping in mind.<br></bloc=
kquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">As stated =
above by Wuille this seems to not be a concern for typical P2SH uses, but m=
y argument here is simply that in many cases, not all stakeholders in a tra=
nsaction will hold one of the private keys required to sign. And such stake=
holders would want a guarantee that the original script is followed as prom=
ised.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">I agree that=
such flags typically wouldn't have a meaningful effect for funds from =
non-P2SH addresses, since the entire transaction / script could be replaced=
by the very same keyholders.=C2=A0</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">I'm not concerned by the ability to move funds to an addres=
s with the new rules that you'd otherwise graftroot in, only that you c=
an provide a transparent guarantee that you ALSO follow the original script=
as promised. What happens *after* you have followed the original script is=
unrelated, IMHO.=C2=A0</div><div dir=3D"auto"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">
</blockquote></div></div></div>
--000000000000648c96056cf07ff2--
|
