summaryrefslogtreecommitdiff
path: root/f6/28cfe848344befa54c8e76bcbcb7f9a9980975
blob: a6eb5a9891f62e4f7b800df442fcb6b344f3acd0 (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
Return-Path: <keagan.mcclelland@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 11362C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 May 2021 15:01:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E34E140217
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 May 2021 15:01:19 +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 B35qm66BPlj4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 May 2021 15:01:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com
 [IPv6:2a00:1450:4864:20::436])
 by smtp2.osuosl.org (Postfix) with ESMTPS id AB716401CC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 May 2021 15:01:18 +0000 (UTC)
Received: by mail-wr1-x436.google.com with SMTP id a4so16981615wrr.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 10 May 2021 08:01:18 -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=Vk9xZU7+Qt5tv4JAgwufE9Rx7h4KR7VN1wKZPirhR8c=;
 b=P1vPayk7kVICCRNDq3swQn4Tav1t1KvxARye5D/HOvz4JbuNR1YYcj8ma0R9y54DIw
 goAuBmTo9gClPevIZ0bSIT0gnOaOAWpDHUwunr5ZnVBEmWZtrjvHA5f/MDuKVgscE+pi
 JpXIXE+IwgkaUrw/OcKHa7aYjTcVFf7MITiA74NqQMAWaZs27Wud3SYWrH8ZYfjPnkb6
 G/CjNy0XFYd6u5djp2nwVeTaI9WnRECpvyNNgzOE/Z/um12TDdHsTgMf8zFezb5oPjLG
 hXuyIiISXtDYm37AjKtuBUuzl30f5OAUvWnuZ4LKklZjpR8VunBfLyPnhF2pouxz0+e0
 6gng==
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=Vk9xZU7+Qt5tv4JAgwufE9Rx7h4KR7VN1wKZPirhR8c=;
 b=V2NcYq7L9/TutIV6RamdwCuzUYMyQN58m5j5mxxOZahRj6fnld7uLF26zv7UQWfJlW
 6p0ZcrwK2psakktL/7Z+U1RuoEhbUmvqeb2Yur3A3D5gxaNAFLhwXv8D4lL6LKRFyPK0
 9GJhBW2fW2/rZ1mv7lZX622FSWFxhJlP5dtq0da0sK8RfyabMfJoughn4qWmn+WNinAt
 15eXxZ1C7EbFERaHigopjRx7BtJ9zvM7kBVH/pGHLkJkNjeiBOzvpORmmD0HPSoseaRd
 ZK6xTNWo9tBGTnMONK4Q8tzZAoZynDo6a41+uQ3lIM/ypXZmIHbbhErxq4yJmfL6rLdX
 EQtQ==
X-Gm-Message-State: AOAM530G4XI0DKBXNjHYGNy2hhe1A8HvD9UZk1AOR56VovOVELya0/7y
 8Dn1IdGxNGBgqF1r+/qQpjxTo8AX+5IhebR02hzJcM1BpFE=
X-Google-Smtp-Source: ABdhPJwLMChvd2yHV/D1Ix3S6xuIHLyIOwuhKSrnQURZKEXLA7DxGvQKFJNYoFgu/fVWVV5j2nvkZt3jKsVRNQ+i0/w=
X-Received: by 2002:a5d:4d0b:: with SMTP id z11mr31885196wrt.164.1620658876433; 
 Mon, 10 May 2021 08:01:16 -0700 (PDT)
MIME-Version: 1.0
References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com>
 <CAJowKg+QM94g+JcC-E-NGD4J9-nXHWt5kBw14bXTAWaqZz=bYw@mail.gmail.com>
In-Reply-To: <CAJowKg+QM94g+JcC-E-NGD4J9-nXHWt5kBw14bXTAWaqZz=bYw@mail.gmail.com>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Mon, 10 May 2021 09:01:05 -0600
Message-ID: <CALeFGL02d9NVp+yobrtc2g6k2nBjBj0Qb==3Ukkbi8C_zb5qMg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary="000000000000a1ca4e05c1fb0ca2"
X-Mailman-Approved-At: Mon, 10 May 2021 18:56:26 +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: Mon, 10 May 2021 15:01:20 -0000

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

To reiterate some of the points here. My problem with proof of stake is
twofold.

1. It requires permission of coin holders to enter into the system. This is
not true of proof of work. You may even attempt (though not successfully) a
proof of work with pencil and paper and submit the block from a regular
laptop if you so choose. Whether this level of permissionlessness is
necessary is up to individual risk tolerance etc. but it is definitely the
default preference of Bitcoin.

2. Proof of stake must have a trusted means of timestamping to regulate
overproduction of blocks. This introduction of trust is generally
considered to be a nonstarter in Bitcoin. Proof of Work regulates this by
making blocks fundamentally difficult to produce in the first place.

