summaryrefslogtreecommitdiff
path: root/37/1802f9f521ae4b86a6ffbb95ef3b12dc1726b4
blob: bb0a84cbb77b4fac4ac4df58fba957a4ce47b889 (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
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
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
Return-Path: <willtech@live.com.au>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 91558C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 03:45:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 6C6A987084
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 03:45:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 75WIhO6UkCoB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 03:45:12 +0000 (UTC)
X-Greylist: delayed 00:34:07 by SQLgrey-1.7.6
Received: from APC01-PU1-obe.outbound.protection.outlook.com
 (mail-oln040092254083.outbound.protection.outlook.com [40.92.254.83])
 by hemlock.osuosl.org (Postfix) with ESMTPS id AFEE487079
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 03:45:11 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=KNb8etBE7PaJhxiCSD8lYPbknMH8QfcGbl9+5SkvzJpAtBfDciEE/5QmpWEIGDnWoZfJgKi/mA2nmna9KV6nD6YW7d6eL8BL6ETh6LD03BKaSyflgMkJzCjb9jUwqvvPxqmtgHUhAs6wXMPcC88vuYB1YLUlj6UYrJRXLrCePglxsQbU6LZBXKPW2Z87cNgeJETOf6+2sfRdUQXxJmH0NAJgOzDjgNxGvFEi2m2sXHscUBGtROQO20Vy8T5Z6NIBbytPMiB4matraKTIpWP/G5jO/a4YSQeKcZwHpjKVeGe8smm50opXB+dZ+dd/6hNDYzPD5Q/Ui4p1yxbdMrPp/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1o+KG908f5cQg4YHPAhLCse+zPYnQcojCAP4i52Uk+U=;
 b=X6LfaT+qkj4seZQPgqwskzLNHknz5tU/09VT84qHGgZ7XEBiVDjc6Ea1OnXOKgIXB5mFMefaoykzshsiDUetbIRdlK8dCE7jf6sABEGuXHE9aaC+BoBrOWmmAzYOkTK5GadQS/jwntwjUDerE9U1Rr0kOLhsNuV0bwZcvhq/E7Ektfbvqdkj5ZMG2R55W848Mbm6TYa1Zs4uJyQXDC2z7FGViaaOC59A3s8UlJTrxHDQ9jp90UUvq7vGklFI15OciqNFakUfiGvI0l8197+v32u+6bI9iN+g2hiKy4E5AeCwy6UgP2cD2yVdzKOUBuRDYB0x00q0jHlKCMlvQQ3SEg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
Received: from SG2APC01FT024.eop-APC01.prod.protection.outlook.com
 (2a01:111:e400:7ebd::50) by
 SG2APC01HT064.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::295)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Tue, 29 Sep
 2020 03:10:36 +0000
Received: from PSXP216MB0967.KORP216.PROD.OUTLOOK.COM (10.152.250.51) by
 SG2APC01FT024.mail.protection.outlook.com (10.152.250.185) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3412.21 via Frontend Transport; Tue, 29 Sep 2020 03:10:36 +0000
Received: from PSXP216MB0967.KORP216.PROD.OUTLOOK.COM
 ([fe80::7824:d690:5506:7f95]) by PSXP216MB0967.KORP216.PROD.OUTLOOK.COM
 ([fe80::7824:d690:5506:7f95%8]) with mapi id 15.20.3412.029; Tue, 29 Sep 2020
 03:10:36 +0000
From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>, Mike Brooks
 <f@in.st.capital>
Thread-Topic: [bitcoin-dev] Floating-Point Nakamoto Consensus
Thread-Index: AQHWkzTDRX06cyQol02+jyZ664P+sql+74xp
Date: Tue, 29 Sep 2020 03:10:36 +0000
Message-ID: <PSXP216MB0967356F976C35E9D1C5A5EC9D320@PSXP216MB0967.KORP216.PROD.OUTLOOK.COM>
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
In-Reply-To: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:D21F0FC69498A8EE0917DC1E091E220B1169ACB7F27A129D8EF1C6A78A3321A5;
 UpperCasedChecksum:DE8689A99E253EDD05EDF7B83C3D05658BEB624AC49E7CADFD1298C4FE0AFAAC;
 SizeAsReceived:6908; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [jMazCu4uEbWNOahT/MUJdQtb1b91/DEb]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 04594707-bf8f-4e03-20d3-08d864253c6a
x-ms-traffictypediagnostic: SG2APC01HT064:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Rwks7quhLH2TOTf8dqbpFnQTReNKaOBqtekM3e4Rn0vTOJNJks8NC7/KBv/fdovaRUrpef6uj4gSlz4Y/m5uFd4shGyFiZ7FP6Cr5pkPmqrRK40UAVpC7Flx1pdXbTmVDJMkzAiuJeuVWHUc6PZeaVdnzOtijwBuy34lv8Q5Czto7/vEOsCf1ejemfLdmeu2RiqoLeKnlBxrEf6omx6NuBLjKLM7DujeiSrJ1QOMQ/bwwB2KKoBl7Gmcqz5Q1mU6
x-ms-exchange-antispam-messagedata: R3RLJz3AbSANAUXzNByqcdgU/Rc/u0cj2X6ZHwfkSzaSJ6xAVuBu0pF0TKuw2UMzmE7Ar6liCjz6dF6ajfVAJe10+fe2xnJqcDTB4hInw2zhMHVFgFv2YuXJxklQNGT/Y9WUF/Rz9r6mV7Z4WRdciQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
 boundary="_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: SG2APC01FT024.eop-APC01.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 04594707-bf8f-4e03-20d3-08d864253c6a
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2020 03:10:36.2581 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT064
X-Mailman-Approved-At: Tue, 29 Sep 2020 07:29:39 +0000
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
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: Tue, 29 Sep 2020 03:45:16 -0000

--_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Good Afternoon,

Re: [bitcoin-dev] Floating-Point Nakamoto Consensus

I note that the discussion thread for this proposal has previously received=
 HARD_NAK

I note in the whitepaper the following basic introduction of need:
>As a result anode will simply adopt the first solution seen, creating a ki=
nd of race condition.

The said race condition, it is not noted, is 'self-resolving' with the netw=
ork adopting the longest chain with the highest proof of work as any conten=
tious tip is built on. This is the proper reason for waiting for two confir=
mations for a transaction as a minimum proof of its inclusion in the blockc=
hain (without fraud), and for waiting for six confirmations before consider=
ing that a transaction is 'final'.

I take it that your work is intended to allow the network to decide immedia=
tely without waiting for a chain to be further extended, in that case, the =
solution should be as noted elsewhere to accept the higher proof of work wi=
th the greater precision proof. When comparing two competing blocks there i=
s an indirect reference to a higher proof of work due to the greater precis=
ion in the block hash, although the answer could have been arrived with few=
er attempts. As it is, the total proof of work is not directly calculated b=
ut is evaluated as the chain with more blocks being the chain with more pro=
of-of-work, whereas in the cases two blocks are received as alternates exte=
nding the same chain tip there is currently no method of comparison to dete=
rmine which of the blocks, and the correct tip is not chosen without furthe=
r proof-of-work to extend a tip. Resolving this reduces the network expense=
 of reorganisation in ordinary conditions but in the case of a network-spli=
t resolves nothing.

KING JAMES HRMH
Great British Empire

Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills

et al.


Willtech
www.willtech.com.au
www.go-overt.com
and other projects

