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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 16C2EC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 May 2021 16:59:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id DB3DF40579
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 May 2021 16:59:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id lYM3YoWwxt8k
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 May 2021 16:59:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com
[IPv6:2607:f8b0:4864:20::52c])
by smtp4.osuosl.org (Postfix) with ESMTPS id C3825402D6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 May 2021 16:59:11 +0000 (UTC)
Received: by mail-pg1-x52c.google.com with SMTP id y32so5048145pga.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 May 2021 09:59:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=MqM4qf+I2f6VrolyvwMR5eJr8t8wMbzeGqGUebbLoy0=;
b=adGp4MSq1m9KHD9da/HN1gWPfd13nOyzjUXL8AaOsqjveIMQi57zaJH1UhmTOGTBKF
VyV+8AvSrXdVcVCuiG2c7cAn/DfgAE3inzT8yvM5j/I4RxHXcY2RtmBXnvIPhDe6Ma48
YB/vkkdMY2pRPemFWCH96M9iRGtceDZ8YTQ2QKItS+lyeoKokjWet77R0InUtbKY4ShV
pKnaVv4XOa5FWJh+cbyOgRYckdT+7rz8F1HiCS+FRbSOWmUHJVvs3Sm4d0AXrTEd1d/s
U+K7iH7oanv5KdeWXWdzUoTXTWAU1m4Bs1HOQpODjHp4ifMg+6N9eRMX4L39XFvoFJtK
m1tw==
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=MqM4qf+I2f6VrolyvwMR5eJr8t8wMbzeGqGUebbLoy0=;
b=pS0Zygk/Q+iUhrMzdYY/bbgLPf0hMgfP10yQPkyVXpZsVpm3JAJ+hJpDFaxGnZGo3y
qsq5VOoFtq3F1H0KWnU4iWVApMJya1+6+DnMtemeuDvpjtsXiAPlIwISeXoD6oZH5dkq
4UBOqEi0AXKzDuSYiOtHwSbrgwDOsBM4OVXqvWZKEWWY40xPnIAHb/UKGizrDsUtiuGb
CD8CJEgEUdJUNVhPBLtC9MeCrnZM6xyxGuEHCrqqyzVd/Z8zpB10rgnW3SjHMl82W+Kn
t0qOvcBXFkyD622ev+0TD/2c19MuOEWu1sfjX0IynVs/xF/U3vd8cliRKqUTKuqsHm3W
1eAw==
X-Gm-Message-State: AOAM531qdIryWEtALQzOz/zLlKzIFEj2eXwapmnQq1eVGDkEYnX0GMJ4
mq+eY/WZrs8CHiZ1hHGv6Mm790LgEYw5Xf9ReU8l06Q=
X-Google-Smtp-Source: ABdhPJygrTfLCSMgyzLWKoBYo0OIiWp+RsdrcXZDZUY0rynP+XffkNmCo8BA3wH6NT9xss7SzS3z0jJ8oDsGilH6bYY=
X-Received: by 2002:aa7:8202:0:b029:2d8:c24d:841d with SMTP id
k2-20020aa782020000b02902d8c24d841dmr427133pfi.57.1621270751171; Mon, 17 May
2021 09:59:11 -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>
In-Reply-To: <CAD5xwhi1G3Jj3FAAWQP3BXTK34ugDQY32hq-cQnt8Ny8JP4eGQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 17 May 2021 12:58:59 -0400
Message-ID: <CAJowKgJ1x5YKWS1S-sgdU3Tn+hPT64iiUCwG8qh-JS0xqS7ieA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Mon, 17 May 2021 19:00:13 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
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: Mon, 17 May 2021 16:59:13 -0000
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.
There has been some decent earlier work on blind/uncensorable burns:
https://eprint.iacr.org/2019/1096.pdf
A miner could then reveal A) the VDF and B) proof-of-burn as a part of
a block. Nodes would simply select the block with A) a valid VDF and
B) the highest "qualified" POB.
With most burns running at a loss, and no way to predict the next
"winning burn", and the VDF providing timing, I'm not sure how this is
worse than Bitcoin's existing system.
On Mon, May 10, 2021 at 5:51 PM Jeremy <jlrubin@mit.edu> wrote:
>
> re: 2, there's been some promising developments with Verifiable Delay Functions that make me think that the block regulation problems are solvable without requiring brute-force search proof of work. Are those inapplicable for some reason?
>
|
