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
|
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 6469E71E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 09:21:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8FF9D63
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 09:21:32 +0000 (UTC)
Received: by mail-wm0-f53.google.com with SMTP id g17so71033974wme.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 02:21:32 -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=ylHEjThBMowkJv4b4hJb5LeiWPKeY3IXWUbmmR3QgPQ=;
b=pcu63lzguybZsuNPLOrQZEEnvW5xsCv7uUAuLg/7+MW7yCDqoW6S+lCNmvpKHAd8AQ
fXPwB7mW1MiVpyksagp3ZLp71sQeyquWq4tFM8Af7NV7urbL84XwisR/QXZ7pMdZUDzb
TQ35MgNBwk5FnTAs7g3Xd3ydzeZ1aJWx9kCHgwB8FoR0huUHzrANuBK6exwJm3kmE4zj
UsQydd90aKEVs8Il5VeFn6104fNF5vrrh4D6C5N2pg8VJy3MigPIGrJm9WakolyrUB4l
J5ABkVshG/K8Xpz7S4oY7OpmywIxxDJQZ1SB1ttHjA6Y34xbW57hMHkf9O5jkU3Dvg4Q
NdVg==
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=ylHEjThBMowkJv4b4hJb5LeiWPKeY3IXWUbmmR3QgPQ=;
b=BWse8XQWdGiG8Kd2ct2tci0cs6T/GvZV5xdVfeb8PDhm7yb+FBSLkvBf/jMum9zu+S
CeQRb/RWhoQjwt+X0OMvkqXeS3DzswhhSV6WNeSudBZx8XPkHa4THIA4V0btT7UpEVCP
K8RZptf+HazydoSTP9vZflFXJAsKHw9aV/Oegm8oIjbezN0a4NyRaS1zNF6Mt2x3Zvqq
TY4MCTqxk3bgMZa6vklDgq+s7yfO/Und9rzUT43LGwTJmPS8WV2byQo5RXyYqGhgRwVQ
8WNdsNfQrRinKljbRUGqcTnWA9Q60K6bY7OHN9r0LuiGs3xhvubcuPtbzd4l6zJphUnH
pwTQ==
X-Gm-Message-State: AOPr4FXkHI7ZZ6wzfD+FW7gSEDKA60lRQxKFHUg/vmaqBhMFUR4gNpXoDyqY/O3Z3qgOqg==
X-Received: by 10.28.32.147 with SMTP id g141mr245585wmg.22.1462958491193;
Wed, 11 May 2016 02:21:31 -0700 (PDT)
Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com.
[74.125.82.50]) by smtp.gmail.com with ESMTPSA id
f135sm7421590wmf.22.2016.05.11.02.21.29
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 11 May 2016 02:21:30 -0700 (PDT)
Received: by mail-wm0-f50.google.com with SMTP id n129so210943339wmn.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 02:21:29 -0700 (PDT)
X-Received: by 10.194.205.167 with SMTP id lh7mr2568942wjc.30.1462958489785;
Wed, 11 May 2016 02:21:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.155.36 with HTTP; Wed, 11 May 2016 02:21:10 -0700 (PDT)
In-Reply-To: <CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
References: <20160510185728.GA1149@fedora-21-dvm>
<CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
From: Jannes Faber <jannes.faber@gmail.com>
Date: Wed, 11 May 2016 11:21:10 +0200
X-Gmail-Original-Message-ID: <CABeL=0iSvOTqQ-JRuhQfc7spKaXi1eBMMm0D-ahVm3GwztQQ_w@mail.gmail.com>
Message-ID: <CABeL=0iSvOTqQ-JRuhQfc7spKaXi1eBMMm0D-ahVm3GwztQQ_w@mail.gmail.com>
To: Timo Hanke <timo.hanke@web.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=047d7b8739e81af01e05328d91a1
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
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 09:21:33 -0000
--047d7b8739e81af01e05328d91a1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 AsicB=
oost at
> any point in time. How can you risk forking that percentage out? Note tha=
t
> 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 mining a=
lgorithm,
> 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, but
rather AsicBoost blocks will continue to be ignored (orphaned) until they
stop making them.
That hardware cannot =E2=80=9Cswitch over=E2=80=9D to the majority chain ev=
en if it wanted
> to.
>
They will in fact continually "switch over" to the majority, they just are
unable to extend that majority chain themselves.
--
Jannes
--047d7b8739e81af01e05328d91a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <span dir=3D"ltr"><<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>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? Note that this would b=
e a GUARANTEED chain fork. Meaning that after you change the block mining a=
lgorithm some percentage of hardware will no longer be able to produce vali=
d blocks. That hardware cannot =E2=80=9Cswitch over=E2=80=9D to the majorit=
y chain even if it wanted to. Hence you are guaranteed to have two co-exist=
ing bitcoin blockchains afterwards.</div><div><br></div><div>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 chain=
s.</div></div></blockquote><div><br></div><div>Assuming AsicBoost miners ar=
e in the minority, their chain will constantly get overtaken. So it will no=
t be one endless hard fork as you claim, but rather AsicBoost blocks will c=
ontinue to be ignored (orphaned) until they stop making them.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Tha=
t hardware cannot =E2=80=9Cswitch over=E2=80=9D to the majority chain even =
if it wanted to.</div></div></blockquote><div><br></div><div>They will in f=
act continually "switch over" to the majority, they just are unab=
le to extend that majority chain themselves.<br><br>--<br></div><div>Jannes=
<br></div></div></div></div>
--047d7b8739e81af01e05328d91a1--
|
