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
|
Return-Path: <david.vorick@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 69455516
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 03:23:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com
[209.85.128.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B924B196
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 03:23:24 +0000 (UTC)
Received: by mail-wr0-f174.google.com with SMTP id t20so41089786wra.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Apr 2017 20:23:24 -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=M7r8M3DICnIZdcZugHQNYzXHgJ8CgutkYT06LhDnOCk=;
b=SAVpssJGwYXcTmzQKTo59O/WU8exXQpyq9Y1vhwaRkKGnmYveviMKl33ZES5sUgo+g
+G7MzKgqky3914VDwXdeuUpE8ts1dYWiLmWNph+ptlZAQGE2qbWlT635WIWf9yk6IgtJ
Vi323G2btWMJNhbR8105IdGjQKU0DY0j/dE/goFC+dW0OagZOAFYSOQv805isXMBxFT+
YFmK3sXxS4YHaqMgW38mi0AcWELYsC9l/bbucDTCTQRXczectgJXNv27ScgiwivhcV85
Zq57TDOb1a1L0aFDxcRp9Yz8X7JYwLn/bINTDmqBZdIFBax0ss4HdQPogEkdGVVHstuG
TqjA==
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=M7r8M3DICnIZdcZugHQNYzXHgJ8CgutkYT06LhDnOCk=;
b=UFghhKkr3sDXbO7nREDIrPSDgZXdJzQUpcRmNQkCbvTdqcXp3NDVLQG8K4btX73bY9
ya9oqlKWNx1BYWXdnth/V0v9zu8+cUwTxw+WdZC10FYfU3t2g3Yiyf+MwmKmA31X2QGu
7YDZUDmh9493V14LEZ6+f9vGHJjm8ywp0K5zJMHg8qUfwQqyp7Xkn7FF9nGZvxDbLmDs
9FFKqlLCFloAwB4ct8y22apJFmAgS3Kv6mcwcJVtitiXq0ghtX6hKb54OOoquBu3q8Ks
7HHP1FXIdOHq8Qdo+Yy+vy8d95NCeFfTAiI5V+a1Di4qta3Xh9hD/WiD6eU+66CRXYkT
l2+Q==
X-Gm-Message-State: AFeK/H2Z0R0LQ2P5/UcZ2viCrB1HhVmUyDOLieRsKeRo9nbT3Az2vZYLLxw1QqFiLiichxOlekiHUCOhOMUUdA==
X-Received: by 10.223.148.102 with SMTP id 93mr25517273wrq.144.1491449003178;
Wed, 05 Apr 2017 20:23:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.55.9 with HTTP; Wed, 5 Apr 2017 20:23:22 -0700 (PDT)
In-Reply-To: <20170406024910.GA1271@savin.petertodd.org>
References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com>
<20170406023123.GA1071@savin.petertodd.org>
<CA+KqGkqSxeAUZFVFqM_QkEWcGFHgZXwGuOE==7HpXp1+D_Tj3Q@mail.gmail.com>
<20170406024910.GA1271@savin.petertodd.org>
From: David Vorick <david.vorick@gmail.com>
Date: Wed, 5 Apr 2017 23:23:22 -0400
Message-ID: <CAFVRnyrqiNY_JOqhv2ysm2WsBMYsU3tTAASAtHzMbA68_9Yx8g@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c0d257409040f054c770857
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] BIP proposal: Inhibiting a covert attack on the
Bitcoin POW function
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, 06 Apr 2017 03:23:25 -0000
--94eb2c0d257409040f054c770857
Content-Type: text/plain; charset=UTF-8
I have a practical concern related to the amount of activation energy
required to get something like this through. We are talking about
implementing something that would remove tens to hundreds of millions of
dollars of mining revenue for miners who have already gambled that this
income would be available to them.
That's not something they are going to let go of without a fight, and we've
already seen this with the segwit resistance. Further, my understanding is
that this makes a UASF a lot more difficult. Mining hardware that has
unique optimizations on one chain only can resist a UASF beyond a simple
economic majority, because they can do more hashes on the same amount of
revenue. Threshold for success is no longer 51%, especially if you are
expecting the miners to struggle (and this is a case where they have a very
good reason to struggle). Any resistance from the hashrate during the early
days of a UASF will inevitably cause large reorgs for older nodes, and is
not much better than a hardfork.
I don't know what the right answer is. But I know that we are not going to
get segwit without a fight. We are not going to invalidate covert asicboost
without a fight. And we are working with a system that actively (and is
demonstrably very effective at doing it) resists changes which are
contentious. This is definitely a contentious change, because an important
part of the community (the miners) is going to be actively resisting it.
I urge everybody to realize how difficult something like this is going to
be to pull off. We are literally talking about invalidating hardware (or at
least the optimized bits). It's only going to succeed if everybody is
conclusively on board. As you consider proposals, realize that anything
which is not the simplest and least contentious is already dead.
--94eb2c0d257409040f054c770857
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I have a practical concern related to the amount=
of activation energy required to get something like this through. We are t=
alking about implementing something that would remove tens to hundreds of m=
illions of dollars of mining revenue for miners who have already gambled th=
at this income would be available to them.<br><br></div>That's not some=
thing they are going to let go of without a fight, and we've already se=
en this with the segwit resistance. Further, my understanding is that this =
makes a UASF a lot more difficult. Mining hardware that has unique optimiza=
tions on one chain only can resist a UASF beyond a simple economic majority=
, because they can do more hashes on the same amount of revenue. Threshold =
for success is no longer 51%, especially if you are expecting the miners to=
struggle (and this is a case where they have a very good reason to struggl=
e). Any resistance from the hashrate during the early days of a UASF will i=
nevitably cause large reorgs for older nodes, and is not much better than a=
hardfork.<br><br></div><div>I don't know what the right answer is. But=
I know that we are not going to get segwit without a fight. We are not goi=
ng to invalidate covert asicboost without a fight. And we are working with =
a system that actively (and is demonstrably very effective at doing it) res=
ists changes which are contentious. This is definitely a contentious change=
, because an important part of the community (the miners) is going to be ac=
tively resisting it.<br><br></div><div>I urge everybody to realize how diff=
icult something like this is going to be to pull off. We are literally talk=
ing about invalidating hardware (or at least the optimized bits). It's =
only going to succeed if everybody is conclusively on board. As you conside=
r proposals, realize that anything which is not the simplest and least cont=
entious is already dead.<br></div></div>
--94eb2c0d257409040f054c770857--
|
