Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

[Anthony Towns <aj@erisian.com.au>]

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)

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

But even without a patent, entry costs might be high (redesigning an
ASIC, making software that shuffles transactions so you can use the
ASIC's features) and how that works out seems hard to analyse...

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

Reportedly, ASICBoost is an option you can turn on or off on some mining
hardware, so this seems valid (I'm assuming not using the option either
increases your electricity use by ~20% due to activating extra circuitry,
or decreases your hashrate by ~20% and maybe also decreases your
electricity use by less than that by not activating some circuitry); but
"being an ASIC" isn't something you can turn off and on in that manner.

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

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

I think it's the case that any optional technology with license fees can't
be made available to all miners on equal terms, though, provided there is
any way for it to be blocked via consensus mechanisms. If it were, the
choice would be:

 my percentage of the hashrate is h (0<h, h much less than 1), total
 hashrate is 1=100%, licensing fee is uniform per hashrate, so h*X,
 advantage of using technology is a factor of r (0<r, r*h much less
 than 1)

 - technology allowed, I use it:
     I make r*h but pay X*h, so revenue is proportional to (r-X)*h
 - technology allowed, I don't use it:
     I make h, pay nothing, so revenue is proportional to h

 Provides the licensor sets X<r, of these choices I always chose to use
 the technology, and so does everyone else. So base hashrate if no one
 were to use the technology is H=1/r.

 - technology not allowed, no one uses it:
     I make h blocks, but total hashrate is 1/r, so revenue is proportional
     to h/(1/r)=rh

 But rh>(r-X)*h provided X>0, so all miners are better off if the
 technology is not allowed (because they all suffer equally in loss of
 hashrate, which is cancelled out in a retarget period; and they all
 benefit equally by not having to pay licensing fees).

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. Unless somehow it works to make it
more expensive for higher hashrate miners, this makes decentralisation
worse.

Cheers,
aj