earn.com/willtech
linkedin.com/in/damianwilliamson


m. 0487135719
f. 61261470192


----
________________________________
From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf=
 of Mike Brooks via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Friday, 25 September 2020 5:40 AM
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Floating-Point Nakamoto Consensus

  Hey Everyone,

 A lot of work has gone into this paper, and the current revision has been =
well received and there is a lot of excitement on this side to be sharing i=
t with you today. There are so few people that truly understand this topic,=
 but we are all pulling in the same direction to make Bitcoin better and it=
 shows.  It is wildly underrated that future proofing was never really a co=
nsideration in the initial design - but here we are a decade later with ama=
zing solutions like SegWit which gives us a real future-proofing framework.=
  The fact that future-proofing was added to Bitcoin with a softfork gives =
me goosebumps. I'd just like to take the time to thank the people who worke=
d on SegWit and it is an appreciation that comes up in conversation of how =
difficult and necessary that process was, and this appreciation may not be =
vocalized to the great people who worked on it. The fact that Bitcoin keeps=
 improving and is able to respond to new threats is nothing short of amazin=
g - thank you everyone for a great project.

This current proposal really has nothing to do with SegWit - but it is an u=
pdate that will make the network a little better for the future, and we hop=
e you enjoy the paper.

PDF:
https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/Floa=
ting-Point%20Nakamoto%20Consensus.pdf

Pull Request:
https://github.com/bitcoin/bitcoin/pull/19665/files

---



Floating-Point Nakamoto Consensus


Abstract =97 It has been shown that Nakamoto Consensus is very useful in th=
e formation of long-term global agreement =97 and has issues with short-ter=
m disagreement which can lead to re-organization (=93or-org=94) of the bloc=
kchain.  A malicious miner with knowledge of a specific kind of denial-of-s=
ervice (DoS) vulnerability can gain an unfair advantage in the current Bitc=
oin network, and can be used to undermine the security guarantees that deve=
lopers rely upon.  Floating-Point Nakamoto consensu makes it more expensive=
 to replace an already mined block vs. creation of a new block, and by reso=
lving ambiguity of competition solutions it helps achieve global consumers =
more quickly.  A floating-point fitness test strongly incentivises the corr=
ect network behavior, and prevents disagreement from ever forming in the fi=
rst place.

Introduction

The Bitcoin protocol was created to provide a decentralized consensus on a =
fully distributed p2p network.  A problem arises when more than one proof-o=
f-work is presented as the next solution block in the blockchain.  Two solu=
tions of the same height are seen as authoritative equals which is the basi=
s of a growing disagreement. A node will adopt the first solution seen, as =
both solutions propagate across the network a race condition of disagreemen=
t is formed. This race condition can be controlled by byzentiene fault inje=
ction commonly referred to as an =93eclipsing=94 attack.  When two segments=
 of the network disagree it creates a moment of weakness in which less than=
 51% of the network=92s computational resources are required to keep the ne=
twork balanced against itself.

Nakamoto Consensus

Nakamoto Consensus is the process of proving computational resources in ord=
er to determine eligibility to participate in the decision making process. =
 If the outcome of an election were based on one node (or one-IP-address-on=
e-vote), then representation could be subverted by anyone able to allocate =
many IPs. A consensus is only formed when the prevailing decision has the g=
reatest proof-of-work effort invested in it. In order for a Nakamoto Consen=
sus to operate, the network must ensure that incentives are aligned such th=
at the resources needed to subvert a proof-of-work based consensus outweigh=
 the resources gained through its exploitation. In this consensus model, th=
e proof-of-work requirements for the creation of the next valid solution ha=
s the exact same cost as replacing the current solution. There is no penalt=
y for dishonesty, and this has worked well in practice because the majority=
 of the nodes on the network are honest and transparent, which is a substan=
tial barrier for a single dishonest node to overcome.


A minimal network peer-to-peer structure is required to support Nakamoto Co=
nesus, and for our purposes this is entirely decentralized. Messages are br=
oadcast on a best-effort basis, and nodes can leave and rejoin the network =
at will, accepting the longest proof-of-work chain as proof of what happene=
d while they were gone.  This design makes no guarantees that the peers con=
nected do not misrepresent the network or so called =93dishonest nodes.=94 =
Without a central authority or central view - all peers depend on the data =
provided by neighboring peers - therefore a dishonest node can continue unt=
il a peer is able to make contact an honest node.

Security

In this threat model let us assume a malicious miner possesses knowledge of=
 an unpatched DoS vulnerability (=930-day=94) which will strictly prevent h=
onest nodes from communicating to new members of the network - a so-called =
=93total eclipse.=94  The kind of DoS vulnerability needed to conduct an ec=
lipse does not need to consume all CPU or computaitly ability of target nod=
es - but rather prevent target nodes from forming new connections that woul=
d undermine the eclipsing effect. These kinds of DoS vulnerabilities are so=
mewhat less substional than actually knocking a powerful-mining node offlin=
e.  This class of attacks are valuable to an adversary because in order for=
 an honest node to prove that a dishonest node is lying - they would need t=
o form a connection to a segment of the network that isn=92t entirely suppr=
essed. Let us assume a defense-in-depth strategy and plan on this kind of f=
ailure.


Let us now consider that the C++ Bitcoind has a finite number of worker thr=
eads and a finite number of connections that can be serviced by these worke=
rs.  When a rude client occupies all connections - then a pidgin-hole princ=
iple comes into play. If a network's maximum capacity for connection handle=
rs =91k=92, is the sum of all available worker threads for all nodes in the=
 network, establishing =91k+1=92 connections by the pidgin-hole principle w=
ill prevent any new connections from being formed by honest nodes - thereby=
 creating a perfect eclipse for any new miners joining the network would on=
ly be able to form connections with dishonest nodes.


Now let=92s assume a dishonest node is modified in two ways - it increases =
the maximum connection handles to hundreds of thousands instead of the curr=
ent value which is about 10. Then this node is modified to ignore any solut=
ion blocks found by honest nodes - thus forcing the dishonest side of the n=
etwork to keep searching for a competitive-solution to split the network in=
 two sides that disagree about which tip of the chain to use.  Any new solu=
tion propagates through nodes one hop at a time. This propagation can be pr=
edicted and shaped by dishonest non-voting nodes that are being used to pas=
s messages for honest nodes.


At this point an attacker can expedite the transmission of one solution, wh=
ile slowing another. If ever a competing proof-of-work is broadcasted to th=
e network, the adversary will use their network influence to split knowledg=
e of the proof-of-work as close to =BD as possible. If the network eclipse =
is perfect then an adversary can leverage an eigen-vector of computational =
effort to keep the disagreement in balance for as long as it is needed. No =
mechanism is stopping the attacker from adding additional computation resou=
rces or adjusting the eclipsing effect to make sure the system is in balanc=
e.   As long as two sides of the network are perfectly in disagreement and =
generating new blocks - the attacker has intentionally created a hard-fork =
against the will of the network architects and operators. The disagreement =
needs to be kept open until the adversary=92s transactions have been valida=
ted on the honest chain - at which point the attacker will add more nodes t=
o the dishonest chain to make sure it is the ultimate winner - thus replaci=
ng out the honest chain with the one generated by dishonest miners.


This attack is convenient from the adversary=92s perspective,  Bitcoin bein=
g a broadcast network advertises the IP addresses of all active nodes - and=
 Shodan and the internet scanning project can find all passive nodes respon=
