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
|
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 50AF0D99
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Jul 2019 21:28:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from EUR03-DB5-obe.outbound.protection.outlook.com
(mail-oln040092071038.outbound.protection.outlook.com [40.92.71.38])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6F28892
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Jul 2019 21:28:03 +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=xAxtJaFgSM7j/OJJwiDPRu9WbpkdBkjcXuRcwoks4xU=;
b=KiieSMBfOdsr5RQjUJOtlcSJ3jUAFecKcZi1ykynm32uTDH9rprfR0IyloXftbo3jgIj6Hqj3H4CQESLybodStWZh6g48NP2gi0jizvC1nF+wDgoEJ2gyAIEGdlevMTU+uzffndKNfwo9nWtiWMEqDEmdlGUd40lU/ZuB3lN4ciYm3bayv+jsRDEXRz0MwakSw4H3j39q0bq5rvq04Nhiy9glvlyDqTJpicMjwrrjrX39sHhj8SAylG7z2W8IkPYWvJzir/5cy3UdTkM6R6P3DANs2LNKXws/+MPgeAnpiigT0AaaeW1gsPVy14OV/TNPAQjz2P/gZDCWI0/kxhDyQ==
Received: from AM5EUR03FT008.eop-EUR03.prod.protection.outlook.com
(10.152.16.51) by AM5EUR03HT239.eop-EUR03.prod.protection.outlook.com
(10.152.16.209) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18;
Tue, 16 Jul 2019 21:28:02 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.16.52) by
AM5EUR03FT008.mail.protection.outlook.com (10.152.16.123) with
Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2052.18 via Frontend Transport; Tue, 16 Jul 2019 21:28:01 +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;
Tue, 16 Jul 2019 21:28:01 +0000
From: "Kenshiro []" <tensiam@hotmail.com>
To: Oscar Lafarga <otech47@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LabNvC2AgAAIwng=
Date: Tue, 16 Jul 2019 21:28:01 +0000
Message-ID: <DB6PR10MB1832257D676DDA7B4F55E658A6CE0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
<CAO7Y_eWDcFHWQMSL3h4Nz1a4FVsMq04YsGph5RR6khWzzdAyOg@mail.gmail.com>
In-Reply-To: <CAO7Y_eWDcFHWQMSL3h4Nz1a4FVsMq04YsGph5RR6khWzzdAyOg@mail.gmail.com>
Accept-Language: en-US, es-ES
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:6DB4DFC73963C7B0DD91341B8F32F87D926DABD85236F6BE85AC9D9F0B13BB81;
UpperCasedChecksum:69E551AEC4AB3A9D11A665CD375E0649A40A8AAAE183E0872DA2567414821694;
SizeAsReceived:6901; Count:42
x-tmn: [v9KVNw9LFshfb7O9SqLSoAN9R0C60YMJ]
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)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045);
SRVR:AM5EUR03HT239;
x-ms-traffictypediagnostic: AM5EUR03HT239:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-message-info: of85H1nZGLp/b8GB4bTo8ZGvBiSg20g6R51bakH/7CFtyljMKbUEolJDCZko48RhPEzbLWkHf4sFkt/NWbqTZDz9ppnDpOSxumQEYcrJbGJbALuAMQsQ4inSNt6BPi8GLzpxh2jnWFecMXeA96pPcMbkISSR5Pu5umNXz6B/We7Ih+3s6/9liS9DqyE6i0mJ
Content-Type: multipart/alternative;
boundary="_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_"
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: 0a3b074d-e5cd-4cec-3fbd-08d70a347b17
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 21:28:01.4883 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT239
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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 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 21:28:05 -0000
--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Oscar,
Thank you for your answer. Just to clarify my proposal:
1 - It's a full change to Proof of Stake protocol to avoid the energy waste=
and to prevent a 51% history rewrite attack, even if the attacker has 99% =
of coins.
2 - The hardcoded checkpoints could be set by each bitcoin node client, not=
only Bitcoin Core. No matter if the checkpoints are different, only that t=
hey are frequent. They are there to prevent Long Range attacks. Checkpoints=
are public just like the rest of the software, they don't require any trus=
t. A bad checkpoint would be detected by the community.
3 - There are several PoS coins working just now and as far as I know they =
don't have any problem. NXT coin implements the moving checkpoint system an=
d others the hardcoded checkpoints.
4 - In any given block, only one staker gets the authorization to create th=
at block, so other stakers can't spam the network with many different block=
s as they are illegal.
5 - The block explorer is only required during a 51% attack, and only for n=
odes that are updating blocks during the attack. Updated nodes are protecte=
d thanks to the moving checkpoints.
Regards,
________________________________
From: Oscar Lafarga <otech47@gmail.com>
Sent: Tuesday, July 16, 2019 22:35
To: Kenshiro []; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Hi Kenshiro,
I don't think your proposal would require any changes to the Bitcoin Core i=
mplementation. This system you describe seems like it would operate as an i=
ndependent addition, rather than an alternative to the Proof of Work consen=
sus code that runs within Bitcoin now. It introduces security risk in the s=
election of block explorer and to the Bitcoin Core release dispatch system,=
reducing the trustlessness of the current network. Also, without the const=
raints 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 Syb=
il attack<https://en.wikipedia.org/wiki/Sybil_attack#>).
I believe many other software projects have tried similar checkpointing sch=
emes that have resulted in hard forks or overall weakened consensus. I have=
n't dug too deeply, but I'm not aware of any cases where these schemes acco=
mplish anything useful to improve the bitcoin network.
Best,
On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrot=
e:
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 corre=
ctly implemented could be 100% secure against all 51% history rewrite attac=
ks. 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 i=
n that moment. This simple measure protects the blockchain up to the last c=
heckpoint, and prevents any Long-Range attack.
- Moving checkpoints: the nodes only allow chain reorgs not deeper than N b=
locks. If N is 10 blocks, then the nodes ignore any hard fork starting at a=
ny block under nodeBlockHeight - N. This fully protects nodes that are onli=
ne 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 downloa=
d the hash of the current block height, or ask some trusted source like a f=
riend 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 co=
ins 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<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Oscar Lafarga
https://www.setlife.network
<https://www.setdev.io/>
--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<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);">
Hi Oscar,</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
Thank you for your answer. Just to clarify my proposal:</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
1 - It's a full change to Proof of Stake protocol to avoid the energy waste=
and to prevent a 51% history rewrite attack, even if the attacker has 99% =
of coins.</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
2 - The hardcoded checkpoints could be set by each bitcoin node client, not=
only Bitcoin Core. No matter if the checkpoints are different, only that t=
hey are frequent. They are there to prevent Long Range attacks. Checkpoints=
are public just like the rest of
the software, they don't require any trust. A bad checkpoint would be dete=
cted by the community.</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
3 - There are several PoS coins working just now and as far as I know they =
don't have any problem. NXT coin implements the moving checkpoint system an=
d others the hardcoded checkpoints. </div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
4 - In any given block, only one staker gets the authorization to create th=
at block, so other stakers can't spam the network with many different block=
s as they are illegal. </div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
5 - The block explorer is only required during a 51% attack, and only for n=
odes that are updating blocks during the attack. Updated nodes are protecte=
d thanks to the moving checkpoints.</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
Regards,</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> Oscar Lafarga <ote=
ch47@gmail.com><br>
<b>Sent:</b> Tuesday, July 16, 2019 22:35<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>
<div dir=3D"ltr">Hi Kenshiro,<br>
<br>
I don't think your proposal would require any changes to the Bitcoin Core i=
mplementation. This system you describe seems like it would operate as an i=
ndependent addition, rather than an alternative to the Proof of Work consen=
sus 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 th=
e current network. Also, without the constraints that PoW places on block c=
reation, you increase the vector
space for attacks since it is trivial to spam blocks to node on the networ=
k (see
<a href=3D"https://en.wikipedia.org/wiki/Sybil_attack#">Sybil attack</a>).<=
br>
<br>
I believe many other software projects have tried similar checkpointing sch=
emes that have resulted in hard forks or overall weakened consensus. I have=
n't dug too deeply, but I'm not aware of any cases where these schemes acco=
mplish anything useful to improve
the bitcoin network.<br>
<br>
Best,</div>
<br>
<div class=3D"x_gmail_quote">
<div dir=3D"ltr" class=3D"x_gmail_attr">On Tue, Jul 16, 2019 at 5:33 AM Ken=
shiro [] via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
</div>
<blockquote class=3D"x_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; col=
or:rgb(0,0,0)">
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<p style=3D"margin:0px; padding:0px 0px 0.25em; font-size:14px; font-family=
:"Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-co=
lor:rgb(255,255,255)">
Hi,</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,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 corre=
ctly implemented could be 100% secure against all 51% history rewrite attac=
ks. 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:&qu=
ot;Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<span style=3D"margin:0px">- Hardcoded checkpoints:</span><span> </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:&qu=
ot;Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,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:&qu=
ot;Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,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:&qu=
ot;Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,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 =
would be unable to use the coins to do any history rewrite attack. The atta=
cker 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:&qu=
ot;Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px 0px; font-size:14px; font-family=
:"Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-co=
lor:rgb(255,255,255)">
What do you think? :)</p>
<p style=3D"margin:0px; padding:0.25em 0px 0px; font-size:14px; font-family=
:"Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-co=
lor:rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px 0px; font-size:14px; font-family=
:"Noto Sans",Arial,sans-serif; color:rgb(26,26,27); background-co=
lor:rgb(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"x_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>
</div>
</div>
</body>
</html>
--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_--
|