summaryrefslogtreecommitdiff
path: root/f1/a98528757a0f9bf30c14905fea79e3bb5aaa2d
blob: 151f6ad148b800de53772237920e639ee617cbaa (plain)
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
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 AE72287A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 13:55:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
	[209.85.213.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 023ABFF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 13:55:33 +0000 (UTC)
Received: by mail-vk0-f43.google.com with SMTP id d188so40884382vka.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Apr 2017 06:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream-io.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=83QWtXnEpbqAt4ctnb++h8JuufVA1ygqZIDEHSTHfrs=;
	b=gjbjmrIp/dQoYnRr+KZzmgVL1mCEC3mpooYKlxxN+iV4HXNg/bdD63AE5XMPPbyGc7
	tPQjZAB/I6/265qyIixKJcROKAPw3Upa7o96ce2rzBiOOt4Fb47xe9KG8tC10UcqE8y7
	TmVyyHVssnI5PIp9axncYy2XjpiJ2w4meNFSBi4PqHtCZf2XrJ8dOAUmgW0EcESZZvs0
	E/11enT0vA4aAF5ZGwA8ivBjq2RkknY0TnGFZxc4H2FM/lRScK8uLtoJQMI/bryYfPCK
	iyR9a41tXHOSgft00wbBBOH7tzLT2k5pEyBdOuhzg6JYoP7HYvu60/EmB7ELZKJFan7K
	xrwQ==
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;
	bh=83QWtXnEpbqAt4ctnb++h8JuufVA1ygqZIDEHSTHfrs=;
	b=FzZeIPddBAVaRPwBLmIu4PukB5mYtRsfAVlfniMBDtl9yoYLmThV6e8Jx7K1HLV6XC
	fpmiER4aHuLlhO5ZSU/GkuvAhpjC7hrqfKrZ3Y023DEIhRPy2+M8PxoOEbWlz1KJjBtw
	ZGjMGIh/Au4j4nnrIQCFuCXeYPuz6NIL7wQ+JVSpp3bfe/MK9WrgNZ5mllznM/xtXxOy
	wMxA8YzCdXFFSlv0ReMnjteyP2fBDumaiEqiiad6F+ua1JXadxTHwaUEWPViDNsICRVy
	TbFAe8mxN1d6FH0Axs8JIefHR+cgVKfMTMwKSvIbHIi7FI5QnXVLTwI8Bz2b7YJuhPR3
	88gw==
X-Gm-Message-State: AFeK/H1PQFDm4UcaL67jEJ3qbe55GmGvElPU+a6WX7Ub7U8Uf1imt5a4/rsjyadtlhUxgPYNlVxDiSOSolI/4hFe
X-Received: by 10.159.55.234 with SMTP id q97mr15851769uaq.115.1491486932608; 
	Thu, 06 Apr 2017 06:55:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.91.202 with HTTP; Thu, 6 Apr 2017 06:55:31 -0700 (PDT)
Received: by 10.176.91.202 with HTTP; Thu, 6 Apr 2017 06:55:31 -0700 (PDT)
In-Reply-To: <CAMZUoKn8tr3LGbks0TnaCx9NTP6MZUzQ8PE6jDq1xiqpYyYwow@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>
	<F5F02B94-E094-4C16-80B6-8B0876E423E4@toom.im>
	<CAMZUoK=oDAD9nhFAHkgncWtYxjBNh3qXbUffOH57QMnqjhmN6g@mail.gmail.com>
	<CAMZUoKn8tr3LGbks0TnaCx9NTP6MZUzQ8PE6jDq1xiqpYyYwow@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 6 Apr 2017 09:55:31 -0400
Message-ID: <CAMZUoKkXMffG1RFT3398zcBN3EmwgPLXm2egeUTqO7ELn7BnsA@mail.gmail.com>
To: Jonathan Toomim <j@toom.im>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c03eda2ce3a6a054c7fdcfb
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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 13:55:34 -0000

--94eb2c03eda2ce3a6a054c7fdcfb
Content-Type: text/plain; charset=UTF-8

Hi Jonathan,

The proposal raised here does not deny miners the ability to use ASICBOOST.
Miners can still use overt ASICBOOST by version bit fiddling and get the
same power savings.  In fact, overt ASICBOOST is much easier to implement
than covert ASICBOOST, so I don't really understand what the objection is.


On Apr 6, 2017 13:44, "Jonathan Toomim via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Ethically, this situation has some similarities to the DAO fork. We have an
entity who closely examined the code, found an unintended characteristic of
that code, and made use of that characteristic in order to gain tens of
millions of dollars. Now that developers are aware of it, they want to
modify the code in order to negate as much of the gains as possible.

There are differences, too, of course: the DAO attacker was explicitly
malicious and stole Ether from others, whereas Bitmain is just optimizing
their hardware better than anyone else and better than some of us think
they should be allowed to.

In both cases, developers are proposing that the developers and a majority
of users collude to reduce the wealth of a single entity by altering the
blockchain rules.

In the case of the DAO fork, users were stealing back stolen funds, but
that justification doesn't apply in this case. On the other hand, in this
case we're talking about causing someone a loss by reducing the value of
hardware investments rather than forcibly taking back their coins, which is
less direct and maybe more justifiable.

While I don't like patented mining algorithms, I also don't like the idea
of playing Calvin Ball on the blockchain. Rule changes should not be
employed as a means of disempowering and empoverishing particular entities
without very good reason. Whether patenting a mining optimization qualifies
as good reason is questionable.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--94eb2c03eda2ce3a6a054c7fdcfb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Hi Jonathan,<div dir=3D"auto"><br></div><div dir=3D"=
auto">The proposal raised here does not deny miners the ability to use ASIC=
BOOST. Miners can still use overt ASICBOOST by version bit fiddling and get=
 the same power savings.=C2=A0 In fact, overt ASICBOOST is much easier to i=
mplement than covert ASICBOOST, so I don&#39;t really understand what the o=
bjection is.</div><br><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Apr 6, 2017 13:44, &quot;Jonathan Toomim via bitcoin-dev&quot; &lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><blockquote clas=
s=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">Ethically, this situation has some similarities to the DAO fork. W=
e have an entity who closely examined the code, found an unintended charact=
eristic of that code, and made use of that characteristic in order to gain =
tens of millions of dollars. Now that developers are aware of it, they want=
 to modify the code in order to negate as much of the gains as possible.<br=
>
<br>
There are differences, too, of course: the DAO attacker was explicitly mali=
cious and stole Ether from others, whereas Bitmain is just optimizing their=
 hardware better than anyone else and better than some of us think they sho=
uld be allowed to.<br>
<br>
In both cases, developers are proposing that the developers and a majority =
of users collude to reduce the wealth of a single entity by altering the bl=
ockchain rules.<br>
<br>
In the case of the DAO fork, users were stealing back stolen funds, but tha=
t justification doesn&#39;t apply in this case. On the other hand, in this =
case we&#39;re talking about causing someone a loss by reducing the value o=
f hardware investments rather than forcibly taking back their coins, which =
is less direct and maybe more justifiable.<br>
<br>
While I don&#39;t like patented mining algorithms, I also don&#39;t like th=
e idea of playing Calvin Ball on the blockchain. Rule changes should not be=
 employed as a means of disempowering and empoverishing particular entities=
 without very good reason. Whether patenting a mining optimization qualifie=
s as good reason is questionable.<br>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div></div></div>

--94eb2c03eda2ce3a6a054c7fdcfb--