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
|
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 278D91027
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 May 2018 22:06:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 571E46C1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 May 2018 22:06:44 +0000 (UTC)
Received: by mail-wm0-f51.google.com with SMTP id j4-v6so12923179wme.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 May 2018 15:06:44 -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;
bh=JU5pgHjY5ojMvEpGb4kP0BVKwdNz6dZJ+fFtp9KUh34=;
b=ZMtUmtGjXhBUYripBw9+B3YN5XTukD0MHIkTx2pKOQYeAqYg1ByZr8XFK4eUY6sl4k
UhWKHytZgC9iI3EiYdTG9zl2YFjan+rLKWViUGrvOrmJnIZ2b+1T0ZMF3CjxAYROdUUQ
QuXN3daH2VQFsc2Dd4qA7jXMpqMopFfD53GVys7SCaRilXRM6orJt5I26jk1PdaIoKCC
1/vuSZ2irRiBUgHakuRAHlIdNR0t03gzwEs0CJDaL6Tn8+zhT5qm8/H8zxacOSeAWFaY
spCIUD1pKyrrvZbUFkxD2WTCE0qCQcbxbzcikTGRo03sGWG45OxPYVoEA+VPST6xZACB
1nWQ==
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;
bh=JU5pgHjY5ojMvEpGb4kP0BVKwdNz6dZJ+fFtp9KUh34=;
b=kY+N44Te/oPoL+lPHrThmsH9kZCyD62ND35ZSfbXled91fYyMoX6Iigb4zuPKp+OGj
quS8XKk08sfJ5o8kaP7mQhlqMw/7E2A6BYAsaFAhrB0xmEoW1i+RlhUFeKRY5sdUp3Df
LDRenHMBnMynC3ZKi4nOnhxH9iJB5GxiZX22a43wdQzio4pvcRpyY6qshEjZRvW0Fvku
6lrnrYRVHuC6QE32WtNOqHEpr19CLQQkAQRwfXFCqHvU+zNiVcKKID3RQk2HZdnYDnR8
mVLn03x7bzRJ/vzCcVubc2uv8uLl+/vcxjBz+CX6UxWDOZOezEUpLODSkW96D2DBXFax
lIJg==
X-Gm-Message-State: ALKqPweWuJVbGc0WnKMckcRRYZFb18hAlvhbx6I0LU3exwSqzQvK8VUV
S3UlvwtnQCJLHtxxMlHXNbJZsrWdH4PzJ9uuKUw=
X-Google-Smtp-Source: AB8JxZpltzFKIyUpgc1xuCGr5Xh7zG6WoHZ+u7ex6zn1suxZpMXB2YUcWBcwNlycnvHMkhHKuNjQMqRnntFNlZa/wWY=
X-Received: by 2002:a50:ed92:: with SMTP id
h18-v6mr9223305edr.102.1527113202821;
Wed, 23 May 2018 15:06:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
In-Reply-To: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 24 May 2018 00:06:31 +0200
Message-ID: <CAAt2M1-DTzKct-NU9TotxDve8vLe5HFYxHZbq+t_A69C1nL-PA@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000fc6efd056ce6bfe4"
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: Wed, 23 May 2018 22:06:45 -0000
--000000000000fc6efd056ce6bfe4
Content-Type: text/plain; charset="UTF-8"
Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> skrev:
> Hello all,
>
> Given the recent discussions about Taproot [1] and Graftroot [2], I
> was wondering if a practical deployment needs a way to explicitly
> enable or disable the Graftroot spending path. I have no strong
> reasons why this would be necessary, but I'd like to hear other
> people's thoughts.
>
I'm definitely in favor of the suggestion of requiring a flag to allow the
usage of these in a transaction, so that you get to choose in advance if
the script will be static or "editable".
Consider for example a P2SH address for some fund, where you create a
transaction in advance. Even if the parties involved in signing the
transaction would agree (collude), the original intent of this particular
P2SH address may be to hold the fund accountable by enforcing some given
rules by script. To be able to circumvent the rules could break the purpose
of the fund.
The name of the scheme escapes me, but this could include a variety of
proof-requiring committed transactions, like say a transaction that will
pay out if you can provide a proof satisfying some conditions such as
embedding the solution to a given problem. This fund would only be supposed
to pay out of the published conditions are met (which may include an expiry
date).
To then use taproot / graftroot to withdraw the funds despite this
possibility not showing in the published script could be problematic.
I'm simultaneously in favor of being able to have scripts where the usage
of taproot / graftroot isn't visible in advance, but it must simultaneously
be possible to prove a transaction ISN'T using it.
>
--000000000000fc6efd056ce6bfe4
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 tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev <<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.=
org</a>> skrev:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
Given the recent discussions about Taproot [1] and Graftroot [2], I<br>
was wondering if a practical deployment needs a way to explicitly<br>
enable or disable the Graftroot spending path. I have no strong<br>
reasons why this would be necessary, but I'd like to hear other<br>
people's thoughts.<br></blockquote></div></div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><span style=3D"font-family:sans-serif">I'm defini=
tely in favor of the suggestion of requiring a flag to allow the usage of t=
hese in a transaction, so that you get to choose in advance if the script w=
ill be static or "editable".=C2=A0</span><br></div><div dir=3D"au=
to"><span style=3D"font-family:sans-serif"><br></span></div><div dir=3D"aut=
o"><font face=3D"sans-serif">Consider for example a P2SH address for some f=
und, where you create a transaction in advance. Even if the parties involve=
d in signing the transaction would agree (collude), the original intent of =
this particular P2SH address may be to hold the fund accountable by enforci=
ng some given rules by script. To be able to circumvent the rules could bre=
ak the purpose of the fund.=C2=A0</font></div><div dir=3D"auto"><font face=
=3D"sans-serif"><br></font></div><div dir=3D"auto"><font face=3D"sans-serif=
">The name of the scheme escapes me, but this could include a variety of pr=
oof-requiring committed transactions, like say a transaction that will pay =
out if you can provide a proof satisfying some conditions such as embedding=
the solution to a given problem. This fund would only be supposed to pay o=
ut of the published conditions are met (which may include an expiry date).=
=C2=A0</font></div><div dir=3D"auto"><font face=3D"sans-serif"><br></font><=
/div><div dir=3D"auto"><font face=3D"sans-serif">To then use taproot / graf=
troot to withdraw the funds despite this possibility not showing in the pub=
lished script could be problematic.=C2=A0</font></div><div dir=3D"auto"><fo=
nt face=3D"sans-serif"><br></font></div><div dir=3D"auto"><font face=3D"san=
s-serif">I'm simultaneously in favor of being able to have scripts wher=
e the usage of taproot / graftroot isn't visible in advance, but it mus=
t simultaneously be possible to prove a transaction ISN'T using it.=C2=
=A0</font></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
</blockquote></div></div></div>
--000000000000fc6efd056ce6bfe4--
|
