summaryrefslogtreecommitdiff
path: root/92/c956939f1c59e99445f3fd0b519dd0a5be5ddd
blob: 9e83960c3313a1544fcdca9ebf21770af5d9811d (plain)
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
Return-Path: <aubergemediale@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9C68DC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 12:46:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 90C9B60861
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 12:46:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id OBKNi2VOJLIE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 12:46:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [IPv6:2a00:1450:4864:20::631])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 2458660670
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 12:46:52 +0000 (UTC)
Received: by mail-ej1-x631.google.com with SMTP id n2so14318081ejy.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 05:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=1EvPccIrTltTBTgipdI52+AaLdH/8YvP8dKEItioE78=;
 b=NrGGy4XX2eEhUq3LbThTB1FQYEW5deSW8Ok7ba0Ss+sMYm8vySSRw4Wo54/lGc0Po7
 K2eK4vq5M7z9+lxUkr+JRj5zFf1nLC3Jf/MiXhssytO8XlHnMFH8I49mq0055fBHSlCq
 pFkdePLw0uAp1UgSprsFMP1RHNS1fST0X+/Ny4hPNsKlYwos3SNCJ9r0MWVfnKYUYChP
 ieG4FKsV9FBoy/f8nUFBUxdsPzL5eTw8VbrhO6og1t+kdK8Nw8FvjOeBgliN5+99NHSR
 zFNhlijf0S4g9Xk93wLON+E2Qj7KS4mF9phK+ibSJQlmqW50ygdRSynvuaJVhSt8ZtAY
 Sfow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=1EvPccIrTltTBTgipdI52+AaLdH/8YvP8dKEItioE78=;
 b=BwDqg7+fLH3k0zIozz7bdPt5J408yUkiVms8+3N7hZNZgLPPPGkIhb+uKdSPXAwrpb
 DB8FQZym5kgTwNgBnJrL6eINjOKQisOZiMuiy/ATxYAAEFb2Z2pQmqXMLa6vg3WQVcvq
 Q2riXUXTCdVcwBu5Nf40zsnd/JuRRDUjAutRp2nBz42r1MmoxStBgLatdV86/UPULDho
 CrORpr7Qb2j8bAslQ2Ct1/5j4OnOsI77FwG4eU8le1cpKVAJzU8gKAbLICcHLz40Qq9P
 +ymQuBtqXAJ2Tk57rzXttztZB/VvZiGW+o/DqppPRV1LoWJdQ1e/QlPel2fZiT9Fg8HL
 FEIA==
X-Gm-Message-State: AOAM532eDFwu/BBix42tIQ/Du/k1eGUvzJRvaylO9PZ0a+Zlz2n0ImIv
 aiQ/e18VYwYr6TD7BManJxe/c592N6Vifdhxp+U=
X-Google-Smtp-Source: ABdhPJwpK/KUTLGAqkXCmm7ofRn7bPM9FfVH3J3SPGiy3sPOr7h5uWlQi7TVbc5uoR3U5hZqoJ+aTTsAG5Acb6bpRsg=
X-Received: by 2002:a17:906:af72:: with SMTP id
 os18mr3045263ejb.327.1621342011342; 
 Tue, 18 May 2021 05:46:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAGFmrSac+Ej1a6da8GcPK1pB_kgowtQk5roaDCVsL9t1zgwEFA@mail.gmail.com>
 <CALeFGL3U2yb2WVz4rwcBqO25kd0B7NcgrN4iMjDyackrTTegpw@mail.gmail.com>
 <ZFVpoVGcwTTpDDlAXLn8cCwic0l40b3DmE_UoKIv4IvmFDDX9W2F1sRHYwido1X7OK0fX1QAx5J8I5DokM4pcIKziNAgAwc6emrHulfbRE8=@protonmail.com>
In-Reply-To: <ZFVpoVGcwTTpDDlAXLn8cCwic0l40b3DmE_UoKIv4IvmFDDX9W2F1sRHYwido1X7OK0fX1QAx5J8I5DokM4pcIKziNAgAwc6emrHulfbRE8=@protonmail.com>
From: Claus Ehrenberg <aubergemediale@gmail.com>
Date: Tue, 18 May 2021 14:46:39 +0200
Message-ID: <CANPykMoM4+3svpUNQBwa8xrsKnEv48FVT1fu0+wpnTB4PXkg4g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a543a305c29a1a8d"
X-Mailman-Approved-At: Tue, 18 May 2021 14:24:16 +0000
Subject: Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
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: Tue, 18 May 2021 12:46:55 -0000

--000000000000a543a305c29a1a8d
Content-Type: text/plain; charset="UTF-8"

> Ultimately all currency security derives from energy consumption.
> Everything eventually resolves down to proof-of-work.
This is ideology. Yes, without energy and work, not many things happen. But
the amounts of energy and work to achieve a goal vary widely. Detailed
analysis comparing one alternative with the other in depth  is required.
And I would not look for order-of-magnitude improvements, 25% better is
also a big deal, if discovered.

