summaryrefslogtreecommitdiff
path: root/6b/c1afe96264bcd8548f554f7aebaf7a46e863fd
blob: 1cc1d2dd35dd6cc6f7e8bc560f5cb7706e30d537 (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
Return-Path: <marco@agner.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A8ED9B1E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 16:57:19 +0000 (UTC)
X-Greylist: delayed 00:07:52 by SQLgrey-1.7.6
Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69D1B16A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 16:57:18 +0000 (UTC)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx2.mailbox.org (Postfix) with ESMTPS id 08E454586D;
	Thu,  6 Apr 2017 18:49:24 +0200 (CEST)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240])
	by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de
	[80.241.56.116]) (amavisd-new, port 10030)
	with ESMTP id QWtdykyMI8WB; Thu,  6 Apr 2017 18:49:19 +0200 (CEST)
To: Jonathan Toomim <j@toom.im>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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>
	<CAFVRnyrqiNY_JOqhv2ysm2WsBMYsU3tTAASAtHzMbA68_9Yx8g@mail.gmail.com>
	<F5F02B94-E094-4C16-80B6-8B0876E423E4@toom.im>
From: Marco <marco@agner.io>
Message-ID: <f9dd165b-7e04-c842-6406-28b3083f44b9@agner.io>
Date: Thu, 6 Apr 2017 13:49:13 -0300
MIME-Version: 1.0
In-Reply-To: <F5F02B94-E094-4C16-80B6-8B0876E423E4@toom.im>
Content-Type: multipart/alternative;
	boundary="------------0911F20F9B0EA975A39710ED"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW 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: Thu, 06 Apr 2017 16:58:48 +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 16:57:19 -0000

This is a multi-part message in MIME format.
--------------0911F20F9B0EA975A39710ED
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 04/06/2017 03:24 AM, Jonathan Toomim via bitcoin-dev wrote:
> Ethically, this situation has some similarities to the DAO fork. We hav=
e an entity who closely examined the code, found an unintended characteri=
stic of that code, and made use of that characteristic in order to gain t=
ens of millions of dollars. Now that developers are aware of it, they wan=
t 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 major=
ity 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 thi=
s case we're talking about causing someone a loss by reducing the value o=
f hardware investments rather than forcibly taking back their coins, whic=
h is less direct and maybe more justifiable.
>
> While I don't like patented mining algorithms, I also don't like the id=
ea of playing Calvin Ball on the blockchain. Rule changes should not be e=
mployed as a means of disempowering and empoverishing particular entities=
 without very good reason. Whether patenting a mining optimization qualif=
ies as good reason is questionable.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Quite different in that the DAO fork was about an application level bug
and this current proposal is about a possibly dangerous incentive at
protocol level.
In the first, a protocol change was called to recover funds lost for an
application level bug. In the latter, a protocol change is being called
to address a perceived incentive problem in the protocol.

A good comparison would be if a protocol level change was being proposed
for a case like mt gox. But it's not.

Plus... This proposal only addresses one covert asicboost and not other
overt forms.
Even though we may, as well, have good reasons to block other overt forms=
=2E

Marco Agner
https://www.agner.io


--------------0911F20F9B0EA975A39710ED
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><tt>On 04/06/2017 03:24 AM, Jonathan
        Toomim via bitcoin-dev wrote:</tt><tt><br>
      </tt></div>
    <blockquote cite="mid:F5F02B94-E094-4C16-80B6-8B0876E423E4@toom.im"
      type="cite">
      <pre wrap="">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.
</pre>
      <tt><br>
      </tt>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <tt><br>
      </tt>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <tt>Quite different in that the DAO fork was about an application
      level bug and this current proposal is about a possibly dangerous
      incentive at protocol level.<br>
      In the first, a protocol change was called to recover funds lost
      for an application level bug. In the latter, a protocol change is
      being called to address a perceived incentive problem in the
      protocol.<br>
      <br>
      A good comparison would be if a protocol level change was being
      proposed for a case like mt gox. But it's not.<br>
      <br>
      Plus... This proposal only addresses one covert asicboost and not
      other overt forms.<br>
      Even though we may, as well, have good reasons to block other
      overt forms.<br>
    </tt>
    <pre class="moz-signature" cols="72">Marco Agner
<a class="moz-txt-link-freetext" href="https://www.agner.io">https://www.agner.io</a></pre>
  </body>
</html>

--------------0911F20F9B0EA975A39710ED--