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
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
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 A0F3D71F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 13:23:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb0-f172.google.com (mail-yb0-f172.google.com
[209.85.213.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E95248D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 13:23:37 +0000 (UTC)
Received: by mail-yb0-f172.google.com with SMTP id m133so23192917ybb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 06:23:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=7d8ucwSwjergwjE0B+H7xDw4TdXe+8Q/RK+Lsi7yl3w=;
b=SGCTdtIgvYCpidWpkIgOL1l3UqlfQXLKq8/A4EGdcYuuqm34Un/KtpvHasXOS53DUS
7tkNO3VwjQvLQ5kJ28s96RymVmIwStJ25bT5uB2xZSDbz/uk4YZflmnQhivfGa/CARUu
Da+eJdzY5Ji2OoDkxqYb41p7KyVyPUy90oBZ9xIQeQGe51rtEI229LYfQF41JpsuTYYM
FAVhGxmMOgsrXSPGYaDyApaHg4g0YAW9RBThU5I16R73dHPWXDFpoqGelxc5+aVdC4ZQ
GFlSV7VthrVSSyRIXy90I404rz9dTPck13iQqRHQAGaNC/4GJwZFlt71iWxWGbrhGcuT
1bAg==
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=7d8ucwSwjergwjE0B+H7xDw4TdXe+8Q/RK+Lsi7yl3w=;
b=d4magQc2vrSf6sFfa7E03QyPLYBKpeLmmlw0rWiTM1T4qmz0nr0rIk2TzqmnC4A3iR
WtPdgBkA28eSeDuhgRv8YJcoFwbQp9SFQOo+TRrtWmGwTjbV5CKn7d6BJ98tRRlpTwX2
zu+wyfDvb2WbW94FEIeJQlDmhv7LZ5PPOCxJVSXLxM/B/b6l5lgSGRPjv38Ul3LafkJN
qExsfAOJQYN0/pnftbT5+A+ukuCDtXrlcRpDqSzMeUwHwH3MY/8JmkH26Ft0mlclCPcu
Uk9feWkyGT+d87xiYj21E0skoX2/y//pp8BlwbJMkT5YjI5sHdasdcRS3zipW7cxbgmH
A0ow==
X-Gm-Message-State: AN3rC/7ViAoUGbdihr8PdqPGgwp6llmFNX8FTe66UgxRPFHXoeMSdCRw
d7jj254lV6WuYTYI754MULS9oTo96Q==
X-Received: by 10.37.171.162 with SMTP id v31mr9729558ybi.88.1492262617057;
Sat, 15 Apr 2017 06:23:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.123.135 with HTTP; Sat, 15 Apr 2017 06:23:35 -0700 (PDT)
Received: by 10.37.123.135 with HTTP; Sat, 15 Apr 2017 06:23:35 -0700 (PDT)
In-Reply-To: <2941cf86-422f-6a88-fb44-9ac01c5e996a@chrisacheson.net>
References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
<E7A3E345-15C9-4C4C-B3D7-C75634243430@gmail.com>
<CAAS2fgSXOkTcJ5tTssuGMCQwh-JFQTkzU5VBjaR+hKT+bD3Q6A@mail.gmail.com>
<2941cf86-422f-6a88-fb44-9ac01c5e996a@chrisacheson.net>
From: Natanael <natanael.l@gmail.com>
Date: Sat, 15 Apr 2017 15:23:35 +0200
Message-ID: <CAAt2M19-R83VS2PB6ppjqSH4cSXT--5M=QxUFLpYDr8iMnpGpQ@mail.gmail.com>
To: Chris Acheson <mail@chrisacheson.net>
Content-Type: multipart/alternative; boundary=94eb2c18881a339378054d34770b
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no 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>
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
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: Sat, 15 Apr 2017 13:23:38 -0000
--94eb2c18881a339378054d34770b
Content-Type: text/plain; charset=UTF-8
Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Not sure if you missed my previous reply to you, but I'm curious about
your thoughts on this particular point. I contend that for any UASF,
orphaning non-signalling blocks on the flag date is [maybe] safer [for
those in on the UASF fork] than just
considering the fork active on the flag date.
Note my additions.
Enforcement by orphaning non-compliance makes it harder to reverse a buggy
softfork, since you necessarily increase the effort needed to return enough
mining power to the safe chain since you now have mostly unmonitored mining
hardware fighting you actively, whose operators you might not be able to
contact. You'd practically have to hardfork out of the situation.
There's also the risk of the activation itself triggering concensus bugs
(multiple incompatible UASF forks), if there's multiple implementations of
it in the network (or one buggy one). We have already seen something like
it happen. This can both happen on the miner side, client side or both
(miner side only would lead to a ton of orphaned blocks, client side means
netsplit).
It is also not economically favorable for any individual miner to be the
one to mine empty blocks on top of any surviving softfork-incompatible
chain. As a miner you would only volunteer to do it if you believe the
softfork is necessary or itself will enable greater future profit.
Besides that, I also just don't believe that UASF itself as a method to
activate softforks is a good choice. The only two reliable signals we have
for this purpose in Bitcoin are block height (flag day) and standard miner
signaling, as every other metric can be falsified or gamed.
But there's also more problems - a big one is that we have no way right now
for a node to tell another "the transaction you just relayed to me is
invalid according to an active softfork" (or "will become invalid". This
matters for several reasons.
The first one that came to my mind is that we have widespread usage of
zero-confirmation payments in the network.
This was already dangerous for other reasons, but this UASF could make it
guaranteed cost-free to exploit - because as many also know, we ALSO
already have a lot of nodes that do not enforce the non-default rejection
policies (otherwise we'd never see such transactions on blocks), including
many alternative Bitcoin clients.
The combination of these factors means that you can present an UASF invalid
transaction to a non-updated client that is supposedly protected by the
deliberate orphaning effort, and have it accept this as a payment. To never
see it get confirmed, or to eventually see it doublespent by an UASF-valid
transaction.
I would not at all be surprised if it turned out that many
zero-confirmation accepting services do not reject non-default
transactions, or if they aren't all UASF-segwit aware.
This is why a flag day or similar is more effective - it can't be ignored
unlike "just another one of those UASF proposals" that you might not have
evaluated or not expect to activate.
This is by the way also a reason that I believe that all nodes and services
should publish all concensus critical policies that they enforce. This
would make it far easier to alert somebody that they NEED TO prepare for
whatever proposal that might conflict with their active policies.
--94eb2c18881a339378054d34770b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div data-smartmail=3D"gmail_signature" dir=3D"auto"><br>=
</div><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_quote=
">Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a>>:<blockquote class=3D"quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted=
-text">
<br>
</div>Not sure if you missed my previous reply to you, but I'm curious =
about<br>
your thoughts on this particular point. I contend that for any UASF,<br>
orphaning non-signalling blocks on the flag date is [maybe] safer [for thos=
e in on the UASF fork] than just<br>
considering the fork active on the flag date.<br></blockquote></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Note my additions.=C2=A0</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">Enforcement by orphaning non-=
compliance makes it harder to reverse a buggy softfork, since you necessari=
ly increase the effort needed to return enough mining power to the safe cha=
in since you now have mostly unmonitored mining hardware fighting you activ=
ely, whose operators you might not be able to contact. You'd practicall=
y have to hardfork out of the situation.=C2=A0</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">There's also the risk of the activation itself t=
riggering concensus bugs (multiple incompatible UASF forks), if there's=
multiple implementations of it in the network (or one buggy one). We have =
already seen something like it happen. This can both happen on the miner si=
de, client side or both (miner side only would lead to a ton of orphaned bl=
ocks, client side means netsplit).=C2=A0</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">It is also not economically favorable for any individual m=
iner to be the one to mine empty blocks on top of any surviving softfork-in=
compatible chain. As a miner you would only volunteer to do it if you belie=
ve the softfork is necessary or itself will enable greater future profit.=
=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Besides that, I a=
lso just don't believe that UASF itself as a method to activate softfor=
ks is a good choice. The only two reliable signals we have for this purpose=
in Bitcoin are block height (flag day) and standard miner signaling, as ev=
ery other metric can be falsified or gamed.=C2=A0</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">But there's also more problems - a big one is=
that we have no way right now for a node to tell another "the transac=
tion you just relayed to me is invalid according to an active softfork"=
; (or "will become invalid". This matters for several reasons.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">The first one that c=
ame to my mind is that we have widespread usage of zero-confirmation paymen=
ts in the network.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>This was already dangerous for other reasons, but this UASF could make it =
guaranteed cost-free to exploit - because as many also know, we ALSO alread=
y have a lot of nodes that do not enforce the non-default rejection policie=
s (otherwise we'd never see such transactions on blocks), including man=
y alternative Bitcoin clients.=C2=A0</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">The combination of these factors means that you can present an=
UASF invalid transaction to a non-updated client that is supposedly protec=
ted by the deliberate orphaning effort, and have it accept this as a paymen=
t. To never see it get confirmed, or to eventually see it doublespent by an=
UASF-valid transaction.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">I would not at all be surprised if it turned out that many zero-conf=
irmation accepting services do not reject non-default transactions, or if t=
hey aren't all UASF-segwit aware.=C2=A0</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">This is why a flag day or similar is more effective - i=
t can't be ignored unlike "just another one of those UASF proposal=
s" that you might not have evaluated or not expect to activate.=C2=A0<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">This is by the way also =
a reason that I believe that all nodes and services should publish all conc=
ensus critical policies that they enforce. This would make it far easier to=
alert somebody that they NEED TO prepare for whatever proposal that might =
conflict with their active policies.=C2=A0</div></div>
--94eb2c18881a339378054d34770b--
|
