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
|
Return-Path: <otech47@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 81931E39
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Jul 2019 20:35:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com
[209.85.208.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8DC208A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Jul 2019 20:35:34 +0000 (UTC)
Received: by mail-lj1-f196.google.com with SMTP id v24so21329263ljg.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Jul 2019 13:35:34 -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=6D/YTKiAjf0i3dk0zfTtmiE6zXpybK2vEF7BvnTNXg8=;
b=kROBvnaTDoknSTUkyDTMck1K8cVme6jAjMZwHFRLpVYRSbn3A3eJi0iDNF2Mm+WoqP
Q/PHAYTd/uNEsmWVOROwtNlX1K3Lm+0t4fXRVmVjmLt5FOrGJJUGvbidoa9nO3YqknAr
FF3EnzqJQdRLeL3L8SPwU7kA7xRsyXODJYtsbLB/MiiRy5VvLqoPaTbvE+ruv3bkumhj
5XQirANwwjPduaIJZfISkxr17dNCrly9H6KgI3AHH2P1lsxoJ61eyOvFjI3nIEkfYd6W
FJShT6nQ5MvgYSzFyG1UVCeb4XqeAtw6ptLd3E/corUr6mtH5BeM9sbbOKWjawdgUhsl
U4/w==
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=6D/YTKiAjf0i3dk0zfTtmiE6zXpybK2vEF7BvnTNXg8=;
b=XU4p4+wpyHh53ymgrYZtOVgRIOYubOZZYPiufU4GF95D8A3GW0KSB/Tc09dIxHvSyK
+r1MXF0G3VU8DBgZSxCYGnOaJgdJ90bdzNBmpHKzcurl/w4+cpMXvmy1uJ6cPvrm75Rc
1LphZYXX43Y0BlIXYBUgBnGVF3DN70TRR+1OhsC+Igoyn2/+5rFfr6AyRIFW46rsj7em
DNEBTtx1h8Q3ErwjLN8oDaTDLPuppTPKtYL/DT0leHwXgiccU53UPdaGyB6hlQbbzhbw
HHWolQvGATobBZIt+Nd6fbTWJkmHne1a3KaTClgBScVM6mqt6fGhYKDH9Mav7swK5CbT
WZhg==
X-Gm-Message-State: APjAAAVgF6DhigYKkgVp+sHzxm5GsTBAZUMZhctu2ACqVH/wnB6uxEZg
vzZO3AXekfHdLQ6d4ZxkaM9lw1494tao/CFsn3c=
X-Google-Smtp-Source: APXvYqwUbclcJ5cg2yPh4WJxuYZxv7DGwA19IIa5ylajJGIT0g34UYVrQT1Od1BCUwThlPn3RnG/TB5gn9ETbs9q0zw=
X-Received: by 2002:a2e:a415:: with SMTP id p21mr18609932ljn.111.1563309332730;
Tue, 16 Jul 2019 13:35:32 -0700 (PDT)
MIME-Version: 1.0
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
From: Oscar Lafarga <otech47@gmail.com>
Date: Tue, 16 Jul 2019 13:35:21 -0700
Message-ID: <CAO7Y_eWDcFHWQMSL3h4Nz1a4FVsMq04YsGph5RR6khWzzdAyOg@mail.gmail.com>
To: "Kenshiro []" <tensiam@hotmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000739964058dd25125"
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, HTTPS_HTTP_MISMATCH,
RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 17 Jul 2019 07:52:04 +0000
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 16 Jul 2019 20:35:35 -0000
--000000000000739964058dd25125
Content-Type: text/plain; charset="UTF-8"
Hi Kenshiro,
I don't think your proposal would require any changes to the Bitcoin Core
implementation. This system you describe seems like it would operate as an
independent addition, rather than an alternative to the Proof of Work
consensus code that runs within Bitcoin now. It introduces security risk in
the selection of block explorer and to the Bitcoin Core release dispatch
system, reducing the trustlessness of the current network. Also, without
the constraints that PoW places on block creation, you increase the vector
space for attacks since it is trivial to spam blocks to node on the network
(see Sybil attack <https://en.wikipedia.org/wiki/Sybil_attack#>).
I believe many other software projects have tried similar checkpointing
schemes that have resulted in hard forks or overall weakened consensus. I
haven't dug too deeply, but I'm not aware of any cases where these schemes
accomplish anything useful to improve the bitcoin network.
Best,
On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi,
>
>
> After studying several Proof of Stake implementations I think it's not
> only an eco-friendly (and more ethical) alternative to Proof of Work, but
> correctly implemented could be 100% secure against all 51% history rewrite
> attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra
> improvements are required:
>
>
> - Hardcoded checkpoints: each Bitcoin Core release (each few months)
> should include a hardcoded checkpoint with the hash of the current block
> height in that moment. This simple measure protects the blockchain up to
> the last checkpoint, and prevents any Long-Range attack.
>
>
> - Moving checkpoints: the nodes only allow chain reorgs not deeper than N
> blocks. If N is 10 blocks, then the nodes ignore any hard fork starting at
> any block under nodeBlockHeight - N. This fully protects nodes that are
> online and updated. Nodes that are not fully updated need some extra rule
> to be protected between the last hardcoded checkpoint and the current
> blockchain height. This extra rule could be connecting to a block explorer
> to download the hash of the current block height, or ask some trusted
> source like a friend and enter the hash manually. After being fully
> updated, the user can always check that he is in the correct chain checking
> with a block explorer.
>
>
> Someone could have 99% of the coins and still would be unable to use the
> coins to do any history rewrite attack. The attacker could only slow down
> the network not creating his blocks, or censor transactions in his blocks.
>
>
> What do you think? :)
>
>
> Regards
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Oscar Lafarga
https://www.setlife.network
<https://www.setdev.io/>
--000000000000739964058dd25125
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Kenshiro,<br><br>I don't think your proposal would =
require any changes to the Bitcoin Core implementation. This system you des=
cribe seems like it would operate as an independent addition, rather than a=
n alternative to the Proof of Work consensus code that runs within Bitcoin =
now. It introduces security risk in the selection of block explorer and to =
the Bitcoin Core release dispatch system, reducing the trustlessness of the=
current network. Also, without the constraints that PoW places on block cr=
eation, you increase the vector space for attacks since it is trivial to sp=
am blocks to node on the network (see <a href=3D"https://en.wikipedia.org/w=
iki/Sybil_attack#">Sybil attack</a>).<br><br>I believe many other software =
projects have tried similar checkpointing schemes that have resulted in har=
d forks or overall weakened consensus. I haven't dug too deeply, but I&=
#39;m not aware of any cases where these schemes accomplish anything useful=
to improve the bitcoin network.<br><br>Best,</div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 16, 2019 at 5:33 A=
M Kenshiro [] via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12pt;color=
:rgb(0,0,0)">
<p style=3D"margin:0px;padding:0px 0px 0.25em;font-size:14px;font-family:&q=
uot;Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:r=
gb(255,255,255)">
Hi,</p>
<p style=3D"margin:0px;padding:0.25em 0px;font-size:14px;font-family:"=
Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:rgb(2=
55,255,255)">
<br>
</p>
<p style=3D"margin:0px;padding:0.25em 0px;font-size:14px;font-family:"=
Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:rgb(2=
55,255,255)">
After studying several Proof of Stake implementations I think it's not =
only an eco-friendly (and more ethical) alternative to Proof of Work, but c=
orrectly implemented could be 100% secure against all 51% history rewrite a=
ttacks. Over a "standard" PoS protocol
like PoS v3.0, only 2 extra improvements are required:</p>
<p style=3D"margin:0px;padding:0.25em 0px;font-size:14px;font-family:"=
Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:rgb(2=
55,255,255)">
<br>
</p>
<p style=3D"margin:0px;padding:0.25em 0px;font-size:14px;font-family:"=
Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:rgb(2=
55,255,255)">
<span style=3D"margin:0px">- Hardcoded checkpoints:</span><span>=C2=A0</spa=
n>each Bitcoin Core release (each few months) should include a hardcoded ch=
eckpoint with the hash of the current block height in that moment. This sim=
ple measure protects the blockchain up
to the last checkpoint, and prevents any Long-Range attack.</p>
<p style=3D"margin:0px;padding:0.25em 0px;font-size:14px;font-family:"=
Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:rgb(2=
55,255,255)">
<br>
</p>
<p style=3D"margin:0px;padding:0.25em 0px;font-size:14px;font-family:"=
Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:rgb(2=
55,255,255)">
<span style=3D"margin:0px">- Moving checkpoints: the nodes only allow chain=
reorgs not deeper than N blocks. If N is 10 blocks, then the nodes ignore =
any hard fork starting at any block under nodeBlockHeight - N. This fully p=
rotects nodes that are online and
updated. Nodes that are not fully updated need some extra rule to be prote=
cted between the last hardcoded checkpoint and the current blockchain heigh=
t. This extra rule could be connecting to a block explorer to download the =
hash of the current block height,
or ask some trusted source like a friend and enter the hash manually. Afte=
r being fully updated, the user can always check that he is in the correct =
chain checking with a block explorer.</span></p>
<p style=3D"margin:0px;padding:0.25em 0px;font-size:14px;font-family:"=
Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:rgb(2=
55,255,255)">
<span style=3D"color:rgb(26,26,27);font-family:"Noto Sans",Arial,=
sans-serif;font-size:14px"><br>
</span></p>
<p style=3D"margin:0px;padding:0.25em 0px;font-size:14px;font-family:"=
Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:rgb(2=
55,255,255)">
<span style=3D"color:rgb(26,26,27);font-family:"Noto Sans",Arial,=
sans-serif;font-size:14px">Someone could have 99% of the coins and still wo=
uld be unable to use the coins to do any history rewrite attack. The attack=
er could only slow down the network
not creating his blocks, or censor transactions in his blocks.</span><br>
</p>
<p style=3D"margin:0px;padding:0.25em 0px;font-size:14px;font-family:"=
Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:rgb(2=
55,255,255)">
<br>
</p>
<p style=3D"margin:0px;padding:0.25em 0px 0px;font-size:14px;font-family:&q=
uot;Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:r=
gb(255,255,255)">
What do you think? :)</p>
<p style=3D"margin:0px;padding:0.25em 0px 0px;font-size:14px;font-family:&q=
uot;Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:r=
gb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px;padding:0.25em 0px 0px;font-size:14px;font-family:&q=
uot;Noto Sans",Arial,sans-serif;color:rgb(26,26,27);background-color:r=
gb(255,255,255)">
Regards</p>
<br>
</div>
</div>
_______________________________________________<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><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div=
dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"font-size:12.=
8px">Oscar Lafarga</span><div style=3D"font-size:12.8px"><a href=3D"https:/=
/www.setdev.io/" target=3D"_blank">https://www.setlife.network<br></a></div=
></div></div></div></div></div></div></div></div>
--000000000000739964058dd25125--
|
