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
|
Return-Path: <james.hilliard1@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B9343267
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 22:01:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com
[209.85.218.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8607C12F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 22:01:00 +0000 (UTC)
Received: by mail-oi0-f45.google.com with SMTP id k142so90969438oib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 15:01:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-transfer-encoding;
bh=X1Iac2kp2ZtTptAE0fpNrvInyTHuSfVknuJIbJWAFp0=;
b=yv68iYsN5mXnezacOZLkpQUTwU7j1bjNK4KEoaQ7GXUJt+6zKIbt0Sd6xFe9HnPAmq
1RQSg9X0FxRAYipaiiayN33x5jk6kNvvq1krxV8JdVxtH7Oebm6ThSKRZ5lyI0KB37ep
3n53iu9Jbjnsewr2H/xTxvGhCOxBy6HaYWWi8zQa4pVfb8dpf3SC/SVz+1ASPL+wYIbe
9Om9B8JK4CW3DHBBM/Ttz8on6x+D824/jNV8/j+CDcbijDcCaGnDBxe2HMWQNJ3sk9aj
f3Q3pJSGCj0393XW+BsOzw0J/K0hiZJ6GVf6Jf3ilTI0X8wIfSiWycLviNxHeMcSJNJV
qfLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:content-transfer-encoding;
bh=X1Iac2kp2ZtTptAE0fpNrvInyTHuSfVknuJIbJWAFp0=;
b=ja6mY64sHv3uLnXXfwhIGxFVGAknr/PIbsu8ukKSGbRl1QiW+2Mm7aVKoQA407LkyH
hMZNGIFQj9vT5GcjcZZdmWFQAbVDf1OKlfP7MxxdRckO0Grpwhs43BLWOC163zQXou4t
kq98SKnN4CWlqRu2Lf/dpXqdf3GCl+E9qoCV2CwhApiPzIfh9kRlR124/q0TaQCqo7+i
KK1xtJR/k/NcHloXRm88YZiJZ/2cHHQ9RGr6EiaOTYKqyTgXt/9V2OwiFhgZSbHq4EDy
+9Lmtd6mM6FLH3qwN1Ht7XBnNbZtGkJlat/T0QUee13MdK8fCZiaAlK8cErKwmiWWROv
lf2w==
X-Gm-Message-State: AOPr4FUY8PLRqZCrTGW9kxyC10jG8UC3Dj7IPDLjgo1iC8zBSmD6C0TCTC4xFvcEpTTUURhYSWUPLl9hc9kxEQ==
MIME-Version: 1.0
X-Received: by 10.202.204.21 with SMTP id c21mr3022667oig.188.1463004059804;
Wed, 11 May 2016 15:00:59 -0700 (PDT)
Received: by 10.182.115.138 with HTTP; Wed, 11 May 2016 15:00:59 -0700 (PDT)
In-Reply-To: <57339B02.3060806@mattcorallo.com>
References: <20160510185728.GA1149@fedora-21-dvm>
<CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
<57339B02.3060806@mattcorallo.com>
Date: Wed, 11 May 2016 18:00:59 -0400
Message-ID: <CADvTj4pmH2+TE4hdfr3Yo9CMxuDBjzAXj2j-gmpGkmrOMH6Pjg@mail.gmail.com>
From: James Hilliard <james.hilliard1@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.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=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
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
Subject: Re: [bitcoin-dev] Making AsicBoost irrelevant
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: Wed, 11 May 2016 22:01:01 -0000
I was told that the patent appears to be owned exclusively by Bitmain
in China https://www.google.com/patents/CN105245327A?cl=3Den
On Wed, May 11, 2016 at 4:50 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> That's the reason for this post! All current major ASIC manufacturers
> have made warrants that they are not using AsicBoost (with the exception
> of the 21 Inc Bitcoin computer).
>
> The fact that the optimization was patented is what has required that we
> work to hardfork it out, not that people might have such private
> optimizations. The fact that AsicBoost was independently discovered by
> at least two (if not three) organizations seems to lend credence to the
> idea that private optimizations will only provide a temporary win over
> competitors.
>
> Matt
>
> On 05/11/16 03:14, Timo Hanke via bitcoin-dev wrote:
>> There is no way to tell from a block if it was mined with AsicBoost or
>> not. So you don=E2=80=99t know what percentage of the hashrate uses Asic=
Boost at
>> any point in time. How can you risk forking that percentage out? Note
>> that this would be a GUARANTEED chain fork. Meaning that after you
>> change the block mining algorithm some percentage of hardware will no
>> longer be able to produce valid blocks. That hardware cannot =E2=80=9Csw=
itch
>> over=E2=80=9D to the majority chain even if it wanted to. Hence you are
>> guaranteed to have two co-existing bitcoin blockchains afterwards.
>>
>> Again: this is unlike the hypothetical persistence of two chains after a
>> hardfork that is only contentious but doesn=E2=80=99t change the mining
>> algorithm, the kind of hardfork you are proposing would guarantee the
>> persistence of two chains.
>>
>> Note that =E2=80=9CAsicBoost=E2=80=9D above is replaceable with =E2=80=
=9Coptimization X=E2=80=9D. It=E2=80=99s
>> simply a logical argument: If you want to make optimization X impossible
>> and someone is already using optimization X you end up with two chains.
>> So unless you know exactly which optimizations are in use (and therefore
>> also know which ones are not in use) you can=E2=80=99t make these kind o=
f
>> changes. AsicBoost is known at least since middle of 2013.
>>
>> To be more precise, if you change the block validation ruleset R to
>> block validation ruleset S you have to make sure that every hardware
>> that was capable of mining R-valid blocks is also capable of mining
>> S-valid blocks.
>>
>> The problem is that chip manufacturers will not tell you which
>> optimizations they use. You would have to threaten to irreversibly fork
>> their hardware out by a rule change, only then would they start shouting
>> and reveal their optimization. It seems extremely dangerous to set the
>> precedence of a hardfork that irreversibly forks out a certain type of
>> mining hardware.
>>
>> The part "Also the fix should be compatible with existing mining
>> hardware." is impossible to achieve because it's unclear what "existing
>> mining hardware" is. There has never been a specification of what mining
>> hardware should do. There are only acceptance rules.
>>
>> The only way out is to go the exact opposite way and to embrace as many
>> optimizations as possible to the point where there are no more
>> optimizations left to do, or hopefully getting very close to that point.
>>
>> Timo
>>
>>
>>
>> On Tue, May 10, 2016 at 11:57 AM, Peter Todd via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>
>> As part of the hard-fork proposed in the HK agreement(1) we'd like
>> to make the
>> patented AsicBoost optimisation useless, and hopefully make further
>> similar
>> optimizations useless as well.
>>
>> What's the best way to do this? Ideally this would be SPV
>> compatible, but if it
>> requires changes from SPV clients that's ok too. Also the fix this
>> should be
>> compatible with existing mining hardware.
>>
>>
>> 1)
>> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-2=
66d475a61ff
>>
>> 2)
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/01=
2596.html
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org <http://petertodd.o=
rg>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
