summaryrefslogtreecommitdiff
path: root/ca/fa644e8fdf6a69c16aebd3e807fbdc48bb60ca
blob: 493e5af93b263b5260f9cd78f82c6b3d82709df9 (plain)
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
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 03652721
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 31 May 2017 06:18:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com [74.125.83.42])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6435F134
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 31 May 2017 06:18:01 +0000 (UTC)
Received: by mail-pg0-f42.google.com with SMTP id u28so3157876pgn.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 30 May 2017 23:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to; bh=xFRemSese1T3cQvlB16guJF9yltDCqIDiS1Yzof/xO4=;
	b=q0f56V31bkWFSjHT/ulL/xxLsJgrws6r+5WiwWi6bufgCOdt/Bq/aZNhBC7wsz+gl3
	fowluYQKnUAx4sCbQnViy5HmTBONFPFbr1HEENl3i2dVtVHm210e81evPZ7ZsXZpeQ14
	0xG3TlMi1x+3sLUWUV9X830iePWso/C1msdPutRYjmG099qsfCO7B+ShUMOBELqOEEmX
	qk0pfWxQE0p+xikH+BRbpI+wiWlwGLIZjdHjHmps940tau0Q7o0KZgIHoXNRT1RGoUdh
	XJDvAM2JQDquqrJPR9w0ZN/O479mxv+81QAaOkT0gX2pQrBfpOereCVCVv1VeOPWvOYp
	OYwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to;
	bh=xFRemSese1T3cQvlB16guJF9yltDCqIDiS1Yzof/xO4=;
	b=X6yDMiZUj6Wo6HFfrAQkBIinJrl3hKIGaI/ZckURH+wORdwLCHF7nStr0JicOdjrqd
	LZFc00spK0CqLtAPM5AlVbymB6hoSz8DLn2xYMBa2Bwqc7A7WcYu804hcDKIBMiRPxkC
	xc1gzs8JWTQEYnFmb2A/jn+psp57pUia927zvkK2mhcIOV8HmJXwW+LQ3oJIHCTnUIow
	UI06h64/sKkl9uyIm0dRNj+upHz2mMxn/TqbWcJNv8VA1b6ZmFj1qlQEEiQe6l/HviJB
	nOJaWS6QIM1kuuOeTnTw6WItIR42MgYTwypp1pN3uBc2y7UTDrsYC+FqB9onWsesVH1V
	jfZw==
X-Gm-Message-State: AODbwcAPlcMtIo8X/NWVNFNElZOwz5FWGl8TJvkhLoRba6Hqq5oiUBA1
	hzrn9lm6BKdR3YpzjIuezQ==
X-Received: by 10.98.204.130 with SMTP id j2mr28350885pfk.107.1496211480894;
	Tue, 30 May 2017 23:18:00 -0700 (PDT)
Received: from ?IPv6:2601:600:a080:16bb:f4b7:8d27:cdfa:1b18?
	([2601:600:a080:16bb:f4b7:8d27:cdfa:1b18])
	by smtp.gmail.com with ESMTPSA id
	204sm22830271pfu.19.2017.05.30.23.17.59
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 30 May 2017 23:18:00 -0700 (PDT)
To: Anthony Towns <aj@erisian.com.au>, bitcoin-dev@lists.linuxfoundation.org, 
	Libbitcoin Development <libbitcoin@lists.dyne.org>
References: <D0299438-E848-4696-B323-8D0E810AE491@gmail.com>
	<CAFmyj8zNkPj3my3CLzkXdpJ1xkD0GQk8ODg09qYnnj_ONGUtsQ@mail.gmail.com>
	<2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com>
	<20170527063726.GA12042@erisian.com.au>
	<f25dee23-4e92-d464-9fec-20d0c54c573b@voskuil.org>
	<20170529111914.GA21581@erisian.com.au>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <ae8c6944-1af4-5ea8-a2a4-a18d0967302e@voskuil.org>
