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
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 11EECC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 May 2020 07:58:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id EECF586D95
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 May 2020 07:58:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id lqUysTFNVDsZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 May 2020 07:58:25 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by whitealder.osuosl.org (Postfix) with ESMTPS id 06D8586D81
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 May 2020 07:58:25 +0000 (UTC)
Date: Mon, 25 May 2020 07:58:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1590393502;
bh=mDtZFhRFNqdk1Sq87AhvLJOOYLEux9qqC0+ZhDzzLto=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=vSPUadQx7QhuzMJ3mWmNcgHS+oWdQ5hKETqM5qmlj7/ayBZy3b/ZDwF1nWBT2GHGI
nHa1TaBuP+4qdf2JPjKSSkGGYhEF1cYUJx+DfvR0MpVKAyuBrvpiFGTRFob4eQ+Q/H
U3rvfjnP2pmvStVnXLjrV8+KQr6Mw96qA/9NLkQA=
To: Karl <gmkarl@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <cR1ZDwP76-IljeSxpbx7WNI5t_d0eIbRTnUO8z3h7fQLJzAYVG_D427p_1NWfrJtWfyyBwnzjzgZClUCeZrZWg9ZNTbZKzmfuHHSO7D-9tA=@protonmail.com>
In-Reply-To: <CALL-=e6J4QFjdbC=caux=TAHjveKaehnGfdyeEdEhgniSp7PYA@mail.gmail.com>
References: <mailman.2587.1590231461.32591.bitcoin-dev@lists.linuxfoundation.org>
<CALL-=e4Eg=iRbZOV+SAzn3_NhZrS-QviDgZdSmxLQTLvoMduPw@mail.gmail.com>
<k4J1fJMk2ySTLdlj8RgYxgb4_U3gtRH65Au5FLsCsVZPiEBRKU1cqy_S--2IxiRUGI1-5P1SMZkxnwlBf8YJ8ZQM_AM7jeuA6Y6dpT9jwi0=@protonmail.com>
<CALL-=e6_hrT9W2j73==cyX4Q=yt+guJn7RSgW1quA4JAgjD42w@mail.gmail.com>
<WqvuQWsFg50edn9nmk0DRcTsEZr__CFaQd9T3bw3b7CffGDjwXsVApzZvnsNdmeLQDrFKDMFgb5QDzHVhOhudGfu3HlvQKyR-9luPI-YCbs=@protonmail.com>
<CALL-=e6J4QFjdbC=caux=TAHjveKaehnGfdyeEdEhgniSp7PYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] hashcash-newhash
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 25 May 2020 07:58:28 -0000
Good morning Kari,
> > > You mention ASICs becoming commoditized.=C2=A0 I'd remind you that ev=
entually there will be a public mathematical breaking of the algorithm, at =
which point all ASICs will become obsolete regardless.=C2=A0 Would you agre=
e it would be better to prepare for this by planning algorithm change?
> >
> > Possibly, but then the reason for change is no longer to promote decent=
ralization, would it?
>
> > It helps to be clear about what your goals are, because any chosen solu=
tion might not be the best way to fix it.
> > I admit that, if the problem were to be avoid the inevitable obsoletion=
of SHA-2, then this is the only solution, but that is not the problem you =
stated you were trying to solve in the first place.
>
> To be up front, the reason for decentralization is due to concern around =
the security of the hashing.=C2=A0 Having a public breakage of the function=
simply makes the urgency obvious.
Now that I have thought about it more: again, the important thing about the=
proof-of-work technique is not so much the algorithm itself, only that exe=
cuting it requires energy.
And all algorithms require energy in order to execute.
Even if some technique is found which partially breaks the hash function an=
d allows faster generation of hashes for the amount of energy consumed, thi=
s is not a problem for mining itself: the difficulty adjusts and mining con=
tinues.
The execution of this technique is unlikely to require no computation, only=
reduced computational effort; and all that is needed is *some* measure of =
computational effort done, the *scale* of that measure is not really materi=
al for the purpose of ordering atomic transactional updates to the UTXO set=
.
Of course, things like the Merkle tree and txids and so on would need chang=
ing in case of even a partial break of the hash function, which would requi=
re a hardfork to survive; you might as well change the proof-of-work functi=
on as well then.
>
> Reddit claims two entities controlled 62% of the hashrate recently:=C2=
=A0https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_h=
ours_bitcoins_nakamoto/ .=C2=A0 Compromising the systems of these two group=
s seems like it is all that is needed to compromise the entire blockchain (=
to the limited degree a 51% attack does).
You seem to be equating "break of the hash function" with "centralization o=
f hashrate", which I do not quite agree with.
Most human beings cannot think without constant communication with other hu=
man beings.
Thus, it is unlikely that a private break of the hash function is possible.
Instead, a break of the hash function is likely to be discovered in various=
ways by multiple human beings who have been communicating with each other.
Even historically, inventions never arose fully-formed from the head of the=
inventor, like Athena from the brow of Zeus; every invention has predecess=
ors, successors, and peers in the inhabited milieu.
Instead, you can look up the costs of local electricity globally, and notic=
e where those entities have their largest mines geographically located.
>
> Hence I see decentralization and cryptanalysis of the algorithm to be rou=
ghly similar security concerns.
>
> It sounds like you agree that a change of algorithm is needed before the =
current one is publicly broken.
>
> > > You mention many coordinated hardforks.=C2=A0 Would you agree that if=
we came up with a way of programmatically cycling the algorithm, that only=
one hardfork work be needed?=C2=A0 For example one could ask nodes to cons=
ent to new algorithm code written in a simple scripting language, and rejec=
t old ones slowly enough to provide for new research.
> >
> > Even *with* a scripting language, the issue is still what code written =
in that language is accepted, and *how*.
> >
> > Do miners vote on a new script describing the new hashing algorithm?
> > What would their incentive be to obsolete their existing hardware?
> > (using proof-of-work to lock in a hashing change feels very much like a=
chicken-and-egg problem: the censorship-resistance provided by Bitcoin is =
based on evicting any censors by overpowering their hashpower, but requires=
some method of measuring that hashpower: it seems unlikely that you can sa=
fely change the way hashpower is measured via a hashpower election)
> >
> > Do nodes install particular scripts and impose a switchover schedule of=
some sort?
> > Then how is that different from a hardfork, especially for nodes that d=
o not update?
> > (notice that softforks allow nodes to remain non-updated, at degraded s=
ecurity, but still in sync with the rest of the network and capable of tran=
sacting with them)
>
> I'm expressing that in considering this we have two options: repeated har=
d forks or making repeated change a part of the protocol.=C2=A0 There are m=
any ways to approach or implement it.=C2=A0 It sounds like you're noting th=
at the second option takes some work and care?
>
> Would it be helpful if I outlined more ideas that address your concerns?=
=C2=A0 I want to make sure the idea of changing the algorithm is acceptable=
at all first.
Go ahead.
>
> > > You mention the cost of power as the major factor influencing decentr=
alized mining.=C2=A0 Would you agree that access to hardware that can do th=
e mining is an equally large factor?=C2=A0 Even without ASICs you would nee=
d the physical cycles.=C2=A0 Including this factor helps us discuss the sam=
e set of expected situations.
> >
> > No, because anyone who is capable of selling hardware, or the expertise=
to design and build it, can earn by taking advantage of their particular e=
xpertise.
> >
> > Generally, such experts can saturate the locally-available energy sourc=
es, until local capacity has been saturated, and they can earn even more by=
selling extra hardware to entities located at other energy sources whose l=
ocal capacities are not still underutilized, or expanding themselves to tho=
se sources.
> > Other entities might be in better position to take advantage of particu=
lar local details, and it may be more lucrative for the expert-at-building-=
hardware to just sell the hardware to them than to attempt to expand in pla=
ces where they have little local expertise.
>
> It sounds like you are saying that the supply of electricity is exhausted=
and the supply of hardware is not.
>
> Is that correct?
Given that electricity is consumed very quickly, and hardware takes a long =
time to truly consume or obsolete, yes: rate of consumption of electricity =
is expected to dominate compared to the rate of consumption of hardware.
>
> I've seen that most of the time mining hardware distributors are sold out=
of their top-of-the-line mining equipment, mostly selling in preorders.=
=C2=A0 Are implying most of the mining is done by privately built equipment=
?
It seems the most lucrative thing to do, that if you have a new generation =
of hardware, to mine with them yourself, until the price of local electrici=
ty has increased due to your consumption, and it becomes more lucrative to =
sell the hardware to other potential miners who now have lower electricity =
prices compared to yours (because you have been saturating the local electr=
icity supply with your own mining operations and causing the local prices t=
o rise up, or equivalently, until some governmental or other limits your us=
able electricity supply, which is equivalent to saying that the price of ev=
en more electricity would be your incarceration or other punishment, which =
might be too expensive for you to pay, thus selling the hardware is more lu=
crative).
I have no evidence to back this, thus it is not a claim to truth, only a cl=
aim to economic logic, if we assume that mining hardware manufacturers are =
economically rational, are interested only in the selfish gain of economic =
power, etc. etc.
Real human beings and the entities they build may not behave in such a perf=
ectly rational manner, or I may be assuming details that are not accurate t=
o reality.
>
> Would you agree that an increase in the price of bitcoin would make the a=
vailability of hardware matter much more, because the price of electricity =
would matter much less?
Electricity is a factor with every piece of hardware that is utilized, so a=
ny increase in hardware will also have an increase in electricity consumed.
So I expect that the materiality of the price of electricity will increase =
in lockstep with the materiality of the price of hardware (note that price =
is simply demand over supply, and supply is the availability of hardware).
You could also analyze the transient economic behaviors here, specifically =
that an increase in Bitcoin price makes it more lucrative to mine in more p=
laces, which would start to put in orders for more hardware, and the hardwa=
re will take time to deliver, so the price at those places will increase on=
ly after a long while, etc.
But those are transient changes, and by the time any change at the software=
level is coordinated, the transient economic behaviors may have resettled =
to the expected long-term behavior: humans operate at around the same avera=
ge speed in many different fields.
>
> Something to raise here is that all of these things take time and respond=
in ebbs and flows.=C2=A0 If there were to be a plan to migrate to a new al=
gorithm, it would be participating in those ebbs and flows.
The usual engineering response is to create buffers to be resilient against=
ebbs and flows.
Note how we prefer to dam water supplies (i.e. create a buffer) rather than=
adjust our water consumption dynamically according to the ebb and flow of =
the water supply.
Similarly, economic contracts like futures and options are economic buffers=
against the ebb and flow of local supply of various materials.
Within Bitcoin, my understanding is that the difficulty adjustment system a=
cts as a buffer against transient ebbs and flows of the supply of hashpower=
.
> It takes time to build new hardware, and it takes time for the difficulty=
to adjust to obsolete it.=C2=A0 What do you see as influencing how fast ha=
rdware becomes obsolete?
In the long run?
We will run out of ideas of how to improve the implementation of the hashin=
g function, and there will be only a few designs that implement all the kno=
wn ideas for optimizing the implementation.
Then hardware becomes obsolete from normal wear and tear, e.g. electromigra=
tion, and that takes years to take effect.
>
> I ask these questions because the answers relate to how what ways would b=
e good to change the mining function to increase decentralization.
>
> > And expertise is easy to copy, it is only the initial expertise that is=
hard to create in the first place, once knowledge is written down it can b=
e copied.
>
> Also takes measurable months to do.
But can be massively parallelized, you can have a teacher or mentor teachin=
g an entire classroom of students, and created lectures can be stored and r=
e-given to many students, in the form of books, videos, etc.
Human beings have been doing this since time immemorial, and possibly befor=
e recorded history, in such things as oral traditions and so on.
>
> > > You describe improving electricity availability in expensive areas as=
a way to improve decentralization.=C2=A0 Honestly this sounds out of place=
to me and I'm sorry if I've upset you by rehashing this old topic.=C2=
=A0 I believe this list is for discussing the design of software, not inter=
national energy infrastructure: what is the relation?=C2=A0 There is a lot =
of power to influence behavior here but I thought the tools present are sof=
tware design.
> >
> > I doubt there is any good software-only solution to the problem; the ph=
ysical world remains the basis of the virtual one, and the virtual utterly =
dependent on the physical, and abstractions are always leaky (any non-toy s=
oftware framework inevitably gains a way to query the operating system the =
application is running under, because abstractions inevitably leak): and en=
ergy, or the lack thereof, is the hardest to abstract away, which is the en=
tire point of using proof-of-work as a reliable, unfakeable (i.e. difficult=
to virtualize) clock in the first place.
> >
> > Still, feel free to try: perhaps you might succeed.
>
> You agreed earlier that changing the algorithm would increase decentraliz=
ation, but expressed other concerns with the idea.=C2=A0 Many more general =
solutions are working in many altcoins.=C2=A0 I'm interested in discussing =
changing the proof of work algorithm in bitcoin.
I did not so agree: in particular, I do not agree with equating a break of =
the proof-of-work algorithm with centralization.
More likely, any centralization seen is due to local government interferenc=
e in economic matters, such as creating a local artificial oversupply of el=
ectricity by paying for electricity generation using taxes.
>
> My motivation is security of the blockchain, which is partially held by d=
ecentralization.
Let us be more precise and avoid the word "security".
Miner decentralization supports censorship-resistance, so your motivation i=
s censorship-resistance (is that correct?).
Ultimately, what really protects censorship-resistance is not the details o=
f the hashing algorithm, it is the economics involved.
In order to evict a censor, hashpower must be brought to bear against the c=
ensor.
And that hashpower has to be bought and paid for.
The mechanism for doing this already exists, and is called the "mining fee"=
(note that the block subsidy does not protect against the censor, as the c=
ensor gets the block reward as well; what the censor cannot get is the fees=
attached to a transaction that the censor does not want published).
Regards,
ZmnSCPxj
|