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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9E70DC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 May 2021 07:06:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 851FE60688
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 May 2021 07:06:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.401
X-Spam-Level:
X-Spam-Status: No, score=0.401 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.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 vqDClR_62M63
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 May 2021 07:06:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by smtp3.osuosl.org (Postfix) with ESMTPS id 9C7C760686
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 May 2021 07:06:32 +0000 (UTC)
Date: Tue, 18 May 2021 07:06:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1621321589;
bh=g1hkq9LcXJHEiQHknvD8YOyiw1a5K0F2BP+IJDPNWpc=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=JhNourn16noX+5N70qXBxp5dUfttq7eJqgO8xg4WJsqQTXtHVbW0iOBB9rJxwvJka
MOd/nG3HC2e35oGKYTdTW1MvxgUlQ86AIiyhWFPwLN0KGKe7gjUC9jfVFj7UizeIpm
q1+hy9P70v8fOhz7fwItHJMdYaJa7XNy7pHIgMzg=
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <30li5MRxkBhzLxLmzRnHkCdn8n3Feqegi-FLZ5VDyIX2uRJfq4kVtrsLxw6dUtsM1atYV25IfIfDaQp4s2Dn2vc8LvYkhbAsn0v_Fwjerpw=@protonmail.com>
In-Reply-To: <CAJowKgJ1x5YKWS1S-sgdU3Tn+hPT64iiUCwG8qh-JS0xqS7ieA@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 07:06:35 -0000
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 =3D=3D=3D 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 competitor=
s.
The *real* reason is:
* Proof-of-work allows miners to consume more energy in order to get more b=
locks 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 m=
iners) in order to get more blocks than your competitors.
* Lower temperatures.
* This requires refrigeration/cooling, so you can spend more energy (on t=
he 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 seq=
uential 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
|