Like Jeremy, I=E2=80=99m always interested to learn about new attempts in c=
onsensus
algorithms, but the bar to clear is very high and proof of stake to date
has not proposed much less demonstrated a set of properties that is
consistent with Bitcoins objectives.

Keagan

On Mon, May 10, 2021 at 8:43 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> personally, not speaking for anyone else, i think that proof-of-burn
> has a much higher likelihood of being a) good enough security and b)
> solving the nothing-at-stake problem
>
>  the only issue i see with a quality PoB implementation is a robust
> solution to the block-timing problem.
>
> https://grisha.org/blog/2018/01/23/explaining-proof-of-work/
>
> i do think there *could* be other low-energy solutions to verifiable
> timing, just haven't seen one
>
>
> On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Hello list,
> >
> > I am a lurker here and like many of you I worry about the energy usage
> of bitcoin mining. I understand a lot mining happens with renewable
> resources but the impact is still high.
> >
> > I want to get your opinion on implementing proof of stake for bitcoin
> mining in future. For now, proof of stake is still untested and not battl=
e
> tested like proof of work. Though someday it will be.
> >
> > In the following years we'll be seeing proof of stake being implemented=
.
> Smaller networks can test PoS which is a luxury bitcoin can't afford.
> Here's how I see this the possibilities:
> >
> > 1 - Proof of stake isn't a good enough security mechanism
> > 2 - Proof of state is a good security mechanism and works as intended
> >
> > IF PoS turns out to be good after battle testing, would you consider
> implementing it for Bitcoin? I understand this would invoke a lot of
> controversies and a hard fork that no one likes. But its important enough
> to consider a hard fork. What are your opinions provided PoS does work?
> >
> > Love from India.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">To reiterate some of the points here. My problem with pro=
of of stake is twofold.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">1. It requires permission of coin holders to enter into the system. T=
his is not true of proof of work. You may even attempt (though not successf=
ully) a proof of work with pencil and paper and submit the block from a reg=
ular laptop if you so choose. Whether this level of permissionlessness is n=
ecessary is up to individual risk tolerance etc. but it is definitely the d=
efault preference of Bitcoin.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">2. Proof of stake must have a trusted means of timestamping to regula=
te overproduction of blocks. This introduction of trust is generally consid=
ered to be a nonstarter in Bitcoin. Proof of Work regulates this by making =
blocks fundamentally difficult to produce in the first place.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Like Jeremy, I=E2=80=99m always inter=
ested to learn about new attempts in consensus algorithms, but the bar to c=
lear is very high and proof of stake to date has not proposed much less dem=
onstrated a set of properties that is consistent with Bitcoins objectives.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">Keagan</div><div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 1=
0, 2021 at 8:43 AM Erik Aronesty via bitcoin-dev &lt;<a href=3D"mailto:bitc=
oin-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.8ex;border-left-width:1px;border-left-style:solid;padding-left:1=
ex;border-left-color:rgb(204,204,204)">personally, not speaking for anyone =
else, i think that proof-of-burn<br>
has a much higher likelihood of being a) good enough security and b)<br>
solving the nothing-at-stake problem<br>
<br>
=C2=A0the only issue i see with a quality PoB implementation is a robust<br=
>
solution to the block-timing problem.<br>
<br>
<a href=3D"https://grisha.org/blog/2018/01/23/explaining-proof-of-work/" re=
l=3D"noreferrer" target=3D"_blank">https://grisha.org/blog/2018/01/23/expla=
ining-proof-of-work/</a><br>
<br>
i do think there *could* be other low-energy solutions to verifiable<br>
timing, just haven&#39;t seen one<br>
<br>
<br>
On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Hello list,<br>
&gt;<br>
&gt; I am a lurker here and like many of you I worry about the energy usage=
 of bitcoin mining. I understand a lot mining happens with renewable resour=
ces but the impact is still high.<br>
&gt;<br>
&gt; I want to get your opinion on implementing proof of stake for bitcoin =
mining in future. For now, proof of stake is still untested and not battle =
tested like proof of work. Though someday it will be.<br>
&gt;<br>
&gt; In the following years we&#39;ll be seeing proof of stake being implem=
ented. Smaller networks can test PoS which is a luxury bitcoin can&#39;t af=
ford. Here&#39;s how I see this the possibilities:<br>
&gt;<br>
&gt; 1 - Proof of stake isn&#39;t a good enough security mechanism<br>
&gt; 2 - Proof of state is a good security mechanism and works as intended<=
br>
&gt;<br>
&gt; IF PoS turns out to be good after battle testing, would you consider i=
mplementing it for Bitcoin? I understand this would invoke a lot of controv=
ersies and a hard fork that no one likes. But its important enough to consi=
der a hard fork. What are your opinions provided PoS does work?<br>
&gt;<br>
&gt; Love from India.<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><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>

--000000000000a1ca4e05c1fb0ca2--