summaryrefslogtreecommitdiff
path: root/7f/e2066f18a7eb451bfc4397390ac2033999557a
blob: 0b83b13b73a2aebe48065bda766de89c7c2abaa3 (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
Return-Path: <zachgrw@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C8C78C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 10:16:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id A42A040246
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 10:16:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, 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_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 1m3M5BDkG66s
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 10:16:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com
 [IPv6:2607:f8b0:4864:20::d2c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 4EA05400CD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 10:16:13 +0000 (UTC)
Received: by mail-io1-xd2c.google.com with SMTP id r4so8122559iol.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 May 2021 03:16:13 -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
 :cc; bh=i0owgmqjx++N3lAofrgVXvKvHyG2oB4Vs6Br9kG7Tjc=;
 b=GucokXm+lUWvx8I8Uxf6wL/60d6gmawbNf+UVwfOmTrCxg7LhoeSjlqkGAQl6DCPn0
 tAGa5Yno5C4ijJ60SNWtq5MJzPlLUIseXm79P9mWQatwA1M9jA698+XkM8sw6EkHi3+A
 gKFJlMFXNt17dTsEB+WDbM1KXdFoLuUt3gGjDfZKy5l/gLD8bvvm06uSPG2xqhWRTrIg
 5UCYVdiojwwxAMI70ApxzdIZz+WqxbSl/mQGUHv4QoNOMnnR9aKQLudCKZOqnH0fHDZF
 V6Z0LEogBRM3DQSOzeuY5wVrV7ObUZGAyAJ12NcwTrNeMofi7yhYMUKJd6aAuQguFElj
 CctA==
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:cc;
 bh=i0owgmqjx++N3lAofrgVXvKvHyG2oB4Vs6Br9kG7Tjc=;
 b=NUSeEqikbJlyDw1pYCN9Ggy7ZwvP3oKEalFuA132HXnXh6/c0UV+yxBozYxMpm6ps0
 dst4Eu1uXX8CGjQEhTbGRxULw6LmnAwtXQwKlTZomQD0/4YDoqqXmo9O4A4vTQghVoCd
 ManbuEAu1ieKSPiHW5S5bmRXmhaQgeOyFujOzyrp5nvl77lSqKSgKdnY+MHla84iEwJt
 08lsjf6ZAIX/gVm7V45A1+XADaZ5/UMpY5ZWeNuwbJgMvC2X+1MSk8t7nJYqemxJFNR+
 xFDAQjYXjkutC9xQaFdT1OInZTstNE7JAgBqqokrT47U16H0fKNxJNdb3jfNh+ypOqhN
 ZQtw==
X-Gm-Message-State: AOAM531UnVcuKggIId3TtkHZMV3+KWNScHmUcVMeXrAzgt1PdE9FNlI8
 ++TETSWN3kCJtnd0B4Y0RHb/U/EiQLOBrmn+vjjQZXnv
X-Google-Smtp-Source: ABdhPJxskc2g2PJS68HQvZtTAmuoDEc8+qrsvg41tyBuzOVKdSxTeWUdNkd2PCAb7eU8HQ0/mfknwIrp/K3aGmTC4RA=
X-Received: by 2002:a05:6602:14c8:: with SMTP id
 b8mr263322iow.209.1621332972547; 
 Tue, 18 May 2021 03:16:12 -0700 (PDT)
MIME-Version: 1.0
References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com>
 <CAJowKg+QM94g+JcC-E-NGD4J9-nXHWt5kBw14bXTAWaqZz=bYw@mail.gmail.com>
 <CALeFGL02d9NVp+yobrtc2g6k2nBjBj0Qb==3Ukkbi8C_zb5qMg@mail.gmail.com>
 <CAD5xwhi1G3Jj3FAAWQP3BXTK34ugDQY32hq-cQnt8Ny8JP4eGQ@mail.gmail.com>
 <CAJowKgJ1x5YKWS1S-sgdU3Tn+hPT64iiUCwG8qh-JS0xqS7ieA@mail.gmail.com>
 <30li5MRxkBhzLxLmzRnHkCdn8n3Feqegi-FLZ5VDyIX2uRJfq4kVtrsLxw6dUtsM1atYV25IfIfDaQp4s2Dn2vc8LvYkhbAsn0v_Fwjerpw=@protonmail.com>
In-Reply-To: <30li5MRxkBhzLxLmzRnHkCdn8n3Feqegi-FLZ5VDyIX2uRJfq4kVtrsLxw6dUtsM1atYV25IfIfDaQp4s2Dn2vc8LvYkhbAsn0v_Fwjerpw=@protonmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Tue, 18 May 2021 12:16:01 +0200
Message-ID: <CAJ4-pEBYJNuNMUCt5J5DbKU4RC9JXcO7gZdKh2Vq6PHCmddaeg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000e4334f05c297ffbe"
X-Mailman-Approved-At: Tue, 18 May 2021 10:25:18 +0000
Cc: SatoshiSingh <SatoshiSingh@protonmail.com>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
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 10:16:14 -0000

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

VDFs might enable more constant block times, for instance by having a
two-step PoW:

1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to
difficulty adjustments similar to the as-is). As per the property of VDFs,
miners are able show proof of work.

2. Use current PoW mechanism with lower difficulty so finding a block takes
1 minute on average, again subject to as-is difficulty adjustments.

As a result, variation in block times will be greatly reduced.

Zac


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

> Good morning Erik,
>
> > Verifiable Delay Functions involve active participation of a single
> > verifier. Without this a VDF decays into a proof-of-work (multiple
> > verifiers === parallelism).
> >
> > The verifier, in this case is "the bitcoin network" taken as a whole.
> > I think it is reasonable to consider that some difficult-to-game
> > property of the last N blocks (like the hash of the last 100
> > block-id's or whatever), could be the verification input.
> >
> > The VDF gets calculated by every eligible proof-of-burn miner, and
> > then this is used to prevent a timing issue.
> >
> > Seems reasonable to me, but I haven't looked too far into the
> > requirements of VDF's
> >
> > nice summary for anyone who is interested:
> > https://medium.com/@djrtwo/vdfs-are-not-proof-of-work-91ba3bec2bf4
> >
> > While VDF's almost always lead to a "cpu-speed monopoly", this would
> > only be helpful for block latency in a proof-of-burn chain. Block
> > height would be calculated by eligible-miner-burned-coins, so the
> > monopoly could be easily avoided.
>
> Interesting link.
>
> However, I would like to point out that the *real* reason that PoW
> consumes lots of power is ***NOT***:
>
> * Proof-of-work is parallelizable, so it allows miners consume more energy
> (by buying more grinders) in order to get more blocks than their
> competitors.
>
> The *real* reason is:
>
> * Proof-of-work allows miners to consume more energy in order to get more
> blocks than their competitors.
>
> VDFs attempt to sidestep that by removing parallelism.
> However, there are ways to increase *sequential* speed, such as:
>
> * Overclocking.
>   * This shortens lifetime, so you can spend more energy (on building new
> miners) in order to get more blocks than your competitors.
> * Lower temperatures.
>   * This requires refrigeration/cooling, so you can spend more energy (on
> the refrigeration process) in order to get more blocks than your
> competitors.
>
> I am certain people with gaming rigs can point out more ways to improve
> sequential speed, as necessary to get more frames per second.
>
> Given the above, I think VDFs will still fail at their intended task.
> Speed, yo.
>
> Thus, VDFs do not serve as a sufficient deterrent away from
> ever-increasing energy consumption --- it just moves the energy consumption
> increase away from the obvious (parallelism) to the
> obscure-if-you-have-no-gamer-buds.
>
> You humans just need to get up to Kardashev 1.0, stat.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">VDFs might enable more constant block times, for instance=
 by having a two-step PoW:</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to d=
ifficulty adjustments similar to the as-is). As per the property of VDFs, m=
iners are able show proof of work.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">2. Use current PoW mechanism with lower difficulty so finding a =
block takes 1 minute on average, again subject to as-is difficulty adjustme=
nts.</div><div dir=3D"auto"><br></div><div dir=3D"auto">As a result, variat=
ion in block times will be greatly reduced.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Zac</div><div dir=3D"auto"><br></div><div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 18 May 2021=
 at 09:07, ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-lef=
t-color:rgb(204,204,204)">Good morning Erik,<br>
<br>
&gt; Verifiable Delay Functions involve active participation of a single<br=
>
&gt; verifier. Without this a VDF decays into a proof-of-work (multiple<br>
&gt; verifiers =3D=3D=3D parallelism).<br>
&gt;<br>
&gt; The verifier, in this case is &quot;the bitcoin network&quot; taken as=
 a whole.<br>
&gt; I think it is reasonable to consider that some difficult-to-game<br>
&gt; property of the last N blocks (like the hash of the last 100<br>
&gt; block-id&#39;s or whatever), could be the verification input.<br>
&gt;<br>
&gt; The VDF gets calculated by every eligible proof-of-burn miner, and<br>
&gt; then this is used to prevent a timing issue.<br>
&gt;<br>
&gt; Seems reasonable to me, but I haven&#39;t looked too far into the<br>
&gt; requirements of VDF&#39;s<br>
&gt;<br>
&gt; nice summary for anyone who is interested:<br>
&gt; <a href=3D"https://medium.com/@djrtwo/vdfs-are-not-proof-of-work-91ba3=
bec2bf4" rel=3D"noreferrer" target=3D"_blank">https://medium.com/@djrtwo/vd=
fs-are-not-proof-of-work-91ba3bec2bf4</a><br>
&gt;<br>
&gt; While VDF&#39;s almost always lead to a &quot;cpu-speed monopoly&quot;=
, this would<br>
&gt; only be helpful for block latency in a proof-of-burn chain. Block<br>
&gt; height would be calculated by eligible-miner-burned-coins, so the<br>
&gt; monopoly could be easily avoided.<br>
<br>
Interesting link.<br>
<br>
However, I would like to point out that the *real* reason that PoW consumes=
 lots of power is ***NOT***:<br>
<br>
* Proof-of-work is parallelizable, so it allows miners consume more energy =
(by buying more grinders) in order to get more blocks than their competitor=
s.<br>
<br>
The *real* reason is:<br>
<br>
* Proof-of-work allows miners to consume more energy in order to get more b=
locks than their competitors.<br>
<br>
VDFs attempt to sidestep that by removing parallelism.<br>
However, there are ways to increase *sequential* speed, such as:<br>
<br>
* Overclocking.<br>
=C2=A0 * This shortens lifetime, so you can spend more energy (on building =
new miners) in order to get more blocks than your competitors.<br>
* Lower temperatures.<br>
=C2=A0 * This requires refrigeration/cooling, so you can spend more energy =
(on the refrigeration process) in order to get more blocks than your compet=
itors.<br>
<br>
I am certain people with gaming rigs can point out more ways to improve seq=
uential speed, as necessary to get more frames per second.<br>
<br>
Given the above, I think VDFs will still fail at their intended task.<br>
Speed, yo.<br>
<br>
Thus, VDFs do not serve as a sufficient deterrent away from ever-increasing=
 energy consumption --- it just moves the energy consumption increase away =
from the obvious (parallelism) to the obscure-if-you-have-no-gamer-buds.<br=
>
<br>
You humans just need to get up to Kardashev 1.0, stat.<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></div>

--000000000000e4334f05c297ffbe--