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"
Subject: Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial
 mitigation of CVE-2017-9230
Precedence: list

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--