ding on TCP 8333.  This should illuminate all honest nodes on the network, =
and even honest nodes that are trying to obscure themselves by not announci=
ng their presence.  This means that the attacker doesn=92t need to know exa=
ctly which node is used by a targeted exchange - if the attacker has subdue=
d all nodes then the targeted exchange must be operating a node within this=
 set of targeted honest nodes.


During a split in the blockchain, each side of the network will honor a sep=
arate merkel-tree formation and therefore a separate ledger of transactions=
. An adversary will then broadcast currency deposits to public exchanges, b=
ut only on the weaker side, leaving the stronger side with no transaction f=
rom the adversary. Any exchange that confirms one of these deposits is rely=
ing upon nodes that have been entirely eclipsed so that they cannot see the=
 competing chain - at this point anyone looking to confirm a transaction is=
 vulnerable to a double-spend. With this currency deposited on a chain that=
 will become ephemeral, the attacker can wire out the account balance on a =
different blockchain - such as Tether which is an erc20 token on the Ethere=
um network which would be unaffected by this attack.  When the weaker chain=
 collapses, the transaction that the exchange acted upon is no longer codif=
ied in Bitcoin blockchain's global ledger, and will be replaced with a vers=
ion of the that did not contain these deposits.


Nakamoto Consensus holds no guarantees that it=92s process is deterministic=
.  In the short term, we can observe that the Nakamoto Consensus is empiric=
ally non-deterministic which is evident by re-organizations (re-org) as a m=
ethod of resolving disagreements within the network.   During a reorganizat=
ion a blockchain network is at its weakest point, and a 51% attack to take =
the network becomes unnecessary. An adversary who can eclipse honest hosts =
on the network can use this as a means of byzantine fault-injection to disr=
upt the normal flow of messages on the network which creates disagreement b=
etween miners.


DeFi (Decentralized Finance) and smart-contract obligations depend on netwo=
rk stability and determinism.  Failure to pay contracts, such as what happe=
ned on =93black thursday=94 resulted in secured loans accidentally falling =
into redemption.  The transactions used by a smart contract are intended to=
 be completed quickly and the outcome is irreversible.  However, if the blo=
ckchain network has split then a contract may fire and have it=92s side-eff=
ects execute only to have the transaction on the ledger to be replaced.  An=
other example is that a hard-fork might cause the payer of a smart contract=
 to default - as the transaction that they broadcasted ended up being on th=
e weaker chain that lost. Some smart contracts, such as collateral backed l=
oans have a redemption clause which would force the borrower on the loan to=
 lose their deposit entirely.


With two sides of the network balanced against each other - an attacker has=
 split the blockchain and this hard-fork can last for as long as the attack=
er is able to exert the computational power to ensure that proof-of-work bl=
ocks are regularly found on both sides of the network.  The amount of resou=
rces needed to balance the network against itself is far less than a 51% at=
tack - thereby undermining the security guarantees needed for a decentraliz=
ed untrusted payment network to function.  An adversary with a sufficiently=
 large network of dishonest bots could use this to take a tally of which mi=
ners are participating in which side of the network split. This will create=
 an attacker-controlled hard fork of the network with two mutually exclusiv=
e merkle trees. Whereby the duration of this split is arbitrary, and the de=
cision in which chain to collapse is up to the individual with the most IP =
address, not the most computation.


In Satoshi Nakamoto=92s original paper it was stated that the electorate sh=
ould be represented by computational effort in the form of a proof-of-work,=
 and only these nodes can participate in the consues process.  However, the=
 electorate can be misled by non-voting nodes which can reshape the network=
 to benefit an individual adversary.

Chain Fitness

Any solution to byzantine fault-injection or the intentional formation of d=
isagreements must be fully decentralized. A blockchain is allowed to split =
because there is ambiguity in the Nakamoto proof-of-work, which creates the=
 environment for a race-condition to form. To resolve this, Floating-Point =
Nakamoto Consensus makes it increasingly more expensive to replace the curr=
ent winning block. This added cost comes from a method of disagreement reso=
lution where not every solution block is the same value, and a more-fit sol=
ution is always chosen over a weaker solution. Any adversary attempting to =
have a weaker chain to win out would have to overcome a kind of relay-race,=
 whereby the winning team=92s strength is carried forward and the loser wil=
l have to work harder and harder to maintain the disagreement.  In most cas=
es Floating-Point Nakamoto Consensus will prevent a re-org blockchain from =
ever going past a single block thereby expediting the formation of a global=
 consensus.  Floating-Point Nakamoto Consensus cements the lead of the winn=
er and to greatly incentivize the network to adopt the dominant chain no ma=
tter how many valid solutions are advertised, or what order they arrive.


The first step in Floating-Point Nakamoto Consensus is that all nodes in th=
e network should continue to conduct traditional Nakamoto Consensus and the=
 formation of new blocks is dictated by the same zero-prefix proof-of-work =
requirements.  If at any point there are two solution blocks advertised for=
 the same height - then a floating-point fitness value is calculated and th=
e solution with the higher fitness value is the winner which is then propag=
ated to all neighbors. Any time two solutions are advertised then a re-org =
is inevitable and it is in the best interest of all miners to adopt the mos=
t-fit block, failing to do so risks wasting resources on a mining of a bloc=
k that would be discarded.  To make sure that incentives are aligned, any z=
ero-prefix proof of work could be the next solution, but now in order to re=
place the current winning solution an adversary would need a zero-prefix bl=
ock that is also more fit that the current solution - which is much more co=
mputationally expensive to produce.

Any changes to the current tip of the blockchain must be avoided as much as=
 possible. To avoid thrashing between two or more competitive solutions, ea=
ch replacement can only be done if it is more fit, thereby proving that it =
has an increased expense.  If at any point two solutions of the same height=
 are found it means that eventually some node will have to replace their ti=
p - and it is better to have it done as quickly as possible so that consens=
us is maintained.


In order to have a purely decentralized solution, this kind of agreement mu=
st be empirically derived from the existing proof-of-work so that it is uni=
versally and identically verifiable by all nodes on the network.  Additiona=
lly, this fitness-test evaluation needs to ensure that no two competing sol=
utions can be numerically equivalent.


Let us suppose that two or more valid solutions will be proposed for the sa=
me block.  To weigh the value of a given solution, let's consider a solutio=
n for block 639254, in which the following hash was proposed:

    00000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f8


There are 19 zeros, and the remaining hash in base 16 starts with 9e3 and e=
nds with f8.  This can value can be represented in floating point as:

    19.847052573336114130069196154809453027792121882588614904


To simplify further lets give this block a single whole number to represent=
 one complete solution, and use a rounded floating-point value to represent=
 some fraction of additional work exerted by the miner.

   1.847


Now let us suppose that a few minutes later another solution is advertised =
to the network shown in base16 below:

    000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2


The solution above also has 19 prefixed zeros, and is being broadcast for t=
he same blockheight value of 639254 - and a fitness score of 1.282.  With N=
akamoto Consensus both of these solutions would be equivalent and a given n=
ode would adopt the one that it received first.  In Floating-Post Nakamoto =
Consensus, we compare the fitness scores and keep the highest.  In this cas=
e no matter what happens - some nodes will have to change their tip and a f=
itness test makes sure this happens immediately.


