From: Anthony Towns <aj@erisian•com.au>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230
Date: Mon, 29 May 2017 21:19:14 +1000 [thread overview]
Message-ID: <20170529111914.GA21581@erisian.com.au> (raw)
In-Reply-To: <f25dee23-4e92-d464-9fec-20d0c54c573b@voskuil.org>
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
next prev parent reply other threads:[~2017-05-29 11:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-26 6:30 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 [this message]
2017-05-31 6:17 ` Eric Voskuil
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=20170529111914.GA21581@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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