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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 092711033
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jan 2018 10:48:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
[209.85.223.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E8ABF12E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jan 2018 10:48:54 +0000 (UTC)
Received: by mail-io0-f174.google.com with SMTP id f34so126874ioi.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Jan 2018 02:48:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=Y89oJ3zzMmQa1xgHwXc7b7dg+gI21TKOdAy4Gk9ieM0=;
b=f6pk+GUmeZ+z23Us+nD5uYjlOb1Jr/kgi36EXNqPVTuy+04wjYIPPSDk3MjyJ9fqSN
v8CcHUFzryW4ai6fhW+4nu03Ay9jcJcnbhdbPIft4Ss3rgAMiH92H2LXfLUrCM9yhWGc
PPq7Mm3goST3UEV6dOtIAP2g+nANkJFcmt0AY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=Y89oJ3zzMmQa1xgHwXc7b7dg+gI21TKOdAy4Gk9ieM0=;
b=eZrzv1S7h53B/1U7wLPcOeMFc+BurfYuhuzRC3XiD/k3Sk01fONg0uVn55X/0+Dvx4
LSDkH69/+MBNPx3Bt7c3Si6IOv/+61lPSkUE9PsCRRRxr8hMoeY1Aplt+ZEhQ+tQECZi
4jqHs2yenp/tfFiLumxo7bwg7onCRigtWuyVyEGu6rztEeIcKJDn+FsqT0B8znxgcpKl
BkACLsqZWnA4NfaJ4rDn6v+No5+qqC9k4OcKRTxCOEzezEykOzmVvY2/duvHF7plMvKK
nAX/gHQv7y0Vfoo2ou5B/NKjt4pUZ3FlYdc4sApumEbfzA3dcEBPyhk7ZyavvA9E6m2Y
MrLA==
X-Gm-Message-State: AKGB3mJ/vz0TezpPNtSnbpvCOlLINxMTb2G09n/poN0a7q+TpJ6sUm2Y
vEoXbg7OkpH8V1UnIW9i9Euy6BVLRkIfbq55lrfgew==
X-Google-Smtp-Source: ACJfBosJd7PUGzF8Eiic83dhYEiOmTnP0baTxbP6Ko8SNiY1AQ0a4v2FEpries+PbKdubywq4dvPGlFsGatptRrfi7Y=
X-Received: by 10.107.172.69 with SMTP id v66mr24003670ioe.198.1515754134131;
Fri, 12 Jan 2018 02:48:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.160.194 with HTTP; Fri, 12 Jan 2018 02:48:33 -0800 (PST)
In-Reply-To: <CAPg+sBgRrqZryiETZYCWiqHNOmN2bCfsvr30znjN-gKiU5Vfjg@mail.gmail.com>
References: <87608btgyd.fsf@rustcorp.com.au>
<DB7E57AC-5588-4BBA-9ABC-B9B4F6BAECE2@friedenbach.org>
<CAPg+sBgRrqZryiETZYCWiqHNOmN2bCfsvr30znjN-gKiU5Vfjg@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Fri, 12 Jan 2018 05:48:33 -0500
Message-ID: <CAMZUoKn4noCEQR6eqf9hiZSMdk-3b8UHR1NrEFrKNoLSMzVjGQ@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c05921abb6d9e05629202ba"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Russell O'Connor <roconnor@blockstream.com>,
Kalle Alm <kalle.alm@gmail.com>
Subject: Re: [bitcoin-dev] BIP 117 Feedback
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, 12 Jan 2018 10:48:56 -0000
--94eb2c05921abb6d9e05629202ba
Content-Type: text/plain; charset="UTF-8"
Putting aside for the moment the concerns that Pieter and Rusty have raised
about BIP 117 (concerns which I agree with), is BIP 117 even a viable soft
fork to begin with?
When it comes to soft forks of Script, in the past there have been two
kinds.
The first kind is soft-forking new script semantics into NOPn codes. In
this case, everyone ought to know that these op codes are reserved for
future extensions and no one should be writing script that depends on NOPn
having NOP behavior (For users who want real nop behaviour, there does
exist a real NOP opcode).
The second kind of soft-forking new script semantics is the
reinterpretation of various wholesale scripts (historically via
templates). Examples of this are Segwit and P2SH. In the case of Segwit,
the scripts gaining new semantics were applied to a form of completely
unsecured "anyone-can-spend" programs. Anyone who created such output
prior to the activation of Segwit would know that anyone could claim
ownership of those outputs, and therefore the possibility of losing the
ability to spend legacy forms of these segwit-style outputs is arguably not
harmful as no one in particular had ownership of such funds. The story for
P2SH is somewhat similar: Prior to the activation of P2SH the creator of of
P2SH style outputs would know that anyone could claim ownership of that
style of output as soon as the hash preimage is published (in the mempool,
for example).
However, if I understand correctly, the situation for BIP 117 is entirely
different. As far as I understand there is currently no restrictions about
terminating a v0 witness program with a non-empty alt-stack, and there are
no restrictions on leaving non-canonical boolean values on the main stack.
There could already be commitments to V0 witness programs that, when
executed in some reasonable context, leave a non-empty alt-stack and/or
leave a non-canonical true value on the main stack. Unlike the P2SH or
Segwit soft-forks, these existing commitments could be real outputs that
currently confer non-trivial ownership over their associated funds. If BIP
117 were activated, these commitments would be subject to a new set of
rules that didn't exist when the commitments were made. In particular,
these funds could be rendered unspendable. Because segwit commitments are
hashes of segwit programs, there is no way to even analyze the blockchain
to determine if these commitments currently exist (and even if we could it
probably woudln't be adequate protection).
Naturally we shouldn't be making new rules that could, in principle,
retroactively remove ownership of existing user's funds.
>
--94eb2c05921abb6d9e05629202ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Putting aside for the moment the concerns t=
hat Pieter and Rusty have raised about BIP 117 (concerns which I agree with=
), is BIP 117 even a viable soft fork to begin with?<br><br></div>When it c=
omes to soft forks of Script, in the past there have been two kinds.<br><br=
></div>The first kind is soft-forking new script semantics into NOPn codes.=
=C2=A0 In this case, everyone ought to know that these op codes are reserve=
d for future extensions and no one should be writing script that depends on=
NOPn having NOP behavior (For users who want real nop behaviour, there doe=
s exist a real NOP opcode).<br><br></div>The second kind of soft-forking ne=
w script semantics is the reinterpretation of various wholesale scripts (hi=
storically via templates).=C2=A0 Examples of this are Segwit and P2SH.=C2=
=A0 In the case of Segwit, the scripts gaining new semantics were applied t=
o a form of completely unsecured "anyone-can-spend" programs.=C2=
=A0 Anyone who created such output prior to the activation of Segwit would =
know that anyone could claim ownership of those outputs, and therefore the =
possibility of losing the ability to spend legacy forms of these segwit-sty=
le outputs is arguably not harmful as no one in particular had ownership of=
such funds.=C2=A0 The story for P2SH is somewhat similar: Prior to the act=
ivation of P2SH the creator of of P2SH style outputs would know that anyone=
could claim ownership of that style of output as soon as the hash preimage=
is published (in the mempool, for example).<br><div><div><div><div><div><d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">However,=
if I understand correctly, the situation for BIP 117 is entirely different=
.=C2=A0 As far as I understand there is currently no restrictions about ter=
minating a v0 witness program with a non-empty alt-stack, and there are no =
restrictions on leaving non-canonical boolean values on the main stack.=C2=
=A0 There could already be commitments to V0 witness programs that, when ex=
ecuted in some reasonable context, leave a non-empty alt-stack and/or leave=
a non-canonical true value on the main stack.=C2=A0 Unlike the P2SH or Seg=
wit soft-forks, these existing commitments could be real outputs that curre=
ntly confer non-trivial ownership over their associated funds.=C2=A0 If BIP=
117 were activated, these commitments would be subject to a new set of rul=
es that didn't exist when the commitments were made.=C2=A0 In particula=
r, these funds could be rendered unspendable.=C2=A0 Because segwit commitme=
nts are hashes of segwit programs, there is no way to even analyze the bloc=
kchain to determine if these commitments currently exist (and even if we co=
uld it probably woudln't be adequate protection).<br></div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Naturally we shouldn&=
#39;t be making new rules that could, in principle, retroactively remove ow=
nership of existing user's funds.<br></div><span class=3D"HOEnZb"><font=
color=3D"#888888"><div dir=3D"auto">=C2=A0<br></div></font></span><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
</blockquote></div><br></div></div></div></div></div></div></div></div>
--94eb2c05921abb6d9e05629202ba--
|