With both solutions circulating in the network - any node who has received =
both proof-of-works should know 1.847 is the current highest value, and sho=
uldn=92t need to validate any lower-valued solution.  In fact this fitness =
value has a high degree of confidence that it won=92t be unseated by a larg=
er value - being able to produce a proof-of-work with 19 0=92s and a decima=
l component greater than 0.847 is non-trivial.  As time passes any nodes th=
at received a proof-of-work with a value 1.204 - their view of the network =
should erode as these nodes adopt the 1.847 version of the blockchain.

All nodes are incentivized to support the solution with the highest fitness=
 value - irregardless of which order these proof-of-work were validated. Mi=
ners are incentivized to support the dominant chain which helps preserve th=
e global consensus.


Let us assume that the underlying cryptographic hash-function used to gener=
ate a proof-of-work is an ideal primitive, and therefore a node cannot forc=
e the outcome of the non-zero component of their proof-of-work.  Additional=
ly if we assume an ideal cipher then the fitness of all possible solutions =
is gaussian-random. With these assumptions then on average a new solution w=
ould split the keyspace of remaining solutions in half.  Given that the wor=
k needed to form a  new block remains a constant at 19 blocks for this peri=
od - it is cheaper to produce a N+1 block that has any floating point value=
 as this is guaranteed to be adopted by all nodes if it is the first soluti=
on.  To leverage a chain replacement on nodes conducting Floating-Point Nak=
amoto Consensus a malicious miner would have to expend significantly more r=
esources.


Each successive n+1 solution variant of the same block-height must therefor=
e on average consume half of the remaining finite keyspace. Resulting in a =
the n+1 value not only needed to overcome the 19 zero prefix, but also the =
non-zero fitness test.   It is possible for an adversary to waste their tim=
e making a 19 where n+1 was not greater, at which point the entire network =
will have had a chance to move on with the next solution.  With inductive r=
easoning, we can see that a demissiniong keyspace increases the amount of w=
ork needed to find a solution that also meets this new criteria.


Now let us assume a heavily-fragmented network where some nodes have gotten=
 one or both of the solutions.  In the case of nodes that received the proo=
f-of-work solution with a fitness of 1.847, they will be happily mining on =
this version of the blockchain. The nodes that have gotten both 1.847 and .=
240 will still be mining for the 1.847 domainite version, ensuring a domina=
nt chain.  However, we must assume some parts of the network never got the =
message about 1.847 proof of work, and instead continued to mine using a va=
lue of 1.240 as the previous block.   Now, let=92s say this group of isolat=
ed miners manages to present a new conflicting proof-of-work solution for 6=
39255:


     000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091a6


The above base16 block has a fitness score of 1.532  The fitness value for =
the previous block 639254 is added together:


     2.772 =3D 1.240 + 1.532


In this specific case, no other solution has been broadcast for block heigh=
t 639255 - putting the weaker branch in the lead.  If the weaker branch is =
sufficiently lucky, and finds a solution before the dominant branch then th=
is solution will have a higher overall fitness score, and this solution wil=
l propagate as it has the higher value.  This is also important for transac=
tions on the network as they benefit from using the most recently formed bl=
ock - which will have the highest local fitness score at the time of its di=
scovery.  At this junction, the weaker branch has an opportunity to prevail=
 enterally thus ending the split.


Now let us return to the DoS threat model and explore the worst-case scenar=
io created by byzantine fault injection. Let us assume that both the weaker=
 group and the dominant group have produced competing proof-of-work solutio=
ns for blocks 639254 and 639255 respectively.  Let=92s assume that the domi=
nant group that went with the 1.847 fitness score - also produces a solutio=
n with a similar fitness value and advertises the following solution to the=
 network:


0000000000000000000455207e375bf1dac0d483a7442239f1ef2c70d050c113

19.414973649464574877549198290879237036867705594421756179

or

3.262 =3D 1.847 + 1.415


A total of 3.262 is still dominant over the lesser 2.772 - in order to over=
come this - the 2nd winning block needs to make up for all of the losses in=
 the previous block.  In this scenario, in order for the weaker chain to su=
pplant the dominant chain it must overcome a -0.49 point deficit. In tradit=
ional Nakamoto Consensus the nodes would see both forks as authoritative eq=
uals which creates a divide in mining capacity while two groups of miners s=
earch for the next block.  In Floating-Point Nakamoto Consensus any nodes r=
eceiving both forks, would prefer to mine on the chain with an overall fitn=
ess score of +3.262 - making it even harder for the weaker chain to find mi=
ners to compete in any future disagreement, thereby eroding support for the=
 weaker chain. This kind of comparison requires an empirical method for det=
ermining fitness by miners following the same same system of rules will ins=
ure a self-fulfilled outcome.  After all nodes adopt the dominant chain nor=
mal Nakamoto Consuess can resume without having to take into consideration =
block fitness. This example shows how disagreement can be resolved more qui=
ckly if the network has a mechanism to resolve ambiguity and de-incentivise=
 dissent.

Soft Fork

Blockchain networks that would like to improve the consensus generation met=
hod by adding a fitness test should be able to do so using a =93Soft Fork=
=94 otherwise known as a compatible software update.  By contrast a =93Hard=
-Fork=94 is a separate incompatible network that does not form the same con=
sensus.  Floating-Point Nakamoto Consensus can be implemented as a soft-for=
k because both patched, and non-patched nodes can co-exist and non-patched =
nodes will benefit from a kind of herd immunity in overall network stabilit=
y.  This is because once a small number of nodes start following the same r=
ules then they will become the deciding factor in which chain is chosen.  C=
lients that are using only traditional Nakamoto Consensus will still agree =
with new clients over the total chain length. Miners that adopt the new str=
ategy early, will be less likely to lose out on mining invalid solutions.

Conclusion

Floating-Point Nakamoto consensus allows the network to form a consensus mo=
re quickly by avoiding ambiguity allowing for determinism to take hold. Bit=
coin has become an essential utility, and attacks against our networks must=
 be avoided and adapting, patching and protecting the network is a constant=
 effort. An organized attack against a cryptocurrency network will undermin=
e the guarantees that blockchain developers are depending on.


Any blockchain using Nakamoto Consensus can be modified to use a fitness co=
nstraint such as the one used by a Floating-Point Nakamoto Consensus.  An e=
xample implementation has been written and submitted as a PR to the bitcoin=
 core which is free to be adapted by other networks.






A complete implementation of Floating-Point Nakamoto consensus is in the fo=
llowing pull request:

https://github.com/bitcoin/bitcoin/pull/19665/files


Paper:

https://github.com/in-st/Floating-Point-Nakamoto-Consensus

https://in.st.capital<https://in.st.capital/>


--_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt=
; color: rgb(0, 0, 0);">Good Afternoon,</span></div>
<div style=3D""><br>
</div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">Re: [bitcoin-dev] Floating-Point Na=
kamoto Consensus</span></div>
<div style=3D""><br>
</div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">I note that the discussion thread f=
or this proposal
</span><span style=3D"font-family: Calibri, Helvetica, sans-serif; font-siz=
e: 12pt; color: rgb(0, 0, 0);">has previously received HARD_NAK
</span><br>
</div>
<div style=3D""><br>
</div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">I note in the whitepaper the follow=
ing basic introduction of need:</span><br>
</div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">&gt;As a result a</span><span style=
=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rg=
b(0, 0, 0);">node will simply adopt the first
 solution seen, creating a kind of race condition.</span></div>
<div style=3D""><br>
</div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">The said race condition, it is not =
noted, is 'self-resolving' with the network adopting the longest chain with=
 the highest proof of work as any contentious
 tip is built on. This is the proper reason for waiting for two confirmatio=
