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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
|
Return-Path: <timo.t.hanke@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 02821256
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 22:42:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com
[209.85.217.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 510679C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 22:42:39 +0000 (UTC)
Received: by mail-lb0-f178.google.com with SMTP id pj6so2589234lbb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 15:42:39 -0700 (PDT)
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:cc;
bh=9+VVc4wbZ6yIZJ3PuooIPpjeKIleY53xvq/d3udxTAU=;
b=KfSQsoOAFAf56o7ZkAyNHvpKBznSt8UjC7/HCYDwXB1OPvt3EDcCaOFCTs1NckNsfn
qjRA4IcUTPwYmKane4As9ZpHxV6DAl4wfKuTn44kmaMHp4j6AS7QCyVAQiv7pCa6Ef6p
JjWmNgIN7xAodIoEVihaAd+v12o5U+Tl077Rr9ba6qTGzRInPn/cwcmpOnnzKKPwk2IM
QvxEFlZoY1GX35SSpvkULj8wlJEgtXHeQBBAcFBQbMtpQ3meREqAUvdRTVIrsJmnm3UC
fMlPp9dlFyzl2aYjnZ7wUap1e5rMLVL81vlF7j0pusJ/txxCTm5yLiS55t83DDtWES7w
iQVA==
X-Gm-Message-State: AOPr4FUnfBDARgK7GeFscLWOAfFgr7f9D8GZMc2YIzZzPiVTv+PPDEj7IHIjfmDyaslQvg==
X-Received: by 10.112.147.7 with SMTP id tg7mr2806985lbb.118.1463006557587;
Wed, 11 May 2016 15:42:37 -0700 (PDT)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com.
[209.85.217.175])
by smtp.gmail.com with ESMTPSA id rf6sm1621878lbb.0.2016.05.11.15.42.35
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 11 May 2016 15:42:37 -0700 (PDT)
Received: by mail-lb0-f175.google.com with SMTP id jj5so2581165lbc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 15:42:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.158.135 with SMTP id wu7mr2828761lbb.2.1463006555539;
Wed, 11 May 2016 15:42:35 -0700 (PDT)
Received: by 10.25.144.8 with HTTP; Wed, 11 May 2016 15:42:35 -0700 (PDT)
In-Reply-To: <CABeL=0ih+BB+AKO6uJRCDGZoVo5is4+GBUfQAJkE48Pd_4vzOQ@mail.gmail.com>
References: <20160510185728.GA1149@fedora-21-dvm>
<CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
<CABeL=0iSvOTqQ-JRuhQfc7spKaXi1eBMMm0D-ahVm3GwztQQ_w@mail.gmail.com>
<20160511103601.GC2439@banane.informatik.uni-ulm.de>
<CABeL=0ih+BB+AKO6uJRCDGZoVo5is4+GBUfQAJkE48Pd_4vzOQ@mail.gmail.com>
Date: Wed, 11 May 2016 15:42:35 -0700
X-Gmail-Original-Message-ID: <CAH6h1LuemHi1Z8REhZRywghaLjAzy1e1LeHxVdA7iBifGnLnJA@mail.gmail.com>
Message-ID: <CAH6h1LuemHi1Z8REhZRywghaLjAzy1e1LeHxVdA7iBifGnLnJA@mail.gmail.com>
From: Timo Hanke <timo.hanke@web.de>
To: Jannes Faber <jannes.faber@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c388760c14ac053298c247
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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:42:41 -0000
--001a11c388760c14ac053298c247
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, May 11, 2016 at 3:47 AM, Jannes Faber <jannes.faber@gmail.com>
wrote:
> On 11 May 2016 at 12:36, Henning Kopp <henning.kopp@uni-ulm.de> wrote:
>
>> On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev
>> wrote:
>> > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
>> > bitcoin-dev@lists.linuxfoundation.org> 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 =
AsicBoost
>> at
>> > > any point in time. How can you risk forking that percentage out? Not=
e
>> 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=9Cswitch 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 min=
ing
>> algorithm,
>> > > the kind of hardfork you are proposing would guarantee the
>> persistence of
>> > > two chains.
>> > >
>> >
>> > Assuming AsicBoost miners are in the minority, their chain will
>> constantly
>> > get overtaken. So it will not be one endless hard fork as you claim, b=
ut
>> > rather AsicBoost blocks will continue to be ignored (orphaned) until
>> they
>> > stop making them.
>>
>> At least until a difficulty adjustment on the AsicBoost chain takes
>> place. From that point on, both chains, the AsicBoost one and the
>> forked one will grow approximately at the same speed.
>>
>>
> No: you are still assuming AsicBoost miners would reject normal blocks.
> They don't now and they would have to specifically code for that as a rep=
ly
> to AsicBoost being banned. So there won't be two chains at all, only the
> main chain with a lot (more than usual) of short (few blocks) forks. Each
> forks starts anew, it's not one long fork. Therefore there is no
> "difficulty adjustment on the AiscBoost chain".
>
> Now if they do decide to ban non-AsicBoost blocks as a response to being
> banned themselves, they're just another altcoin with a different PoW and =
no
> one would have a reason to use them over Bitcoin (apart from maybe sellin=
g
> those forked coins asap).
>
This is what I meant. If existing hardware gets forked-out it will
inevitably lead to the creation of an altcoin. Simply because the hardware
exists and can't be used for anything else both chains will survive. I was
only comparing the situation to a contentious hardfork that does not fork
out any hardware. If the latter one is suspected to lead to the permanent
existence of two chains then a hardfork that forks out hardware is even
more likely to do so (I claim it's guaranteed).
> You're confused about what "longest" means as well: it's not just the
> number of blocks, it's the aggregate difficulty that counts: so AsicBoost
> would never become "longer" (more total work) either.
>
> Hope this helps clear things up.
>
> --
> Jannes
>
--001a11c388760c14ac053298c247
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 11, 2016 at 3:47 AM, Jannes Faber <span dir=3D"ltr"><<a href=3D"=
mailto:jannes.faber@gmail.com" target=3D"_blank">jannes.faber@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span=
class=3D"">On 11 May 2016 at 12:36, Henning Kopp <span dir=3D"ltr"><<a =
href=3D"mailto:henning.kopp@uni-ulm.de" target=3D"_blank">henning.kopp@uni-=
ulm.de</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On=
Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev wrote:=
<br>
> On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
><br>
> > There is no way to tell from a block if it was mined with AsicBoo=
st or<br>
> > not. So you don=E2=80=99t know what percentage of the hashrate us=
es AsicBoost at<br>
> > any point in time. How can you risk forking that percentage out? =
Note that<br>
> > this would be a GUARANTEED chain fork. Meaning that after you cha=
nge the<br>
> > block mining algorithm some percentage of hardware will no longer=
be able<br>
> > to produce valid blocks. That hardware cannot =E2=80=9Cswitch ove=
r=E2=80=9D to the majority<br>
> > chain even if it wanted to. Hence you are guaranteed to have two<=
br>
> > co-existing bitcoin blockchains afterwards.<br>
> ><br>
> > Again: this is unlike the hypothetical persistence of two chains =
after a<br>
> > hardfork that is only contentious but doesn=E2=80=99t change the =
mining algorithm,<br>
> > the kind of hardfork you are proposing would guarantee the persis=
tence of<br>
> > two chains.<br>
> ><br>
><br>
> Assuming AsicBoost miners are in the minority, their chain will consta=
ntly<br>
> get overtaken. So it will not be one endless hard fork as you claim, b=
ut<br>
> rather AsicBoost blocks will continue to be ignored (orphaned) until t=
hey<br>
> stop making them.<br>
<br>
</span>At least until a difficulty adjustment on the AsicBoost chain takes<=
br>
place. From that point on, both chains, the AsicBoost one and the<br>
forked one will grow approximately at the same speed.<br>
<br></blockquote><div><br></div></span><div>No: you are still assuming Asic=
Boost miners would reject normal blocks. They don't now and they would =
have to specifically code for that as a reply to AsicBoost being banned. So=
there won't be two chains at all, only the main chain with a lot (more=
than usual) of short (few blocks) forks. Each forks starts anew, it's =
not one long fork. Therefore there is no "difficulty adjustment on the=
AiscBoost chain".<br><br></div><div>Now if they do decide to ban non-=
AsicBoost blocks as a response to being banned themselves, they're just=
another altcoin with a different PoW and no one would have a reason to use=
them over Bitcoin (apart from maybe selling those forked coins asap).<br><=
/div></div></div></div></blockquote><div><br></div><div>This is what I mean=
t. If existing hardware gets forked-out it will inevitably lead to the crea=
tion of an altcoin. Simply because the hardware exists and can't be use=
d for anything else both chains will survive. I was only comparing the situ=
ation to a contentious hardfork that does not fork out any hardware. If the=
latter one is suspected to lead to the permanent existence of two chains t=
hen a hardfork that forks out hardware is even more likely to do so (I clai=
m it's guaranteed).</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br></div><div>You're confused about what "longest" means as=
well: it's not just the number of blocks, it's the aggregate diffi=
culty that counts: so AsicBoost would never become "longer" (more=
total work) either.<br></div><br></div><div class=3D"gmail_quote">Hope thi=
s helps clear things up.<br></div><div class=3D"gmail_quote"><br>--<br></di=
v><div class=3D"gmail_quote">Jannes<br></div></div></div>
</blockquote></div><br></div></div>
--001a11c388760c14ac053298c247--
|
