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
|
Return-Path: <jannes.faber@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CF6B1282
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 10:48:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D6502E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 10:48:20 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id a17so75142411wme.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 03:48:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=u/3SSxsQOMNLKa8CuNemWVRfqA7FTKxG4QOVf7v459U=;
b=HtTyEioYSoHBMbXRyCxqZz3gl4DV2gQQxxGNJRKx1r5S7QJbf27cSGBrmnvX5yJZXD
Rtlbhd1Ck1E8I/EmemQiru1/Cez+1raRXxpA29hd0dEsDBSSx/Ngu1dfPBFCkzStZFRS
1ed+Hfe3xSVO9SuBtDeIz6ZEwBCsZ8Ytv23hA6UzI3q8t3G5HTGyb44pDYBiIUA3dfJw
R1xmYrXbG+P0JnRDsohk0RYBaGNhlJyRCmabdTe6eM3hBGquNeFRS74kKnbGmM4C0s9w
NpcfRWNQ4kBvSwCe8zl//wKYZbCUh0EtCrga7HCAmROazgG0jXUv2JJQ/JaDvdyLYJw3
0SXQ==
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:from:date
:message-id:subject:to:cc;
bh=u/3SSxsQOMNLKa8CuNemWVRfqA7FTKxG4QOVf7v459U=;
b=cVzpFge3g2ONJmhovs9F/5aaqtv0iZsLF7JLUPBCwGACiXJtyqq/NwfJfJ5VcEuE5r
FH69pp/RA4QJzB+VbdGH2MGS9mNI3+La/1ArVxlmZP5pBpbKALvffXsGZeptoooPmC/h
uetoGWUZ2ZoV8sX1RgzQM3rAHPBCtf+v+WU/KUK9q8mat9ddg4fs5PiGtRMhmEKNwoc6
WvbVL4XJdOJxZPWsG5AAOtFHV/BIHq4JGXvyfkCsqsj7PafkmCLnSZ2y6ihPPXdwKcCK
BkHQ135CzNEu2SU735/DMxXEx2bQ8H9SO6UD08YA+ABhE37NlJg0fN4aQEsX4jbIEQHX
kMrw==
X-Gm-Message-State: AOPr4FXRcZhEiKaJqsxDWHdgTN8TNma91GBUgWhHLoPbseETIsLFQqLha2Nw0HuiaoiOQw==
X-Received: by 10.194.63.226 with SMTP id j2mr2973304wjs.27.1462963699379;
Wed, 11 May 2016 03:48:19 -0700 (PDT)
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com.
[74.125.82.48]) by smtp.gmail.com with ESMTPSA id
gk6sm7405153wjc.31.2016.05.11.03.48.18
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 11 May 2016 03:48:18 -0700 (PDT)
Received: by mail-wm0-f48.google.com with SMTP id n129so213999034wmn.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 03:48:18 -0700 (PDT)
X-Received: by 10.28.181.148 with SMTP id e142mr3387151wmf.38.1462963698154;
Wed, 11 May 2016 03:48:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.155.36 with HTTP; Wed, 11 May 2016 03:47:58 -0700 (PDT)
In-Reply-To: <20160511103601.GC2439@banane.informatik.uni-ulm.de>
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>
From: Jannes Faber <jannes.faber@gmail.com>
Date: Wed, 11 May 2016 12:47:58 +0200
X-Gmail-Original-Message-ID: <CABeL=0ih+BB+AKO6uJRCDGZoVo5is4+GBUfQAJkE48Pd_4vzOQ@mail.gmail.com>
Message-ID: <CABeL=0ih+BB+AKO6uJRCDGZoVo5is4+GBUfQAJkE48Pd_4vzOQ@mail.gmail.com>
To: Henning Kopp <henning.kopp@uni-ulm.de>
Content-Type: multipart/alternative; boundary=001a114a0dc68c5c7305328ec76c
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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 10:48:21 -0000
--001a114a0dc68c5c7305328ec76c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 o=
r
> > > not. So you don=E2=80=99t know what percentage of the hashrate uses A=
sicBoost
> 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=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 afte=
r
> a
> > > hardfork that is only contentious but doesn=E2=80=99t change the mini=
ng
> algorithm,
> > > the kind of hardfork you are proposing would guarantee the persistenc=
e
> 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, bu=
t
> > rather AsicBoost blocks will continue to be ignored (orphaned) until th=
ey
> > 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 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".
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).
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
--001a114a0dc68c5c7305328ec76c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 11 May 2016 at 12:36, Henning Kopp <span dir=3D"ltr">&l=
t;<a href=3D"mailto:henning.kopp@uni-ulm.de" target=3D"_blank">henning.kopp=
@uni-ulm.de</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Ma=
y 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">bitcoin-dev@l=
ists.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><div>No: you are still assuming AsicBoost m=
iners 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 u=
sual) of short (few blocks) forks. Each forks starts anew, it's not one=
long fork. Therefore there is no "difficulty adjustment on the AiscBo=
ost chain".<br><br></div><div>Now if they do decide to ban non-AsicBoo=
st blocks as a response to being banned themselves, they're just anothe=
r altcoin with a different PoW and no one would have a reason to use them o=
ver Bitcoin (apart from maybe selling those forked coins asap).<br><br></di=
v><div>You're confused about what "longest" means as well: it=
's not just the number of blocks, it's the aggregate difficulty tha=
t counts: so AsicBoost would never become "longer" (more total wo=
rk) either.<br></div><br></div><div class=3D"gmail_quote">Hope this helps c=
lear things up.<br></div><div class=3D"gmail_quote"><br>--<br></div><div cl=
ass=3D"gmail_quote">Jannes<br></div></div></div>
--001a114a0dc68c5c7305328ec76c--
|