> * Proof-of-space simply moves the work to the construction of more
storage devices.
One needs a cost/benefit analysis, not just an account of the cost. For
example, if PoW could do calculations that are otherwise useful (maybe
solve a queue of standardized math-jobs, such as climate simulations) there
would be more benefit, or, let's say the data storage in proof-of-space is
useful.

> * Proof-of-stake simply moves the work to stake-grinding attacks.
Simply not true, there are PoS implementations that are immune to
stake-grinding attacks, and even where not, the possible amount of
computations is limited compared to PoW

> * The optical proof-of-work simply moves the work to the construction of
more miners.
The idea was to shift from energy to cap-ex. We can get a financial penalty
for misbehavior from three sources:
- cost of energy/labor (PoW)
- cost of capital (PoS)
- cost of cap-ex
There might be a better mix than PoW only. I have written code for mixed
PoW/PoS systems and it works. Adding more cap-ex to the mix can make sense,
but the environmental impact needs to be analyzed, it could also make it
worse than just the use of electricity. At least electricity as such does
not leave waste behind. Mining in orbit with solar power would be totally
acceptable.

> At least, proof-of-work is honest about its consumption of resources.
Agreed, but we can't be satisfied with that. If we try hard enough we can
do better.

Cheers
Claus

On Tue, May 18, 2021 at 8:47 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > A few things jump out at me as I read this proposal
> >
> > First, deriving the hardness from capex as opposed to opex switches the
> privilege from those who have cheap electricity to those who have access to
> chip manufacturers/foundries. While this is similarly the case for Bitcoin
> ASICS today, the longevity of the PoW algorithm has led to a better
> distribution of knowledge and capital goods required to create ASICS. The
> creation of a new PoW of any kind, hurts this dimension of decentralization
> as we would have to start over from scratch on the best way to build,
> distribute, and operate these new pieces of hardware at scale. While I have
> not combed over the PoW proposed here in fine detail, the more complicated
> the algorithm is, the more it privileges those with specific knowledge
> about it and the manufacturing process.
> >
> > The competitive nature of Bitcoin mining is such that miners will be
> willing to spend up to their expected mining reward in their operating
> costs to continue to mine. Let's suppose that this new PoW was adopted,
> miners will continue to buy these chips in ever increasing quantities,
> turning the aforementioned CAPEX into a de facto OPEX. This has a few
> consequences. First it just pushes the energy consumption upstream to the
> chip manufacturing process, rather than eliminating it. And it may trade
> some marginal amount of the energy consumption for the set of resources it
> takes to educate and create chip manufacturers. The only way to avoid that
> cost being funneled back into more energy consumption is to make the
> barrier to understanding of the manufacturing process sufficiently
> difficult so as to limit the proliferation of these chips. Again, this
> privileges the chip manufacturers as well as those with close access to the
> chip manufacturers.
> >
> > As far as I can tell, the only thing this proposal actually does is
> create a very lucrative business model for those who sell this variety of
> chips. Any other effects of it are transient, and in all likelihood the
> transient effects create serious centralization pressure.
> >
> > At the end of the day, the energy consumption is foundational to the
> system. The only way to do away with authorities, is to require
> competition. This competition will employ ever more resources until it is
> unprofitable to do so. At the base of all resources of society is energy.
> You get high energy expenditure, or a privileged class of bitcoin
> administrators: pick one. I suspect you'll find the vast majority of
> Bitcoin users to be in the camp of the energy expenditure, since if we pick
> the latter, we might as well just pack it in and give up on the Bitcoin
> experiment.
>
>
> Keagan is quite correct.
> Ultimately all currency security derives from energy consumption.
> Everything eventually resolves down to proof-of-work.
>
> * Proof-of-space simply moves the work to the construction of more storage
> devices.
> * Proof-of-stake simply moves the work to stake-grinding attacks.
> * The optical proof-of-work simply moves the work to the construction of
> more miners.
> * Even government-enforced fiat is ultimately proof-of-work, as the
> operation and continued existence of any government is work.
>
> It is far better to move towards a more *direct* proof-of-work, than to
> add more complexity and come up with something that is just proof-of-work,
> but with the work moved off to somewhere else and with additional moving
> parts that can be jammed or hacked into.
>
> When considering any new proof-of-foo, it is best to consider all effects
> until you reach the base physics of the arrow of time, at which point you
> will realize it is ultimately just another proof-of-work anyway.
>
> At least, proof-of-work is honest about its consumption of resources.
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000a543a305c29a1a8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; Ultimately all currency security derives from energy =
consumption.<br>&gt; Everything eventually resolves down to proof-of-work.<=
br><div>This is ideology. Yes, without energy and work, not many things hap=
pen. But the amounts of energy and work to achieve a goal vary widely. Deta=
iled analysis comparing one alternative with the other in depth=C2=A0 is re=
quired. And I would not look for order-of-magnitude improvements, 25% bette=
r is also a big deal, if discovered.</div><div><br></div><div>&gt; * Proof-=
of-space simply moves the work to the construction of more storage devices.=
</div><div>One needs a cost/benefit analysis, not just an account of the co=
st. For example, if PoW could do calculations that are otherwise useful (ma=
ybe solve a queue of standardized math-jobs, such as climate simulations) t=
here would be more benefit, or, let&#39;s say the data storage in proof-of-=
space is useful.</div><div><br></div><div>&gt; * Proof-of-stake simply move=
s the work to stake-grinding attacks.<br></div><div>Simply not true, there =
are PoS implementations that are immune=C2=A0to stake-grinding attacks, and=
 even where not, the possible amount of computations is limited compared to=
 PoW</div><div><br></div><div>&gt; * The optical proof-of-work simply moves=
 the work to the construction of more miners.<br></div><div>The idea was to=
 shift from energy to cap-ex. We can get a financial=C2=A0penalty for misbe=
