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
|
Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EBC1A89C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 17:26:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f176.google.com (mail-ua0-f176.google.com
[209.85.217.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 82400164
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Apr 2017 17:26:54 +0000 (UTC)
Received: by mail-ua0-f176.google.com with SMTP id v24so50311uav.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Apr 2017 10:26:54 -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:content-transfer-encoding;
bh=CTSMLDu9tmTorcdSVnyFBMYcHYkpMx0Enos+gBCo0J8=;
b=ag91tyuboG0QlJuuUhlt/XEaRBjY7QvgAKt9A0/UOnSZ+njEPYS3KOXZ4i83KwWcFJ
LFVYkmeeys5r386mgbx86dg7VSRMuJ/sD0fA+YR4giyvshLDCQLgOlr1yAwy1jXleYdQ
6er4GJs56tiXujUwxdfmNeuG6c0Z5hmBWyi7ON8esDw40xsV11cONp4337BGW1NpJ9oi
W8r+3y8rATTNi3NUlJuY+hh7YdgoPWFuFD8trct/4n4KDJFNOCdOFLPfxW3EU+dV08XC
B1+SpfqgaJpzvgQ4OsAClneKKFOY+I7/xmRa/wCAeS3tHJ6AWcnCuQYnkR/JAtZs/gNt
Mo1w==
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:content-transfer-encoding;
bh=CTSMLDu9tmTorcdSVnyFBMYcHYkpMx0Enos+gBCo0J8=;
b=J150rscmALJ+zfT9xU577GQqejpXJUDDIJcvcbVINt+Ke7hsXBWdqG8kKxNTpa5b59
LGeduTZDi5jAKVpbzpWVuud2RuuBcqZL6uad7RmzClP6yB2YE9qE7UyihemsnAt8PUG3
3HKAzsZD+kMZCslVOvrHdVIH2TZfQMltmQMPyY/vXtDX4sFRoVpvZA0FzbJMbHrhz1dY
KAC1zcEgyRgeGZJvs1wmmX7uaZpS5GD7+7oQvhPXNCeGySzM+bz/sw305Ls8snK3sxrl
6vllOR2oENKcMZOoEh894Guan+MRf4tsWLq/ngHhnsBio+/NkGhpkRJYX4N6116w1hlL
sPGQ==
X-Gm-Message-State: AFeK/H05FvmyLzPKhBFF1ZfHDJYqMGgjnT8/f8KLHL/6cOxpjRiGtKh25vX2we1VC5ji5HReBFqfLTCsVZQ3lQ==
X-Received: by 10.159.39.66 with SMTP id a60mr15304377uaa.28.1491499613440;
Thu, 06 Apr 2017 10:26:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Thu, 6 Apr 2017 10:26:52 -0700 (PDT)
In-Reply-To: <CAFVRnyrqiNY_JOqhv2ysm2WsBMYsU3tTAASAtHzMbA68_9Yx8g@mail.gmail.com>
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>
<CAFVRnyrqiNY_JOqhv2ysm2WsBMYsU3tTAASAtHzMbA68_9Yx8g@mail.gmail.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Thu, 6 Apr 2017 10:26:52 -0700
Message-ID: <CAD1TkXvqjKy7YaAhbuS7kaHKa77YhtFmRsrZOt71CJqFbrqWAg@mail.gmail.com>
To: David Vorick <david.vorick@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 06 Apr 2017 17:34:22 +0000
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 17:26:55 -0000
> We are not going to invalidate covert asicboost without a fight. And we a=
re working with a system that actively (and is demonstrably very effective =
at doing it) resists changes which are contentious. This is definitely a co=
ntentious change, because an important part of the community (the miners) i=
s going to be actively resisting it.
I'd just like to point out, invalidating asicboost has only a very
limited number of potential detractors. Only a mining farm that
self-mined and used custom software would be able to exploit this.
Every other mining farm on the planet, plus any users wishing for more
transactions to be included in blocks would be in favor of this,
assuming the theory that it favors fewer transactions is correct.
That makes it less contentious than many other alternatives. It might
even force the mining operation(s) in question to flip and support SW
in order to avoid losing face and/or appearing guilty.
As an additional plus, nearly all of the BU crowd and most BU
supporting miners would have little reason to object to Asicboost -
Based on philosophy alone, but not based on any practical
considerations.
Jared
On Wed, Apr 5, 2017 at 8:23 PM, David Vorick via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 i=
s
> that this makes a UASF a lot more difficult. Mining hardware that has uni=
que
> optimizations on one chain only can resist a UASF beyond a simple economi=
c
> 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 t=
he
> 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 UA=
SF
> will inevitably cause large reorgs for older nodes, and is not much bette=
r
> than a hardfork.
>
> I don't know what the right answer is. But I know that we are not going t=
o
> get segwit without a fight. We are not going to invalidate covert asicboo=
st
> 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 importan=
t
> 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
