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
|
Return-Path: <henning.kopp@uni-ulm.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 259C9411
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 10:36:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from smtp.uni-ulm.de (smtp.uni-ulm.de [134.60.1.26])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53FA4E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 10:36:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at uni-ulm.de
Received: from banane.informatik.uni-ulm.de (banane.informatik.uni-ulm.de
[134.60.77.114]) (authenticated bits=0)
by mail.uni-ulm.de (8.14.9/8.14.9) with ESMTP id u4BAa6cV005304
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
Wed, 11 May 2016 12:36:07 +0200 (CEST)
Date: Wed, 11 May 2016 12:36:01 +0200
From: Henning Kopp <henning.kopp@uni-ulm.de>
To: Jannes Faber <jannes.faber@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABeL=0iSvOTqQ-JRuhQfc7spKaXi1eBMMm0D-ahVm3GwztQQ_w@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
X-DCC-x.dcc-servers-Metrics: poseidon 104; Body=3 Fuz1=3 Fuz2=3
X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE,
RP_MATCHES_RCVD 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 10:36:17 -0000
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’t 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 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 “switch over” 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’t change the mining 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, but
> 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.
All the best
Henning
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp
|
