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
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
|
Return-Path: <tensiam@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D955DCD3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Jul 2019 10:10:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from EUR02-VE1-obe.outbound.protection.outlook.com
(mail-oln040092069108.outbound.protection.outlook.com [40.92.69.108])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44A3071C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Jul 2019 10:10:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=9iw7I4G+kdQHv+Y3vNzKDMxc42AbfZs/YU1+nOooYaU=;
b=kRygxrzRjoLC98UZ+5Nqr+tkhWnReW2aMcPyO0YIi31I9eFjWb4WnShqV2+f6CPsPycrQPYvLgeO591HksRdaZh+9sk95U1EC404/zchTtZv9weL9RXeitAhb7jZTjKx2wsrtu/Bp9j7ue0suakboGtgvwiP7/7uFSzbfrASNxCU8SuL1Fg9dh4QTK4XP7nKdjsC4UFiB63IuKI4ZLd5xJ9vCrjLtcbSV8p6k1wP40QmhLS6u28Q7NGRoNIzLIcGM1Pmb1XUkJrxTb63jqBeTOyMcsm5neIkcTghYs1SkOX0pkOob3UeErh6QW9TMnyfYN67TDNMMNSWEq4lWUaMEA==
Received: from VE1EUR02FT053.eop-EUR02.prod.protection.outlook.com
(10.152.12.52) by VE1EUR02HT040.eop-EUR02.prod.protection.outlook.com
(10.152.13.247) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.19;
Wed, 17 Jul 2019 10:10:23 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.12.56) by
VE1EUR02FT053.mail.protection.outlook.com (10.152.13.137) with
Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
15.20.2052.19 via Frontend Transport; Wed, 17 Jul 2019 10:10:23 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
([fe80::c5ee:488e:37fb:4be5]) by
DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
([fe80::c5ee:488e:37fb:4be5%4]) with mapi id 15.20.2073.012;
Wed, 17 Jul 2019 10:10:23 +0000
From: "Kenshiro []" <tensiam@hotmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
ZmnSCPxj <ZmnSCPxj@protonmail.com>
Thread-Topic: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LabN5JoAgAC5YAg=
Date: Wed, 17 Jul 2019 10:10:23 +0000
Message-ID: <DB6PR10MB1832BAAB9D194B6AA61C2573A6C90@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
<Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
In-Reply-To: <Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
Accept-Language: en-US, es-ES
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:7FC67997B5D5839612AEADEE9ED386AB9659C9ABBD6565BC2AC82C2A691F2F82;
UpperCasedChecksum:61448249A0A2C5935749066CA2B4C4CBD126155A98FB828261926926897CE67F;
SizeAsReceived:6991; Count:42
x-tmn: [9NjXFxtGgnuLl0Rhnzdcp8OfokP8i8jH]
x-ms-publictraffictype: Email
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0;
RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045);
SRVR:VE1EUR02HT040;
x-ms-traffictypediagnostic: VE1EUR02HT040:
x-microsoft-antispam-message-info: /o7UsI9hy3nEL4CDEivICGmHDlYSlk4odM16C1ZjC31HJLayDZrrZAWErvemF8vkXWjyaS/dAy0m7/naJ1Eh2EaBj9Vc3diwCdAVlNsnMWeo6/hZ/1gK+wn/YtwINfnOI0ytOy9UxAvSTzcnHCMF0WursHbPvCXllDVxmVx/m2/UFPW48F3h5lUiwqg1Ham6
Content-Type: multipart/alternative;
boundary="_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 0cb30bd7-1889-40fd-7a08-08d70a9efb9f
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 10:10:23.8358 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT040
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY,
RCVD_IN_DNSWL_NONE autolearn=ham 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 10:49:15 +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: Wed, 17 Jul 2019 10:10:28 -0000
--_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj,
I'm based on the more evolved implementation of PoS that I know, which is P=
oS v3.0 and it's currently implemented in several coins:
http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-s=
take-version
As far as I know the grinding attack is and old issue that is fixed in PoS =
v3.0.
>>>At least the proposed `assumeutxo` requires the operator to explicitly e=
nable it, but I believe your "hardcoded checkpoints" cannot be disabled, mu=
ch less disabled-by-default.
We don't trust the developers, the source code is public and anyone can che=
ck it. With the hardcoded checkpoints is exactly the same, they are in the =
source code repository and everyone can check them. The checkpoints are the=
easiest part to check. A user doesn't have any reason to remove the checkp=
oints, but as with anything in the source code, they could modify it to avo=
id the checkpoints (and become vulnerable to Long Range attacks doing it)
>>>Under the trust-minimization requirement of Bitcoin this is simply not a=
cceptable.
As there is no way to trust-minimally heal from a network split (and every =
time a node is shut down, that is indistinguishable from a network split th=
at isolates that particular node), this is not a trust-minimizing consensus=
algorithm.
The block explorer or other additional source of trust like a friend would =
only be required in the extreme situation that the network is under a 51% a=
ttack, and only by the nodes that are updating blocks in that moment. Updat=
ed nodes are fully protected, and under normal circumstances new nodes can =
just follow the longest chain as always. The other extreme situation that c=
ould cause a hard fork is that the network is splitted more than N blocks, =
which should require some social consensus to fix it. So N should be long e=
nough, like a few hours of blocks or even 1 day.
>>> History rewrites are not the only attack possible.
The worst attack is a censorship attack, and a 99% staker can easily censor=
on the creation of new blocks.
I don't agree, history rewrite attacks are much worse than censorship becau=
se they can be used to steal funds from people. In PoS staking addresses ar=
e public, so maybe it should be possible to detect if some transaction in t=
he mempool is repeatedly being ignored and what staking deposit is repeated=
ly ignoring transactions. After some time, a hard fork could burn the funds=
of the evil validator.
>>> Worse, under proof-of-stake it is often the case that stakers are award=
ed even more coin with which they can stake.
Sure, but in PoW the miners with more hash power earn more coins that can b=
e used to purchase more miners. There is always the privilege of the rich g=
uy, no matter if its PoW or PoS. The point is to design a protocol that don=
't allow the rich to destroy the network.
Let me put it in this way: NXT is a PoS coin that uses moving checkpoints w=
ith a market cap of 21 million dollars. If the current PoS protocols are so=
flawed, how can you explain that a coin with this market cap is not being =
attacked?
https://www.coingecko.com/en/coins/nxt
Another thing is that Ethereum itself is going to PoS next year, but with a=
different implementation that I'm proposing here.
Regards,
________________________________
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Wednesday, July 17, 2019 1:00
To: Kenshiro \[\]; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Good morning Kenshiro,
Sent with ProtonMail Secure Email.
=1B$B!>!>!>!>!>!>!>=1B(B Original Message =1B$B!>!>!>!>!>!>!>=1B(B
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
> Hi,
>
> After studying several Proof of Stake implementations I think it's not on=
ly an eco-friendly (and more ethical) alternative to Proof of Work, but cor=
rectly implemented could be 100% secure against all 51% history rewrite att=
acks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvemen=
ts are required:
Under the trust-minimization and uncensorability requirements that Bitcoin =
has, nothing is more efficient than proof-of-work.
The very idea of proof-of-stake labors under the assumption that unencumber=
ed free-market payment for the consumption of energy is somehow not market-=
efficient despite the well-known phenomenon of the invisible hand, and beli=
eves that it is possible to get something for nothing.
Please re-examine your assumptions.
> - Hardcoded checkpoints:each Bitcoin Core release (each few months) shoul=
d 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.
While this is a developer list and made up of developers who would be quite=
incentivized to agree to such a setup, note that this effectively trusts t=
he developers.
At least the proposed `assumeutxo` requires the operator to explicitly enab=
le it, but I believe your "hardcoded checkpoints" cannot be disabled, much =
less disabled-by-default.
> This extra rule could be connecting to a block explorer to download the h=
ash of the current block height, or ask some trusted source like a friend a=
nd 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.
Under the trust-minimization requirement of Bitcoin this is simply not acce=
ptable.
As there is no way to trust-minimally heal from a network split (and every =
time a node is shut down, that is indistinguishable from a network split th=
at isolates that particular node), this is not a trust-minimizing consensus=
algorithm.
>
> 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 t=
he network not creating his blocks, or censor transactions in his blocks.
History rewrites are not the only attack possible.
The worst attack is a censorship attack, and a 99% staker can easily censor=
on the creation of new blocks.
Censorship attacks cannot be prevented except by ensuring that no single en=
tity can claim 51% control of new block creation.
By ensuring this, we can ensure that at least some other entities are unlik=
ely to keep a transaction out of the blockchain, and in particular that no =
entity can make a short-ranged history rewrite if a censored transaction *d=
oes* get into the blockchain from the efforts of another block producer.
This is trivial under proof-of-work, and is the cost we accept in order to =
achieve uncensorability, since it is non-trivial to acquire energy.
Under proof-of-stake it is difficult to impossible to determine if some sin=
gle entity controls >51% of stakeable coins, and thus has no way to protect=
against censorship attack.
Worse, under proof-of-stake it is often the case that stakers are awarded e=
ven more coin with which they can stake.
Depending on the PoS implementation, stake-grinding may allow a 49% staker =
to achieve 51% and thereby the ability to censor transactions.
Regards,
ZmnSCPxj
--_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-2022-=
jp">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<span>Hi ZmnSCPxj,<br>
</span>
<div><br>
</div>
<div>I'm based on the more evolved implementation of PoS that I know, which=
is PoS v3.0 and it's currently implemented in several coins:<br>
</div>
<div><br>
</div>
<div>http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof=
-of-stake-version<br>
</div>
<div><br>
</div>
<div>As far as I know the grinding attack is and old issue that is fixed in=
PoS v3.0.<br>
</div>
<div><br>
</div>
<div>>>>At least the proposed `assumeutxo` requires the operator t=
o explicitly enable it, but I believe your "hardcoded checkpoints"=
; cannot be disabled, much less disabled-by-default.<br>
</div>
<div><br>
</div>
<div>We don't trust the developers, the source code is public and anyone ca=
n check it. With the hardcoded checkpoints is exactly the same, they are in=
the source code repository and everyone can check them. The checkpoints ar=
e the easiest part to check. A user
doesn't have any reason to remove the checkpoints, but as with anything in=
the source code, they could modify it to avoid the checkpoints (and become=
vulnerable to Long Range attacks doing it)<br>
</div>
<div><br>
</div>
<div>>>>Under the trust-minimization requirement of Bitcoin this i=
s simply not acceptable.<br>
</div>
<div>As there is no way to trust-minimally heal from a network split (and e=
very time a node is shut down, that is indistinguishable from a network spl=
it that isolates that particular node), this is not a trust-minimizing cons=
ensus algorithm.<br>
</div>
<div><br>
</div>
<div>The block explorer or other additional source of trust like a friend w=
ould only be required in the extreme situation that the network is under a =
51% attack, and only by the nodes that are updating blocks in that moment. =
Updated nodes are fully protected,
and under normal circumstances new nodes can just follow the longest chain=
as always. The other extreme situation that could cause a hard fork is tha=
t the network is splitted more than N blocks, which should require some soc=
ial consensus to fix it. So N should
be long enough, like a few hours of blocks or even 1 day.<br>
</div>
<div><br>
</div>
<div>>>> History rewrites are not the only attack possible.<br>
</div>
<div>The worst attack is a censorship attack, and a 99% staker can easily c=
ensor on the creation of new blocks.<br>
</div>
<div><br>
</div>
<div>I don't agree, history rewrite attacks are much worse than censorship =
because they can be used to steal funds from people. In PoS staking address=
es are public, so maybe it should be possible to detect if some transaction=
in the mempool is repeatedly being
ignored and what staking deposit is repeatedly ignoring transactions. Afte=
r some time, a hard fork could burn the funds of the evil validator.<br>
</div>
<div><br>
</div>
<div>>>> Worse, under proof-of-stake it is often the case that sta=
kers are awarded even more coin with which they can stake.<br>
</div>
<div><br>
</div>
<div>Sure, but in PoW the miners with more hash power earn more coins that =
can be used to purchase more miners. There is always the privilege of the r=
ich guy, no matter if its PoW or PoS. The point is to design a protocol tha=
t don't allow the rich to destroy
the network.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Let me put it in this way: NXT is a PoS coin that uses moving checkpoi=
nts with a market cap of 21 million dollars. If the current PoS protocols a=
re so flawed, how can you explain that a coin with this market cap is not b=
eing attacked?<br>
</div>
<div><br>
</div>
<div>https://www.coingecko.com/en/coins/nxt<br>
</div>
<div><br>
</div>
<div>Another thing is that Ethereum itself is going to PoS next year, but w=
ith a different implementation that I'm proposing here.<br>
</div>
<div><br>
</div>
<span>Regards,</span><br>
</div>
<div>
<div id=3D"appendonsend"></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> ZmnSCPxj <ZmnSCPxj=
@protonmail.com><br>
<b>Sent:</b> Wednesday, July 17, 2019 1:00<br>
<b>To:</b> Kenshiro \[\]; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Secure Proof Of Stake implementation on B=
itcoin</font>
<div> </div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"=
>
<div class=3D"PlainText">Good morning Kenshiro,<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
<br>
=1B$B!>!>!>!>!>!>!>=1B(B Original Message =1B$B!>!>!>!>!>!>!>=1B(B<br>
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:<br>
<br>
> Hi,<br>
><br>
> 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:<br>
<br>
Under the trust-minimization and uncensorability requirements that Bitcoin =
has, nothing is more efficient than proof-of-work.<br>
The very idea of proof-of-stake labors under the assumption that unencumber=
ed free-market payment for the consumption of energy is somehow not market-=
efficient despite the well-known phenomenon of the invisible hand, and beli=
eves that it is possible to get
something for nothing.<br>
<br>
Please re-examine your assumptions.<br>
<br>
> - Hardcoded checkpoints:each Bitcoin Core release (each few months) sh=
ould include a hardcoded checkpoint with the hash of the current block heig=
ht in that moment. This simple measure protects the blockchain up to the la=
st checkpoint, and prevents any Long-Range
attack.<br>
<br>
While this is a developer list and made up of developers who would be quite=
incentivized to agree to such a setup, note that this effectively trusts t=
he developers.<br>
At least the proposed `assumeutxo` requires the operator to explicitly enab=
le it, but I believe your "hardcoded checkpoints" cannot be disab=
led, much less disabled-by-default.<br>
<br>
> This extra rule could be connecting to a block explorer to download th=
e hash of the current block height, or ask some trusted source like a frien=
d and enter the hash manually. After being fully updated, the user can alwa=
ys check that he is in the correct
chain checking with a block explorer.<br>
<br>
Under the trust-minimization requirement of Bitcoin this is simply not acce=
ptable.<br>
As there is no way to trust-minimally heal from a network split (and every =
time a node is shut down, that is indistinguishable from a network split th=
at isolates that particular node), this is not a trust-minimizing consensus=
algorithm.<br>
<br>
><br>
> Someone could have 99% of the coins and still would be unable to use t=
he coins to do any history rewrite attack. The attacker could only slow dow=
n the network not creating his blocks, or censor transactions in his blocks=
.<br>
<br>
History rewrites are not the only attack possible.<br>
The worst attack is a censorship attack, and a 99% staker can easily censor=
on the creation of new blocks.<br>
<br>
Censorship attacks cannot be prevented except by ensuring that no single en=
tity can claim 51% control of new block creation.<br>
By ensuring this, we can ensure that at least some other entities are unlik=
ely to keep a transaction out of the blockchain, and in particular that no =
entity can make a short-ranged history rewrite if a censored transaction *d=
oes* get into the blockchain from
the efforts of another block producer.<br>
<br>
This is trivial under proof-of-work, and is the cost we accept in order to =
achieve uncensorability, since it is non-trivial to acquire energy.<br>
Under proof-of-stake it is difficult to impossible to determine if some sin=
gle entity controls >51% of stakeable coins, and thus has no way to prot=
ect against censorship attack.<br>
Worse, under proof-of-stake it is often the case that stakers are awarded e=
ven more coin with which they can stake.<br>
<br>
Depending on the PoS implementation, stake-grinding may allow a 49% staker =
to achieve 51% and thereby the ability to censor transactions.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</div>
</span></font></div>
</div>
</body>
</html>
--_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_--
|