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
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
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 A939DE45
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Mar 2019 17:49:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f177.google.com (mail-it1-f177.google.com
[209.85.166.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EF4F92D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Mar 2019 17:49:45 +0000 (UTC)
Received: by mail-it1-f177.google.com with SMTP id g17so42706ita.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Mar 2019 10:49:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=w7RpGuiwzWWy68zgEZ83JcEek8IskkonXVme5SsK890=;
b=ZVAcZNyHyLVPl4nSXa+gzqqS7UQjoWiA9BWjgp1D3rJb8LF7jPyv45XNdFxuhrbwcY
WQ8DnhkVrzJyexDr0kXbCPd4WwGPE4uTKTd867UHCTI3T84su8IdV4IiNZLfM+A9y4C/
eZ6KX+TcruHTQxP4HqJ/rRjRjUChznY5zbcZw=
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=w7RpGuiwzWWy68zgEZ83JcEek8IskkonXVme5SsK890=;
b=Ox6jqdHcoEytBFch/luW2qTCVbZy4hl3YyDIuOZisMIBUVvyIiI9pvphWyjEEDrw2x
69bDow6GncDvpHAR6rpgzHzKnSGadWPrHsMGYKhvV6KJxxtEAJplfMCa6i64uE1JFAm/
tSyNYCT4OrFujSi/8S6ucGDEMgKUDoDUxyyWQCx6jB/+WmLS78/aFTCXxBk4gkOuXg2k
YAeCNf76CoHJCRNP83gd0S4UXJiVYU/1E3fGulxbtip5zCOW33lQ0QcF34pG5j0ksL1u
8OABbSwkbud6dymklHBJ7fyAg8ejxRgJQ5qyp7A7gDmTtcGxdOIG/S8vzVGhJfzw8xFw
+rEQ==
X-Gm-Message-State: APjAAAXBcsKKH084TwtW93ScSS0QbQ/gwQJBb6SVk8Gw0QLGsJA202d9
gD25WO1KnEr2fLvC5NtVmaUW4apxx32z0yjew8Mfgw==
X-Google-Smtp-Source: APXvYqyw59+4o1oJE47siUm8oWbVskyCC+L+wQyV0P269uf7KQXa2m1fq3AEfvZFIdkDOxBt8fOJU06jdp7+IaabJk0=
X-Received: by 2002:a24:e506:: with SMTP id g6mr140655iti.127.1552326585146;
Mon, 11 Mar 2019 10:49:45 -0700 (PDT)
MIME-Version: 1.0
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
<CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
<6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
<CAMZUoKk3CgatSexAHRuxn3ibCYwgHpTkc0gF0yDi6hLAVcCiNA@mail.gmail.com>
<db3405ef-7e06-9538-0700-df37abaa602d@mattcorallo.com>
<CAMZUoKnK2YhucaJ-1HxH3MXeBtQZebV+h_rcS5Oq=yCMDC5u7A@mail.gmail.com>
<CAAUaCyh09NkgVi2fCNGaNikmaNJ1Yi7AYtBnK9f+Qg8sFoA+_Q@mail.gmail.com>
In-Reply-To: <CAAUaCyh09NkgVi2fCNGaNikmaNJ1Yi7AYtBnK9f+Qg8sFoA+_Q@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 11 Mar 2019 13:49:33 -0400
Message-ID: <CAMZUoKmU3-b5nTBFuO2dCuZZ+xVT6uZmoXgyjbpVkZQLVTrFrA@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000aef66d0583d5325a"
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
X-Mailman-Approved-At: Mon, 11 Mar 2019 21:15:24 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
Consensus Cleanup
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: Mon, 11 Mar 2019 17:49:46 -0000
--000000000000aef66d0583d5325a
Content-Type: text/plain; charset="UTF-8"
Hi Jacob,
> Huh?! The whole point of non-standardness in this context is to (a) make
>>> soft-forking something out safer by derisking miners not upgrading right
>>> away and (b) signal something that may be a candidate for soft-forking
>>> out so that we get feedback. Who is getting things disabled who isn't
>>> bothering to *tell* people that their use-case is being hurt?!
>>>
>>
>> People have told me that they are hurt by some other non-standardness
>> changes and I understand that they have been sitting on those funds for
>> years. Maybe they don't realize their is some place to complain or maybe
>> they think there must be a good reason why they are not allowed to do what
>> they were previously allowed to do. Perhaps others don't want to risk
>> blowing their pseudonymity. Perhaps they think that attempting to undo
>> some of these non-standardness changes is futile. I can bring up the
>> specific cases I've encountered in a new thread if you think it is
>> worthwhile.
>>
>
> Like Matt, I understand non-standardness to be specifically for making a
> transaction type more difficult to set the stage for a future disabling.
>
> If anyone is actually harmed by this change, let them at least speak up
> pseudonymously as others have before. Backwards compatibility shouldn't
> mean letting imaginary implausible cases veto net-beneficial changes.
>
It is so easy to say stuff like this when one's own money isn't what is at
risk.
While I encourage users who would be harmed to chime in if they can,
unfortunately, I think it is mostly wishful thinking on our part that they
necessarily would. In fact, there is evidence that in practice people
don't.
To illustrate this, consider the example of the people affected by PR #5247
<https://github.com/bitcoin/bitcoin/pull/5247>, which makes unparsable
public keys non-standard. As far as I am aware none have commented on this
mailing list about it yet even though I happen to know such people do exist
because I've talked with them on Slack. I believe the person I spoke with
to took over a year (and probably more than two years) to even notice that
the transactions they want to redeem with are no longer standard. To be
fair, their money that is stuck due to PR #5247 isn't lost yet, but I'm
skeptical they would think or know to speak up here even if their money was
on the chopping block. The fact that they haven't been able to move their
money in the last *4 years* doesn't mean they wouldn't like it back one day.
While non-standardness is a helpful in dissuading users from committing new
funds to OP_CODESEPARATOR scripts, it doesn't do anything to help users
that may have been caught unaware by the non-standardness change.
Furthermore, because these transactions are non-standard, anyone caught off
guard by the change is going to have a very hard time redeeming their
funds, as we have already seen with PR #5247, a non-standardness change
that is far older than the OP_CODESERPATOR change in PR #11423
<https://github.com/bitcoin/bitcoin/pull/11423>.
--000000000000aef66d0583d5325a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Hi=
Jacob,<br></div><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div =
dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"auto"><div di=
r=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">Huh?! The whole point of non-standardness in this context is to=
(a) make=C2=A0<br>soft-forking something out safer by derisking miners not=
upgrading right=C2=A0<br>away and (b) signal something that may be a candi=
date for soft-forking=C2=A0<br>out so that we get feedback. Who is getting =
things disabled who isn't=C2=A0<br>bothering to *tell* people that thei=
r use-case is being hurt?!<br></blockquote><div><br></div><div>People have =
told me that they are hurt by some other non-standardness changes and I und=
erstand that they have been sitting on those funds for years.=C2=A0 Maybe t=
hey don't realize their is some place to complain or maybe they think t=
here must be a good reason why they are not allowed to do what they were pr=
eviously allowed to do.=C2=A0 Perhaps others don't want to risk blowing=
their pseudonymity.=C2=A0 Perhaps they think that attempting to undo some =
of these non-standardness changes is futile.=C2=A0 I can bring up the speci=
fic cases I've encountered in a new thread if you think it is worthwhil=
e.</div></div></div></div></div></blockquote><div><br></div><div>Like Matt,=
I understand non-standardness to be specifically for making a transaction =
type more difficult to set the stage for a future disabling.</div><div><br>=
</div><div>If anyone is actually harmed by this change, let them at least s=
peak up pseudonymously as others have before.=C2=A0 Backwards compatibility=
shouldn't mean letting imaginary implausible cases veto net-beneficial=
changes.</div></div></div></div></div></div></blockquote><div><br></div><d=
iv>It is so easy to say stuff like this when one's own money isn't =
what is at risk.</div></div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">While I encourage users who would be harmed to chime in if=
they can, unfortunately, I think it is mostly wishful thinking on our part=
that they necessarily would.=C2=A0 In fact, there is evidence that in prac=
tice people don't.<br></div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote">To illustrate this, consider the example of the people=
affected by <a href=3D"https://github.com/bitcoin/bitcoin/pull/5247" targe=
t=3D"_blank">PR #5247</a>, which makes unparsable public keys non-standard.=
=C2=A0 As far as I am aware none have commented on this mailing list about =
it yet even though I happen to know such people do exist because I've t=
alked with them on Slack.=C2=A0 I believe the person I spoke with to took o=
ver a year (and probably more than two years) to even notice that the trans=
actions they want to redeem with are no longer standard.=C2=A0 To be fair, =
their money that is stuck due to PR #5247 isn't lost yet, but I'm s=
keptical they would think or know to speak up here even if their money was =
on the chopping block.=C2=A0 The fact that they haven't been able to mo=
ve their money in the last *4 years* doesn't mean they wouldn't lik=
e it back one day.<br></div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">While non-standardness is a helpful in dissuading users fr=
om committing new funds to OP_CODESEPARATOR scripts, it doesn't do anyt=
hing to help users that may have been caught unaware by the non-standardnes=
s change.=C2=A0 Furthermore, because these transactions are non-standard, a=
nyone caught off guard by the change is going to have a very hard time rede=
eming their funds, as we have already seen with PR #5247, a non-standardnes=
s change that is far older than the OP_CODESERPATOR change in <a href=3D"ht=
tps://github.com/bitcoin/bitcoin/pull/11423">PR #11423</a>.<br></div></div>=
</div></div></div>
--000000000000aef66d0583d5325a--
|