ns for a transaction as a minimum proof of its inclusion in the blockchain =
(without fraud), and for waiting for six confirmations before considering t=
hat a transaction is 'final'.</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">I take it that your work is intende=
d to allow the network to decide immediately without waiting for a chain to=
 be further extended, in that case,
 the solution should be as noted elsewhere to accept the higher proof of wo=
rk with the greater precision proof. When comparing two competing blocks th=
ere is an indirect reference to a higher proof of work due to the greater p=
recision in the block hash, although
 the answer could have been arrived with fewer attempts. As it is, the tota=
l proof of work is not directly calculated but is evaluated as the chain wi=
th more blocks being the chain with more proof-of-work, whereas in the case=
s two blocks are received as alternates
 extending the same chain tip there is currently no method of comparison to=
 determine which of the blocks, and the correct tip is not chosen without f=
urther proof-of-work to extend a tip. Resolving this reduces the network ex=
pense of reorganisation in ordinary
 conditions but in the case of a network-split resolves nothing.<br>
</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">KING JAMES HRMH</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);">Great British Empire<br>
</span></div>
<div style=3D""><span style=3D"font-family: Calibri, Helvetica, sans-serif;=
 font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div id=3D"Signature">
<div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<div>Regards,
<div>The Australian</div>
<div>LORD HIS EXCELLENCY JAMES HRMH (&amp; HMRH)</div>
<div>of Hougun Manor &amp; Glencoe &amp; British Empire</div>
<div>MR. Damian A. James Williamson</div>
<div>Wills</div>
<div><br>
</div>
<div>et al.</div>
<div><br>
</div>
<div>&nbsp;</div>
<div>Willtech</div>
<div>www.willtech.com.au</div>
<div>www.go-overt.com</div>
<div>and other projects</div>
<div>&nbsp;</div>
<div>earn.com/willtech</div>
<div>linkedin.com/in/damianwilliamson</div>
<div><br>
</div>
<div><br>
</div>
<div>m. 0487135719</div>
<div>f. 61261470192</div>
<div><br>
</div>
<div><br>
</div>
----</div>
</div>
</div>
</div>
</div>
<div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> bitcoin-dev &lt;bit=
coin-dev-bounces@lists.linuxfoundation.org&gt; on behalf of Mike Brooks via=
 bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Sent:</b> Friday, 25 September 2020 5:40 AM<br>
<b>To:</b> bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Subject:</b> [bitcoin-dev] Floating-Point Nakamoto Consensus</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr">&nbsp; Hey Everyone,
<div><br>
</div>
<div>&nbsp;A lot of work has gone into this paper, and the current revision=
 has been well received and there is a lot of excitement on this side to&nb=
sp;be sharing it with you today. There are so few people that truly underst=
and this topic, but we are all pulling in
 the same direction to make Bitcoin better and it shows.&nbsp; It is wildly=
 underrated that future proofing was never really a consideration&nbsp;in t=
he initial&nbsp;design - but here we are a decade later with amazing soluti=
ons like SegWit which&nbsp;gives us a real future-proofing
 framework.&nbsp; The fact that future-proofing was added to Bitcoin with a=
 softfork gives me goosebumps.&nbsp;I'd just like to take the time to thank=
 the people who worked on SegWit and it is an appreciation&nbsp;that comes =
up in conversation of how difficult and necessary
 that process was,&nbsp;and this appreciation may not be vocalized to the g=
reat people who worked on it. The fact that Bitcoin keeps improving and is =
able to respond to new threats is nothing short of amazing - thank you ever=
yone for a great project.</div>
<div><br>
</div>
<div>This current proposal really has nothing to do with&nbsp;SegWit - but =
it is an update that will make the network a little better for the future, =
and we hope you enjoy the paper.&nbsp;</div>
<div><br>
</div>
<div>PDF:<br>
<a href=3D"https://github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/=
master/Floating-Point%20Nakamoto%20Consensus.pdf" target=3D"_blank">https:/=
/github.com/in-st/Floating-Point-Nakamoto-Consensus/blob/master/Floating-Po=
int%20Nakamoto%20Consensus.pdf</a></div>
<div>&nbsp;</div>
<div>Pull Request:<br>
<span id=3D"x_gmail-m_2766209350405513116gmail-docs-internal-guid-e08d4203-=
7fff-1140-7022-8ecfe80e9fea"><a href=3D"https://github.com/bitcoin/bitcoin/=
pull/19665/files" target=3D"_blank" style=3D"text-decoration-line:none"><sp=
an style=3D"font-size:11pt; font-family:Arial; background-color:transparent=
; font-variant-numeric:normal; font-variant-east-asian:normal; text-decorat=
ion-line:underline; vertical-align:baseline; white-space:pre-wrap">https://=
github.com/bitcoin/bitcoin/pull/19665/files</span></a></span>&nbsp;&nbsp;<b=
r>
</div>
<div><br>
</div>
<div>---</div>
<div><br>
</div>
<div><span id=3D"x_gmail-m_2766209350405513116gmail-docs-internal-guid-77a2=
432b-7fff-62c3-0753-fe93652ca512"><br>
<p dir=3D"ltr" style=3D"line-height:1.38; text-align:center; margin-top:0pt=
; margin-bottom:0pt">
<span style=3D"font-size:14pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">Floating-Point Naka=
moto Consensus</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:9pt; font-family:Arial; color:rgb(0,0,0); backgrou=
nd-color:transparent; font-weight:700; font-variant-numeric:normal; font-va=
riant-east-asian:normal; vertical-align:baseline; white-space:pre-wrap">Abs=
tract =97
</span><span style=3D"font-size:9pt; font-family:Arial; color:rgb(0,0,0); b=
ackground-color:transparent; font-variant-numeric:normal; font-variant-east=
-asian:normal; vertical-align:baseline; white-space:pre-wrap">It has been s=
hown that Nakamoto Consensus is very
 useful in the formation of long-term global agreement =97 and has issues w=
ith short-term disagreement which can lead to re-organization (=93or-org=94=
) of the blockchain.&nbsp; A malicious miner with knowledge of a specific k=
ind of denial-of-service (DoS) vulnerability
 can gain an unfair advantage in the current Bitcoin network, and can be us=
ed to undermine the security guarantees that developers rely upon.&nbsp; Fl=
oating-Point Nakamoto consensu makes it more expensive to replace an alread=
y mined block vs. creation of a new block,
 and by resolving ambiguity of competition solutions it helps achieve globa=
l consumers more quickly.&nbsp; A floating-point fitness test strongly ince=
ntivises the correct network behavior, and prevents disagreement from ever =
forming in the first place.</span></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Introduction</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">The
 Bitcoin protocol was created to provide a decentralized consensus on a ful=
ly distributed p2p network.&nbsp; A problem arises when more than one proof=
-of-work is presented as the next solution block in the blockchain.&nbsp; T=
wo solutions of the same height are seen as
 authoritative equals which is the basis of a growing disagreement. A node =
will adopt the first solution seen, as both solutions propagate across the =
network a race condition of disagreement is formed. This race condition can=
 be controlled by byzentiene fault
 injection commonly referred to as an =93eclipsing=94 attack.&nbsp; When tw=
o segments of the network disagree it creates a moment of weakness in which=
 less than 51% of the network=92s computational resources are required to k=
