public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Anthony Towns <aj@erisian.com.au>,
	bitcoin-dev@lists.linuxfoundation.org,
	 Libbitcoin Development <libbitcoin@lists.dyne.org>
Subject: Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
Date: Tue, 30 May 2017 23:17:59 -0700	[thread overview]
Message-ID: <ae8c6944-1af4-5ea8-a2a4-a18d0967302e@voskuil.org> (raw)
In-Reply-To: <20170529111914.GA21581@erisian.com.au>


[-- Attachment #1.1: Type: text/plain, Size: 5811 bytes --]

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:
> 
> (That seems like the cue to move any further responses to bitcoin-discuss)

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?
> 
> 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 period
> 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?
> 
> 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 perform
> 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?
> 
> 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?
> 
> 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 put
> out of business; if you do, you have less profit. There's no way to block
> 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 can'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 fees
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

      reply	other threads:[~2017-05-31  6:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26  6:30 [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230 Cameron Garnham
2017-05-26  6:52 ` Andreas M. Antonopoulos
2017-05-26  8:02   ` Cameron Garnham
2017-05-26  8:15     ` Eric Voskuil
2017-05-26 19:20       ` Cameron Garnham
2017-05-26  9:21     ` Tom Zander
2017-05-26 14:39       ` Erik Aronesty
2017-05-26 14:54         ` Tom Zander
2017-05-27  6:37     ` Anthony Towns
2017-05-27 20:07       ` Eric Voskuil
2017-05-29 11:19         ` Anthony Towns
2017-05-31  6:17           ` Eric Voskuil [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae8c6944-1af4-5ea8-a2a4-a18d0967302e@voskuil.org \
    --to=eric@voskuil.org \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=libbitcoin@lists.dyne.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox