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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6E666722
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 23:01:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148098.authsmtp.com (outmail148098.authsmtp.com
[62.13.148.98])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 70E4613D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2016 23:01:49 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u4BN1mEf067607;
Thu, 12 May 2016 00:01:48 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u4BN1jng062998
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Thu, 12 May 2016 00:01:46 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id C246840109;
Wed, 11 May 2016 23:00:25 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id AA1152012A; Wed, 11 May 2016 19:01:44 -0400 (EDT)
Date: Wed, 11 May 2016 19:01:44 -0400
From: Peter Todd <pete@petertodd.org>
To: Timo Hanke <timo.hanke@web.de>
Message-ID: <20160511230144.GA5252@fedora-21-dvm>
References: <20160510185728.GA1149@fedora-21-dvm>
<CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN"
Content-Disposition: inline
In-Reply-To: <CAH6h1Ls_Dh_oBo-fUMoBtwCQ=U3XgBLhbuHvH+ra78bjHYNyXQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 56015078-17cc-11e6-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwAUFVQNAgsB AmAbW1ReUFx7XWU7 bghPaBtcak9QXgdq
T0pMXVMcUQEafx1b WEkeVBt7fg0IcXdz ZwhnWHBaWUR9fVt8
RR0HCGwHMGF9YGIW BV1YdwJRcQRDe0tA b1YxNiYHcQ5VPz4z
GA41ejw8IwAXDS1W QwcCZXsJQE0hGTkn W1gDBy8iGUAbTiMv RwAA
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 23:01:50 -0000
--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, May 10, 2016 at 08:14:33PM -0700, Timo Hanke wrote:
> There is no way to tell from a block if it was mined with AsicBoost or no=
t.
> 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 th=
is
> 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.
First of all, we can easily do this in a way where miners show their support
for this change, say with the usual 95% approval threshold we've been using=
for
soft-forks. That gets the % of hashing power on a AsicBoost chain fork down=
to
5% at most.
Secondly, we can probably make the consensus PoW allow blocks to be mined u=
sing
both the existing PoW algorithm, and a very slightly tweaked version where
implementing AsicBoost gives no advantage. That removes any incentive to
implement AsicBoost, without making any hardware obsolete (such as 21inc's
hardware). This means that no hashing power at all needs to use the AsicBoo=
st
patent.
Obviously, the fact that miners can support such a change (assuming of cour=
se
the economic majority approves it as well) changes the negotiation position=
re:
licensing fees; the actual outcome may simply be you guys make the patent 1=
00%
public for all to use at a much reduced price, given you're lack of negotia=
tion
strength.
> Note that =E2=80=9CAsicBoost=E2=80=9D above is replaceable with =E2=80=9C=
optimization X=E2=80=9D. It=E2=80=99s
> simply a logical argument: If you want to make optimization X impossible
> and someone is already using optimization X you end up with two chains. So
> unless you know exactly which optimizations are in use (and therefore also
> know which ones are not in use) you can=E2=80=99t make these kind of chan=
ges.
> AsicBoost is known at least since middle of 2013.
I think _patented_ optimizations where one party has a monopoly are very
different than optimizations that anyone can independently rediscover -
AsicBoost itself looks to be something that two or three parties independen=
tly
discovered.
> 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.
=2E..which is a scenario that may result in a dozen patented optimizations,=
with
new ASIC manufacturers needing a dozen licenses, from potentially hostile
entities.
For instance, it's not clear to me if you actually own this patent, or
Cointerra's creditors. Obviously in the latter case, it'd be quite possible
that some kind of bankrupcy court ruling results in the patent getting sold=
to
a hostile entity who will use it against all of Bitcoin. Equally, even if i=
t is
100% owned by you and Sergio, it'd be very easy for a personal bankrupcy to
result in the same scenario (suppose you get into a car accident and lose a
negligence lawsuit over it).
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--J/dobhs11T7y2rNN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJXM7nVAAoJEGOZARBE6K+y6LQH/1IrkZMlvNj5Q1CNsmdEvhzf
W3qjgzOnzTI5eEeNf3Rbpv4/+7UDLuL4QwYLLUTsY0ZaZhgfjCSfRPXiMuL4u4tP
KcqF5JZbPvFHiPsQIu+oFyGtyMengRTcESRYofFcqXlZrjP/9skC4+wrkPvGuqoo
LyS6MDTa04mOHlyDrgiUkQ1VzImVWz0QhhE1QtO04MqFr35qMCtNwGoqf5WqeZk8
7hv7howUIUJ+ognPNGFK0mLRoConLMnx1mL4QBjYqzzqRRRWVx8TrICL0bTH4geg
h4vLPNEmIQS6h0NZzZTToeM2fPnVTlaFuXZOmfZoKLOQu0pGSxXHi7fErO2oVuk=
=DsoY
-----END PGP SIGNATURE-----
--J/dobhs11T7y2rNN--
|