eep the network balanced against itself.&nbsp;</span></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Nakamoto
 Consensus</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Nakamoto
 Consensus is the process of proving computational resources in order to de=
termine eligibility to participate in the decision making process.&nbsp; If=
 the outcome of an election were based on one node (or one-IP-address-one-v=
ote), then representation could be subverted
 by anyone able to allocate many IPs. A consensus is only formed when the p=
revailing decision has the greatest proof-of-work effort invested in it. In=
 order for a Nakamoto Consensus to operate, the network must ensure that in=
centives are aligned such that the
 resources needed to subvert a proof-of-work based consensus outweigh the r=
esources gained through its exploitation. In this consensus model, the proo=
f-of-work requirements for the creation of the next valid solution has the =
exact same cost as replacing the
 current solution. There is no penalty for dishonesty, and this has worked =
well in practice because the majority of the nodes on the network are hones=
t and transparent, which is a substantial barrier for a single dishonest no=
de to overcome.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">A
 minimal network peer-to-peer structure is required to support Nakamoto Con=
esus, and for our purposes this is entirely decentralized. Messages are bro=
adcast on a best-effort basis, and nodes can leave and rejoin the network a=
t will, accepting the longest proof-of-work
 chain as proof of what happened while they were gone.&nbsp; This design ma=
kes no guarantees that the peers connected do not misrepresent the network =
or so called =93dishonest nodes.=94 Without a central authority or central =
view - all peers depend on the data provided
 by neighboring peers - therefore a dishonest node can continue until a pee=
r is able to make contact an honest node.</span></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Security&nbsp;</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">In
 this threat model let us assume a malicious miner possesses knowledge of a=
n unpatched DoS vulnerability (=930-day=94) which will strictly prevent hon=
est nodes from communicating to new members of the network - a so-called =
=93total eclipse.=94&nbsp; The kind of DoS vulnerability
 needed to conduct an eclipse does not need to consume all CPU or computait=
ly ability of target nodes - but rather prevent target nodes from forming n=
ew connections that would undermine the eclipsing effect. These kinds of Do=
S vulnerabilities are somewhat less
 substional than actually knocking a powerful-mining node offline.&nbsp; Th=
is class of attacks are valuable to an adversary because in order for an ho=
nest node to prove that a dishonest node is lying - they would need to form=
 a connection to a segment of the network
 that isn=92t entirely suppressed. Let us assume a defense-in-depth strateg=
y and plan on this kind of failure.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Let
 us now consider that the C++ Bitcoind has a finite number of worker thread=
s and a finite number of connections that can be serviced by these workers.=
&nbsp; When a rude client occupies all connections - then a pidgin-hole pri=
nciple comes into play. If a network's
 maximum capacity for connection handlers =91k=92, is the sum of all availa=
ble worker threads for all nodes in the network, establishing =91k+1=92 con=
nections by the pidgin-hole principle will prevent any new connections from=
 being formed by honest nodes - thereby
 creating a perfect eclipse for any new miners joining the network would on=
ly be able to form connections with dishonest nodes.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Now
 let=92s assume a dishonest node is modified in two ways - it increases the=
 maximum connection handles to hundreds of thousands instead of the current=
 value which is about 10. Then this node is modified to ignore any solution=
 blocks found by honest nodes - thus
 forcing the dishonest side of the network to keep searching for a competit=
ive-solution to split the network in two sides that disagree about which ti=
p of the chain to use.&nbsp; Any new solution propagates through nodes one =
hop at a time. This propagation can be
 predicted and shaped by dishonest non-voting nodes that are being used to =
pass messages for honest nodes.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">At
 this point an attacker can expedite the transmission of one solution, whil=
e slowing another. If ever a competing proof-of-work is broadcasted to the =
network, the adversary will use their network influence to split knowledge =
of the proof-of-work as close to
 =BD as possible. If the network eclipse is perfect then an adversary can l=
everage an eigen-vector of computational effort to keep the disagreement in=
 balance for as long as it is needed. No mechanism is stopping the attacker=
 from adding additional computation
 resources or adjusting the eclipsing effect to make sure the system is in =
balance. &nbsp; As long as two sides of the network are perfectly in disagr=
eement and generating new blocks - the attacker has intentionally created a=
 hard-fork against the will of the network
 architects and operators. The disagreement needs to be kept open until the=
 adversary=92s transactions have been validated on the honest chain - at wh=
ich point the attacker will add more nodes to the dishonest chain to make s=
ure it is the ultimate winner - thus
 replacing out the honest chain with the one generated by dishonest miners.=
</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">This
 attack is convenient from the adversary=92s perspective,&nbsp; Bitcoin bei=
ng a broadcast network advertises the IP addresses of all active nodes - an=
d Shodan and the internet scanning project can find all passive nodes respo=
nding on TCP 8333.&nbsp; This should illuminate
 all honest nodes on the network, and even honest nodes that are trying to =
obscure themselves by not announcing their presence.&nbsp; This means that =
the attacker doesn=92t need to know exactly which node is used by a targete=
d exchange - if the attacker has subdued
 all nodes then the targeted exchange must be operating a node within this =
set of targeted honest nodes.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">During
 a split in the blockchain, each side of the network will honor a separate =
merkel-tree formation and therefore a separate ledger of transactions. An a=
dversary will then broadcast currency deposits to public exchanges, but onl=
y on the weaker side, leaving the
 stronger side with no transaction from the adversary. Any exchange that co=
nfirms one of these deposits is relying upon nodes that have been entirely =
eclipsed so that they cannot see the competing chain - at this point anyone=
 looking to confirm a transaction
 is vulnerable to a double-spend. With this currency deposited on a chain t=
hat will become ephemeral, the attacker can wire out the account balance on=
 a different blockchain - such as Tether which is an erc20 token on the Eth=
ereum network which would be unaffected
 by this attack.&nbsp; When the weaker chain collapses, the transaction tha=
t the exchange acted upon is no longer codified in Bitcoin blockchain's glo=
bal ledger, and will be replaced with a version of the that did not contain=
 these deposits.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Nakamoto
 Consensus holds no guarantees that it=92s process is deterministic.&nbsp; =
In the short term, we can observe that the Nakamoto Consensus is empiricall=
y non-deterministic which is evident by re-organizations (re-org) as a meth=
od of resolving disagreements within the
 network. &nbsp; During a reorganization a blockchain network is at its wea=
kest point, and a 51% attack to take the network becomes unnecessary. An ad=
versary who can eclipse honest hosts on the network can use this as a means=
 of byzantine fault-injection to disrupt
 the normal flow of messages on the network which creates disagreement betw=
een miners.&nbsp;</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">DeFi
 (Decentralized Finance) and smart-contract obligations depend on network s=
tability and determinism.&nbsp; Failure to pay contracts, such as what happ=
ened on =93black thursday=94 resulted in secured loans accidentally falling=
 into redemption.&nbsp; The transactions used
 by a smart contract are intended to be completed quickly and the outcome i=
s irreversible.&nbsp; However, if the blockchain network has split then a c=
ontract may fire and have it=92s side-effects execute only to have the tran=
saction on the ledger to be replaced.&nbsp;
 Another example is that a hard-fork might cause the payer of a smart contr=
act to default - as the transaction that they broadcasted ended up being on=
 the weaker chain that lost. Some smart contracts, such as collateral backe=
d loans have a redemption clause
 which would force the borrower on the loan to lose their deposit entirely.=
&nbsp;</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">With
 two sides of the network balanced against each other - an attacker has spl=