havior from three sources:<br>- cost of energy/labor (PoW)</div><div>- cost=
 of capital (PoS)</div><div>- cost of cap-ex</div><div>There might be a bet=
ter mix than PoW only. I have written code for mixed PoW/PoS systems and it=
 works. Adding more cap-ex to the mix can make sense, but the environmental=
 impact needs to be analyzed, it could also make it worse than just the use=
 of electricity. At least electricity as such does not leave waste behind. =
Mining in orbit with solar power would be totally acceptable.</div><div><br=
></div><div>&gt; At least, proof-of-work is honest about its consumption of=
 resources.<br></div><div>Agreed, but we can&#39;t be satisfied with that. =
If we try hard enough we can do better.</div><div><br></div><div>Cheers</di=
v><div>Claus</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Tue, May 18, 2021 at 8:47 AM ZmnSCPxj via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><br>
&gt; A few things jump out at me as I read this proposal<br>
&gt;<br>
&gt; First, deriving the hardness from capex as opposed to opex switches th=
e privilege from those who have cheap electricity to those who have access =
to chip manufacturers/foundries. While this is similarly the case for Bitco=
in ASICS today, the longevity of the PoW algorithm has led to a better dist=
ribution of knowledge and capital goods required to create ASICS. The creat=
ion of a new PoW of any kind, hurts this dimension of decentralization as w=
e would have to start over from scratch on the best way to build, distribut=
e, and operate these new pieces of hardware at scale. While I have not comb=
ed over the PoW proposed here in fine detail, the more complicated the algo=
rithm is, the more it privileges those with specific knowledge about it and=
 the manufacturing process.<br>
&gt;<br>
&gt; The competitive nature of Bitcoin mining is such that miners will be w=
illing to spend up to their expected mining reward in their operating costs=
 to continue to mine. Let&#39;s suppose that this new PoW was adopted, mine=
rs will continue to buy these chips in ever increasing quantities, turning =
the aforementioned CAPEX into a de facto OPEX. This has a few consequences.=
 First it just pushes the energy consumption upstream to the chip manufactu=
ring process, rather than eliminating it. And it may trade some marginal am=
ount of the energy consumption for the set of resources it takes to educate=
 and create chip manufacturers. The only way to avoid that cost being funne=
led back into more energy consumption is to make the barrier to understandi=
ng of the manufacturing process sufficiently difficult so as to limit the p=
roliferation of these chips. Again, this privileges the chip manufacturers =
as well as those with close access to the chip manufacturers.<br>
&gt;<br>
&gt; As far as I can tell, the only thing this proposal actually does is cr=
eate a very lucrative business model for those who sell this variety of chi=
ps. Any other effects of it are transient, and in all likelihood the transi=
ent effects create serious centralization pressure.<br>
&gt;<br>
&gt; At the end of the day, the energy consumption is foundational to the s=
ystem. The only way to do away with authorities, is to require competition.=
 This competition will employ ever more resources until it is unprofitable =
to do so. At the base of all resources of society is energy. You get high e=
nergy expenditure, or a privileged class of bitcoin administrators: pick on=
e. I suspect you&#39;ll find the vast majority of Bitcoin users to be in th=
e camp of the energy expenditure, since if we pick the latter, we might as =
well just pack it in and give up on the Bitcoin experiment.<br>
<br>
<br>
Keagan is quite correct.<br>
Ultimately all currency security derives from energy consumption.<br>
Everything eventually resolves down to proof-of-work.<br>
<br>
* Proof-of-space simply moves the work to the construction of more storage =
devices.<br>
* Proof-of-stake simply moves the work to stake-grinding attacks.<br>
* The optical proof-of-work simply moves the work to the construction of mo=
re miners.<br>
* Even government-enforced fiat is ultimately proof-of-work, as the operati=
on and continued existence of any government is work.<br>
<br>
It is far better to move towards a more *direct* proof-of-work, than to add=
 more complexity and come up with something that is just proof-of-work, but=
 with the work moved off to somewhere else and with additional moving parts=
 that can be jammed or hacked into.<br>
<br>
When considering any new proof-of-foo, it is best to consider all effects u=
ntil you reach the base physics of the arrow of time, at which point you wi=
ll realize it is ultimately just another proof-of-work anyway.<br>
<br>
At least, proof-of-work is honest about its consumption of resources.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000a543a305c29a1a8d--