Date: Tue, 30 May 2017 23:17:59 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
	Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <20170529111914.GA21581@erisian.com.au>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="aAo2kr7UcK8lv8atWigsPHffC8fK2wr1o"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 31 May 2017 07:04:26 +0000
Subject: Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial
 mitigation of CVE-2017-9230
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, 31 May 2017 06:18:02 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--aAo2kr7UcK8lv8atWigsPHffC8fK2wr1o
Content-Type: multipart/mixed; boundary="E92SqBTcXQCgFsKjsI41uHR1DOlmWlkFW";
 protected-headers="v1"
From: Eric Voskuil <eric@voskuil.org>
To: Anthony Towns <aj@erisian.com.au>, bitcoin-dev@lists.linuxfoundation.org,
 Libbitcoin Development <libbitcoin@lists.dyne.org>
Message-ID: <ae8c6944-1af4-5ea8-a2a4-a18d0967302e@voskuil.org>
Subject: Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial
 mitigation of CVE-2017-9230
References: <D0299438-E848-4696-B323-8D0E810AE491@gmail.com>
 <CAFmyj8zNkPj3my3CLzkXdpJ1xkD0GQk8ODg09qYnnj_ONGUtsQ@mail.gmail.com>
 <2E6BB6FA-65FF-497F-8AEA-4CC8655BAE69@gmail.com>
 <20170527063726.GA12042@erisian.com.au>
 <f25dee23-4e92-d464-9fec-20d0c54c573b@voskuil.org>
 <20170529111914.GA21581@erisian.com.au>
In-Reply-To: <20170529111914.GA21581@erisian.com.au>

--E92SqBTcXQCgFsKjsI41uHR1DOlmWlkFW
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 05/29/2017 04:19 AM, Anthony Towns wrote:
> On Sat, May 27, 2017 at 01:07:58PM -0700, Eric Voskuil via bitcoin-dev =
wrote:
>> Anthony,
>> For the sake of argument:
>=20
> (That seems like the cue to move any further responses to bitcoin-discu=
ss)

I didn't meant to imply that the point was academic, just to ask your
indulgence before making my point. Thanks for the detailed and
thoughtful reply.

>> (1) What would the situation look like if there was no patent?
>=20
> If there were no patent, and it were easy enough to implement it, then
> everyone would use it. So blocking ASICBoost would decrease everyone's
> hashrate by the same amount, and you'd just have a single retarget peri=
od
> with everyone earning a little less, and then everyone would be back to=

> making the same profit.
>...

I don't accept that the ease (absolute cost) of implementing the
ASICBOOST optimization is relevant. The cost of implementation is offset
by its returns. Given that people are presumed to be using it profitably
I consider this point settled.

The important point is that if people widely use the optimization, it
does not constitute any risk whatsoever.

>> (2) Would the same essential formulation exist if there had been a
>> patent on bitcoin mining ASICs in general?
>=20
> Not really; for the formulation to apply you'd have to have some way
> to block ASIC use via consensus rules, in a way that doesn't just block=

> ASICs completely, but just removes their advantage, ie makes them perfo=
rm
> comparably to GPUs/FPGAs or whatever everyone else is using.
>...

I realize that the term "same essential formulation" was misleading, but
my aim was the *source* of harm (unblocked) in an ASIC patent as
compared to an ASICBOOST patent. It seems that you agree that this harm
in both cases results from the patent, not the optimization.

Nobody is suggesting that ASICs are a problem despite the significant
optimization. It is worth considering an alternate history where ASIC
mining had been patented, given that blocking it would not have been an
option. More on this below.

I agree that the optimizations differ in that there is no known way to
block the ASIC advantage, except for all people to use it. But correctly
attributing the source of harm is critical to useful threat modeling. As
the ASIC example is meant to show, it is very possible that an
unblockable patent advantage can arise in the future.