it the blockchain and this hard-fork can last for as long as the attacker i=
s able to exert the computational power to ensure that proof-of-work blocks=
 are regularly found on both sides
 of the network.&nbsp; The amount of resources needed to balance the networ=
k against itself is far less than a 51% attack - thereby undermining the se=
curity guarantees needed for a decentralized untrusted payment network to f=
unction.&nbsp; An adversary with a sufficiently
 large network of dishonest bots could use this to take a tally of which mi=
ners are participating in which side of the network split. This will create=
 an attacker-controlled hard fork of the network with two mutually exclusiv=
e merkle trees. Whereby the duration
 of this split is arbitrary, and the decision in which chain to collapse is=
 up to the individual with the most IP address, not the most computation.</=
span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">In
 Satoshi Nakamoto=92s original paper it was stated that the electorate shou=
ld be represented by computational effort in the form of a proof-of-work, a=
nd only these nodes can participate in the consues process.&nbsp; However, =
the electorate can be misled by non-voting
 nodes which can reshape the network to benefit an individual adversary.</s=
pan></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Chain
 Fitness</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Any
 solution to byzantine fault-injection or the intentional formation of disa=
greements must be fully decentralized. A blockchain is allowed to split bec=
ause there is ambiguity in the Nakamoto proof-of-work, which creates the en=
vironment for a race-condition to
 form. To resolve this, Floating-Point Nakamoto Consensus makes it increasi=
ngly more expensive to replace the current winning block. This added cost c=
omes from a method of disagreement resolution where not every solution bloc=
k is the same value, and a more-fit
 solution is always chosen over a weaker solution. Any adversary attempting=
 to have a weaker chain to win out would have to overcome a kind of relay-r=
ace, whereby the winning team=92s strength is carried forward and the loser=
 will have to work harder and harder
 to maintain the disagreement.&nbsp; In most cases Floating-Point Nakamoto =
Consensus will prevent a re-org blockchain from ever going past a single bl=
ock thereby expediting the formation of a global consensus.&nbsp; Floating-=
Point Nakamoto Consensus cements the lead
 of the winner and to greatly incentivize the network to adopt the dominant=
 chain no matter how many valid solutions are advertised, or what order the=
y arrive.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">The
 first step in Floating-Point Nakamoto Consensus is that all nodes in the n=
etwork should continue to conduct traditional Nakamoto Consensus and the fo=
rmation of new blocks is dictated by the same zero-prefix proof-of-work req=
uirements.&nbsp; If at any point there
 are two solution blocks advertised for the same height - then a floating-p=
oint fitness value is calculated and the solution with the higher fitness v=
alue is the winner which is then propagated to all neighbors. Any time two =
solutions are advertised then a
 re-org is inevitable and it is in the best interest of all miners to adopt=
 the most-fit block, failing to do so risks wasting resources on a mining o=
f a block that would be discarded.&nbsp; To make sure that incentives are a=
ligned, any zero-prefix proof of work
 could be the next solution, but now in order to replace the current winnin=
g solution an adversary would need a zero-prefix block that is also more fi=
t that the current solution - which is much more computationally expensive =
to produce.</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Any
 changes to the current tip of the blockchain must be avoided as much as po=
ssible. To avoid thrashing between two or more competitive solutions, each =
replacement can only be done if it is more fit, thereby proving that it has=
 an increased expense.&nbsp; If at any
 point two solutions of the same height are found it means that eventually =
some node will have to replace their tip - and it is better to have it done=
 as quickly as possible so that consensus is maintained.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">In
 order to have a purely decentralized solution, this kind of agreement must=
 be empirically derived from the existing proof-of-work so that it is unive=
rsally and identically verifiable by all nodes on the network.&nbsp; Additi=
onally, this fitness-test evaluation
 needs to ensure that no two competing solutions can be numerically equival=
ent.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Let
 us suppose that two or more valid solutions will be proposed for the same =
block.&nbsp; To weigh the value of a given solution, let's consider a solut=
ion for block 639254, in which the following hash was proposed:</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;00000000000000000008e33faa94d30cc73aa4fd819e58ce55970e7db82e10f8</sp=
an></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">There
 are 19 zeros, and the remaining hash in base 16 starts with 9e3 and ends w=
ith f8.&nbsp; This can value can be represented in floating point as:</span=
></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;19.847052573336114130069196154809453027792121882588614904</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">To
 simplify further lets give this block a single whole number to represent o=
ne complete solution, and use a rounded floating-point value to represent s=
ome fraction of additional work exerted by the miner.&nbsp;</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;1.847</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Now
 let us suppose that a few minutes later another solution is advertised to =
the network shown in base16 below:</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;000000000000000000028285ed9bd2c774136af8e8b90ca1bbb0caa36544fbc2</sp=
an></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">The
 solution above also has 19 prefixed zeros, and is being broadcast for the =
same blockheight value of 639254 - and a fitness score of 1.282.&nbsp; With=
 Nakamoto Consensus both of these solutions would be equivalent and a given=
 node would adopt the one that it received
 first.&nbsp; In Floating-Post Nakamoto Consensus, we compare the fitness s=
cores and keep the highest.&nbsp; In this case no matter what happens - som=
e nodes will have to change their tip and a fitness test makes sure this ha=
ppens immediately.&nbsp;</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">With
 both solutions circulating in the network - any node who has received both=
 proof-of-works should know 1.847 is the current highest value, and shouldn=
=92t need to validate any lower-valued solution.&nbsp; In fact this fitness=
 value has a high degree of confidence
 that it won=92t be unseated by a larger value - being able to produce a pr=
oof-of-work with 19 0=92s and a decimal component greater than 0.847 is non=
-trivial.&nbsp; As time passes any nodes that received a proof-of-work with=
 a value 1.204 - their view of the network
 should erode as these nodes adopt the 1.847 version of the blockchain.&nbs=
p;</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">All
 nodes are incentivized to support the solution with the highest fitness va=
lue - irregardless of which order these proof-of-work were validated. Miner=
s are incentivized to support the dominant chain which helps preserve the g=
lobal consensus.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Let
 us assume that the underlying cryptographic hash-function used to generate=
 a proof-of-work is an ideal primitive, and therefore a node cannot force t=
he outcome of the non-zero component of their proof-of-work.&nbsp; Addition=
ally if we assume an ideal cipher then
 the fitness of all possible solutions is gaussian-random. With these assum=
ptions then on average a new solution would split the keyspace of remaining=
 solutions in half.&nbsp; Given that the work needed to form a&nbsp; new bl=
ock remains a constant at 19 blocks for this
 period - it is cheaper to produce a N+1 block that has any floating point =
value as this is guaranteed to be adopted by all nodes if it is the first s=
olution.&nbsp; To leverage a chain replacement on nodes conducting Floating=
-Point Nakamoto Consensus a malicious
 miner would have to expend significantly more resources.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Each
 successive n+1 solution variant of the same block-height must therefore on=
 average consume half of the remaining finite keyspace. Resulting in a the =
n+1 value not only needed to overcome the 19 zero prefix, but also the non-=
zero fitness test. &nbsp; It is possible
 for an adversary to waste their time making a 19 where n+1 was not greater=
, at which point the entire network will have had a chance to move on with =
the next solution.&nbsp; With inductive reasoning, we can see that a demiss=
iniong keyspace increases the amount
 of work needed to find a solution that also meets this new criteria.</span=
></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Now
 let us assume a heavily-fragmented network where some nodes have gotten on=
