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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 59A9571E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 14:07:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com
[209.85.213.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF69117B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 14:07:27 +0000 (UTC)
Received: by mail-vk0-f54.google.com with SMTP id o133so58243155vka.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 07:07:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc; bh=CtMVKhwLK9gfB4fCxZ1/hAAqr1sL9aE2b3PUp/NCsDw=;
b=duDLeFQEJIPTmrTdGpO6X7SfTLgflxFAFGCS+rmpBhIvPQ3AX8KQX3zwicSFhFzQXs
WFpcmdq6zLT3waL4U9uSoTRVJaY6fkNWEuIjdsECUMQxoG6TXu2T/BiOktL0Zv13VkGB
jPZYCbFfJQL3mUelpGwy9cW/F97FFJ0XVNXene3RfBKFMLksi45x/dKRWHf3aPEK6o7Q
rrvto89MfWSx0MMUcQEBOe7KCXGkIMlmjdRI63dPf2+md6bMxM3TeCYYQF6+n3unO931
pSnrrbQqNA4H5PlYNqefZlp/Lj8gTOXMPmSbtMW7W405sfkBYmCvNf32X8dgocFI7i21
5ygg==
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=CtMVKhwLK9gfB4fCxZ1/hAAqr1sL9aE2b3PUp/NCsDw=;
b=OQVF5rvLzhwYHRswW6efUbvtCABt5mCx5xAOsR8I7y7Oys7x5sFM9EAXHCUAa128xd
iy32rglZWpQbV/zJ0+wCknoCt2L8pCW4wTpERUOwGjI58kWtMBjMgxGxg38YF5Xd4rFs
tPicGoGM5dl1pBo9KPi4b+NKaBybVTAfx+4ipcta2SH/bzzh0zGHynn0Ny2isr1f2ffR
NLb7O8e/mbSe0z61FVqcaFaNa7ilSJtvbewR+FNgsZmOwYWj6nYXsjhNo66oRhtUeWLm
0QdKdUnfRvUk9EPnuCbz0+EU+WczwS0U0hNCzssPQAgmbNE/wJjD0GN2ACsTRGsZBsfx
1Otw==
X-Gm-Message-State: AOPr4FW8zF4iu6VRbznfNCFio0zRsPTXQHdr6rcc924ySLIzp1VRIGvKUeiH87S2bROp9s/v5Z0wVV2mp5TmnA==
MIME-Version: 1.0
X-Received: by 10.176.6.38 with SMTP id f35mr1859982uaf.36.1462975646826; Wed,
11 May 2016 07:07:26 -0700 (PDT)
Received: by 10.31.141.73 with HTTP; Wed, 11 May 2016 07:07:26 -0700 (PDT)
Received: by 10.31.141.73 with HTTP; Wed, 11 May 2016 07:07:26 -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>
Date: Wed, 11 May 2016 16:07:26 +0200
Message-ID: <CABm2gDpW5K9Y8LFO79RJJS_qgnL-wyc+b1UC+RSaKMrk31fB_Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Timo Hanke <timo.hanke@web.de>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c04796ebfb9d90532918f3e
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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 14:07:28 -0000
--94eb2c04796ebfb9d90532918f3e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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 alg=
orithm,
the kind of hardfork you are proposing would guarantee the persistence of
two chains.
If all users abandon the old rules, why would asicboost miners continue to
spend energy on a chain that everybody else is ignoring?
> 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.
Why?
No, this proposal, for example, may make patented asicboost hardware
obsolete.
I don't accept this claim as true, this is just your opinion.
>
> 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.
What do you mean by "embrace" in the context of a patented optimization
that one miner can prevent the rest from using?
--94eb2c04796ebfb9d90532918f3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br>
><br>
> 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 persi=
stence of two chains.</p>
<p dir=3D"ltr">If all users abandon the old rules, why would asicboost mine=
rs continue to spend energy on a chain that everybody else is ignoring?</p>
<p dir=3D"ltr">> To be more precise, if you change the block validation =
ruleset R to block validation ruleset S you have to make sure that every ha=
rdware that was capable of mining R-valid blocks is also capable of mining =
S-valid blocks.=C2=A0</p>
<p dir=3D"ltr">Why?<br>
No, this proposal, for example, may make patented asicboost hardware obsole=
te.<br>
I don't accept this claim as true, this is just your opinion.</p>
<p dir=3D"ltr">><br>
> The only way out is to go the exact opposite way and to embrace as man=
y optimizations as possible to the point where there are no more optimizati=
ons left to do, or hopefully getting very close to that point.=C2=A0</p>
<p dir=3D"ltr">What do you mean by "embrace" in the context of a =
patented optimization that one miner can prevent the rest from using?<br>
</p>
--94eb2c04796ebfb9d90532918f3e--
|
