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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 59C96360
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 May 2017 11:19:26 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 76913106
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 May 2017 11:19:25 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian))
id 1dFIhl-0004Ze-Lh; Mon, 29 May 2017 21:19:23 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Mon, 29 May 2017 21:19:14 +1000
Date: Mon, 29 May 2017 21:19:14 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20170529111914.GA21581@erisian.com.au>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f25dee23-4e92-d464-9fec-20d0c54c573b@voskuil.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 29 May 2017 12:37:32 +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: Mon, 29 May 2017 11:19:26 -0000
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
|