e or both of the solutions.&nbsp; In the case of nodes that received the pr=
oof-of-work solution with a fitness of 1.847, they will be happily mining o=
n this version of the blockchain. The
 nodes that have gotten both 1.847 and .240 will still be mining for the 1.=
847 domainite version, ensuring a dominant chain.&nbsp; However, we must as=
sume some parts of the network never got the message about 1.847 proof of w=
ork, and instead continued to mine using
 a value of 1.240 as the previous block. &nbsp; Now, let=92s say this group=
 of isolated miners manages to present a new conflicting proof-of-work solu=
tion for 639255:</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;000000000000000000058d8ebeb076584bb5853c80111bc06b5ada35463091=
a6</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">The
 above base16 block has a fitness score of 1.532&nbsp; The fitness value fo=
r the previous block 639254 is added together:</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;2.772
 =3D 1.240 + 1.532</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">In
 this specific case, no other solution has been broadcast for block height =
639255 - putting the weaker branch in the lead.&nbsp; If the weaker branch =
is sufficiently lucky, and finds a solution before the dominant branch then=
 this solution will have a higher overall
 fitness score, and this solution will propagate as it has the higher value=
.&nbsp; This is also important for transactions on the network as they bene=
fit from using the most recently formed block - which will have the highest=
 local fitness score at the time of its
 discovery.&nbsp; At this junction, the weaker branch has an opportunity to=
 prevail enterally thus ending the split.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Now
 let us return to the DoS threat model and explore the worst-case scenario =
created by byzantine fault injection. Let us assume that both the weaker gr=
oup and the dominant group have produced competing proof-of-work solutions =
for blocks 639254 and 639255 respectively.&nbsp;
 Let=92s assume that the dominant group that went with the 1.847 fitness sc=
ore - also produces a solution with a similar fitness value and advertises =
the following solution to the network:</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">0000000000000000000=
455207e375bf1dac0d483a7442239f1ef2c70d050c113</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">19.4149736494645748=
77549198290879237036867705594421756179</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">or</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">3.262 =3D 1.847 + 1=
.415</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">A
 total of 3.262 is still dominant over the lesser 2.772 - in order to overc=
ome this - the 2nd winning block needs to make up for all of the losses in =
the previous block.&nbsp; In this scenario, in order for the weaker chain t=
o supplant the dominant chain it must
 overcome a -0.49 point deficit. In traditional Nakamoto Consensus the node=
s would see both forks as authoritative equals which creates a divide in mi=
ning capacity while two groups of miners search for the next block.&nbsp; I=
n Floating-Point Nakamoto Consensus any
 nodes receiving both forks, would prefer to mine on the chain with an over=
all fitness score of +3.262 - making it even harder for the weaker chain to=
 find miners to compete in any future disagreement, thereby eroding support=
 for the weaker chain. This kind
 of comparison requires an empirical method for determining fitness by mine=
rs following the same same system of rules will insure a self-fulfilled out=
come.&nbsp; After all nodes adopt the dominant chain normal Nakamoto Consue=
ss can resume without having to take
 into consideration block fitness. This example shows how disagreement can =
be resolved more quickly if the network has a mechanism to resolve ambiguit=
y and de-incentivise dissent.</span></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Soft
 Fork</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Blockchain
 networks that would like to improve the consensus generation method by add=
ing a fitness test should be able to do so using a =93Soft Fork=94 otherwis=
e known as a compatible software update.&nbsp; By contrast a =93Hard-Fork=
=94 is a separate incompatible network that does
 not form the same consensus.&nbsp; Floating-Point Nakamoto Consensus can b=
e implemented as a soft-fork because both patched, and non-patched nodes ca=
n co-exist and non-patched nodes will benefit from a kind of herd immunity =
in overall network stability.&nbsp; This is
 because once a small number of nodes start following the same rules then t=
hey will become the deciding factor in which chain is chosen.&nbsp; Clients=
 that are using only traditional Nakamoto Consensus will still agree with n=
ew clients over the total chain length.
 Miners that adopt the new strategy early, will be less likely to lose out =
on mining invalid solutions.</span></p>
<h4 dir=3D"ltr" style=3D"line-height:1.38; margin-top:14pt; margin-bottom:4=
pt"><span style=3D"font-size:12pt; font-family:Arial; color:rgb(102,102,102=
); background-color:transparent; font-weight:400; font-variant-numeric:norm=
al; font-variant-east-asian:normal; vertical-align:baseline; white-space:pr=
e-wrap">Conclusion</span></h4>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Floating-Point
 Nakamoto consensus allows the network to form a consensus more quickly by =
avoiding ambiguity allowing for determinism to take hold. Bitcoin has becom=
e an essential utility, and attacks against our networks must be avoided an=
d adapting, patching and protecting
 the network is a constant effort. An organized attack against a cryptocurr=
ency network will undermine the guarantees that blockchain developers are d=
epending on.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backg=
round-color:transparent; font-variant-numeric:normal; font-variant-east-asi=
an:normal; vertical-align:baseline; white-space:pre-wrap">Any
 blockchain using Nakamoto Consensus can be modified to use a fitness const=
raint such as the one used by a Floating-Point Nakamoto Consensus.&nbsp; An=
 example implementation has been written and submitted as a PR to the bitco=
in core which is free to be adapted by
 other networks.</span></p>
<br>
<br>
<br>
<br>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">A complete implemen=
tation of Floating-Point Nakamoto
 consensus is in the following pull request:</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<a href=3D"https://github.com/bitcoin/bitcoin/pull/19665/files" target=3D"_=
blank" style=3D"text-decoration-line:none"><span style=3D"font-size:11pt; f=
ont-family:Arial; background-color:transparent; font-variant-numeric:normal=
; font-variant-east-asian:normal; text-decoration-line:underline; vertical-=
align:baseline; white-space:pre-wrap">https://github.com/bitcoin/bitcoin/pu=
ll/19665/files</span></a></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<span style=3D"font-size:11pt; font-family:Arial; color:rgb(0,0,0); backgro=
und-color:transparent; font-variant-numeric:normal; font-variant-east-asian=
:normal; vertical-align:baseline; white-space:pre-wrap">Paper:</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<a href=3D"https://github.com/in-st/Floating-Point-Nakamoto-Consensus" targ=
et=3D"_blank" style=3D"text-decoration-line:none"><span style=3D"font-size:=
11pt; font-family:Arial; background-color:transparent; font-variant-numeric=
:normal; font-variant-east-asian:normal; text-decoration-line:underline; ve=
rtical-align:baseline; white-space:pre-wrap">https://github.com/in-st/Float=
ing-Point-Nakamoto-Consensus</span></a></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-left:36pt; margin-top:0pt;=
 margin-bottom:0pt">
<a href=3D"https://in.st.capital/" target=3D"_blank" style=3D"text-decorati=
on-line:none"><span style=3D"font-size:11pt; font-family:Arial; background-=
color:transparent; font-variant-numeric:normal; font-variant-east-asian:nor=
mal; text-decoration-line:underline; vertical-align:baseline; white-space:p=
re-wrap">https://in.st.capital</span></a></p>
<div class=3D"x_gmail-yj6qo"></div>
<br class=3D"x_gmail-Apple-interchange-newline">
</span></div>
</div>
</div>
</div>
</body>
</html>

--_000_PSXP216MB0967356F976C35E9D1C5A5EC9D320PSXP216MB0967KORP_--