>> (3) Would an unforeseen future patented mining optimization exhibit
>> the same characteristics?
>=20
> Maybe? It depends on whether the optimisation's use (or lack thereof)
> can be detected (enforced) via consensus rules. If you've got a patent
> on a 10nm process, and you build a bitcoin ASIC with it, there's no way=

> to stop you via consensus rules that I can think of.

Quite clearly then there is a possibility (if not a certainty) that
Bitcoin will eventually be faced with an unblockable mining patent
advantage.

>> (4) Given that patent is a state grant of monopoly privilege, could a
>> state licensing regime for miners, applied in the same scope as a
>> patent, but absent any patent, have the same effect?
>=20
> I don't think that scenario's any different from charging miners income=

> tax, is it? If you don't pay the licensing fee / income tax, you get pu=
t
> out of business; if you do, you have less profit. There's no way to blo=
ck
> either via consensus mechanisms, at least in general...

Precisely. This is a proper generalization of the threats above. A
patent is a state grant of monopoly privilege. The state's agent (patent
holder) extracts licensing fees from miners. The state does this for its
own perceived benefit (social, economic or otherwise). Extracting money
in exchange for permission to use an optimization is a tax on the
optimization.

> I think it's the case that any optional technology with license fees ca=
n't
> be made available to all miners on equal terms...

This is an important point. Consider also that a subsidy has the same
effect as a tax. A disproportionate tax on competing miners amounts to a
subsidy. A disproportionate subsidy amounts to a tax on competitors.

If the state wants to put its finger on the scale it can do so in either
direction. It can compel licensing fees from miners with no need for a
patent. It can also subsidize mining via subsidized energy costs (for
example), intentionally or otherwise.

> Sadly, the solution to this argument is to use discriminatory terms,
> either not offering the technology to everyone, or offering varying fee=
s
> for miners with different hashrates...

That sounds more like a central authority than a solution.

So, my point:

Mis-attributing the threat is not helpful. This is not an issue of an
unforeseen bug, security vulnerability, bad miners, or evil
patent-holders. This is one narrow example of the general, foreseen,
primary threat to Bitcoin - or any hard money.

Bitcoin's sole defense is decentralization. People parrot this idea
without considering the implication. How does decentralization work? It
works by broadly spreading the risk of state attack. But this implies
that some people are actually taking the risk.

By analogy, BitTorrent is estimated to have 250 million active users in
a month, and 200,000 have been sued in the US since 2010.
Decentralization works because it reduces risk through risk-sharing.

Bitcoin cannot generally prevent state patent/licensing/tax regimes.
Licensing is a ban that is lifted in exchange for payment. What is the
Bitcoin solution to a global ban on mining? On wallets? On exchange?

The Bitcoin defense against a patent is to ignore the patent. Berating
people for doing so seems entirely counterproductive.

e


--E92SqBTcXQCgFsKjsI41uHR1DOlmWlkFW--

--aAo2kr7UcK8lv8atWigsPHffC8fK2wr1o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJZLmAXAAoJEDzYwH8LXOFOUzEH/30lE3qVOOiY0esZ1ytlBY0G
Z/hSIwdskUYpvmwL2OMExWHCPaN4qRs7XJShi+1pb4Xr3iVL5BeKx0maEScKX7Qr
dyP8xqtuwkpn53lsnCyGGXC1/SYtPddLwbab/ayI1WlAVFx4kyMoNU3oWX9MV0iZ
uJ2kVoJFTuZ8LGg/HoZqdGe5aIVJAMHyt+rKC7Z6gfnKTxV/gnRSDXphaVIk92Vd
EeHBj8HKPgsjIQclspUeT1JVlNICIVeIqVsZs4j5SSHtmE8TyqUcmgsktYC9Nm8J
+NEIFDAGE36/Uli0yGwMZvB6CwW6BY1t9FQwqmf2nW1yEE4MNz5ckG61YjSZIc8=
=9HAE
-----END PGP SIGNATURE-----

--aAo2kr7UcK8lv8atWigsPHffC8fK2wr1o--