summaryrefslogtreecommitdiff
path: root/c3/167cf4d35b66ad48842ab5e6613279c31108f1
blob: 319d8783e7a9f1a90eaf9a45bf2a85bb08a7aee8 (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
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2F8BA89E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 24 Dec 2017 03:44:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-HK2-obe.outbound.protection.outlook.com
	(mail-oln040092255104.outbound.protection.outlook.com
	[40.92.255.104])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E33513CA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 24 Dec 2017 03:44:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; 
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
	bh=y/+48eW6pWm9u0n9cdEmouZ8gj4ALtZZ8/Z02m2Q028=;
	b=pHT20WkMnQdOCRU9vAZHFG/zUvQt5tcjPDVEjTB4oinCv8XLhBEjuTcNo/zUq87ia89lH7jImTv/ogRm0h/0xcvCM2Lr2RAT2bRNSDWdUiKehnJ7vBjwZ7T+gNL4sjU6QALopadnxV/vaJtLEvRcrudaUTp1Crin/12iE5ykvNYhieBWTzFEu7+4/eP6Xhuc4Dup5Eed+OTnz0fhpkN3ptrlzH+7Ilj/VT6xkgPSZOq2eHLJXSCsPIsRI1AdsAWpfMqj3c5odzI2lE7EOKmpL19uTUkNvSJBQjTeSdQdi6S708WccI4IBh6FfPj2pzGX+PBAhSVaguiq0/Hx60fcvw==
Received: from PU1APC01FT041.eop-APC01.prod.protection.outlook.com
	(10.152.252.57) by PU1APC01HT140.eop-APC01.prod.protection.outlook.com
	(10.152.253.216) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6;
	Sun, 24 Dec 2017 03:44:26 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.53) by
	PU1APC01FT041.mail.protection.outlook.com (10.152.253.108) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.302.6 via
	Frontend Transport; Sun, 24 Dec 2017 03:44:26 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) by
	PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) with mapi id
	15.20.0345.013; Sun, 24 Dec 2017 03:44:26 +0000
From: Damian Williamson <willtech@live.com.au>
To: Spartacus Rex <spartacusrex99@gmail.com>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction
	Priority For Ordering Transactions In Blocks
Thread-Index: AQHTb5z9LKaNJrfjBkOvllhZtrqBGqNEL2DvgAB3wACAAD9wXoACEoTMgAJcmACAAQbApoAEnfOOgADF9ICAAianIQ==
Date: Sun, 24 Dec 2017 03:44:26 +0000
Message-ID: <PS2P216MB0179D452E5D478511B46E0879D000@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <PS2P216MB01794ABD544248B27BF0DFD99D330@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<PS2P216MB01795BFC05612E021CCEDD7C9D0B0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<5upGmF0IhXUWhcikhdV-e9Pqg-kXfUuXe0kOpGxumie_TO2jLvCgTZ5c6vgBRtaqkL6DmOJb1YftK0osufB5RkhW7YhAhhCI0zBTH3YcORY=@protonmail.com>
	<PS2P216MB0179544A6503C2992190CEB69D0B0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<PS2P216MB0179D6A5965D0CFFEFB2880A9D090@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<AB6BF756-29F1-4442-85A9-B81228E829EC@friedenbach.org>
	<PS2P216MB017991D78147E2B1EC14C3059D0F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<PS2P216MB0179FC39F4A63A43BB70011A9D020@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>,
	<CA+Cf5AaX5a5yuLcnkk=7boiqrSrZf4KG_RjSOF1-2qJtB9ds+Q@mail.gmail.com>
In-Reply-To: <CA+Cf5AaX5a5yuLcnkk=7boiqrSrZf4KG_RjSOF1-2qJtB9ds+Q@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:50C860FD3A586529C3900A6BEA9420D7221B7E11F11DF7743615A2051FA096BA;
	UpperCasedChecksum:EC5ADA40C2321B3F25857D4BB6C76A35288EDE545413C22043B2C3D202A88783;
	SizeAsReceived:7971; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [RkNqNcNGIw61pP1wDUtFrTtFiNGGpcHT]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT140;
	6:eLO3k3MWvj9qfnjdaxUDlr2U4T7FxmPju9CIt1WWbuStRv1cL8/6EfaXRnlfY5OfABElqQFi7404kIOMhwWrwxfSY3bM8RTRJwO8E0x2J+ApuAtQ6H2VDTqNT0DQrAKYIvG5fwFg01dReC60F52TakMYM4LNf2W3vmlVpmA8u2PJ0zivYttiXQrQgV1WvuGRmk3yklRaY1LXV2d2DOg4cgDEUlzpYFd+CxXxOWg+q38TY/xSzgOF5ou/zqxA/q6p53aGO+wOtjgSfcbiknhQLuSHp5/tQDs+iTA15dQ/fy5FJjq50z68EnR0cQct/EYgN1cLqGJE1PVFq1kAbYfDu/BXlLoPr1V0QuKQ4x4YDhI=;
	5:I0WtMMFPOrH81T0HrO5cANtfkOdlE9VrMuRuVrccv+5nUa9r6Hn2pfobWurfDCgoWMvRst3R3VP3yD4huwLMSJUGbjNQmysj63rZZz/4hL5d6qmBzf+neiEdSepFs+tbkqSE6tzz1n7s2utU/eomB7Rs2dHnpBrqJ6eburSimbU=;
	24:3fq4EE2PgEatChKh71rhhFD4frk4AirvmJDod6kItiCkejEMQOeOGZb0vg2gSmzzL8u5IN32xxb0kYD7QmA6RT+5xLSrFBISS1jNQ34MlZI=;
	7:5gX9R/jc9uxjGr9B7qnVonWbf/ZEmP8vBhBskkd4y7qR4mYFe4LPERv7dBYYX26N0Q0jUR8J0n9hOZYBzDnvHbQwlmvKC/RHGteZB3Y85K3Rb2YCqbj9J3qxNwhbqRqRShIG8ad6whyj3J5TnuwBdEMB3rT+hiLOtG9QDrlpsYi9LEqJeubzoPA8a0kQRVJKJba7b51NO1J80iKVXMunpMTNYDEnk5ivLJIDFsKwhyuWZgE4EONZYTvPoj2bw9ZM
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045);
	SRVR:PU1APC01HT140; 
x-ms-traffictypediagnostic: PU1APC01HT140:
x-ms-office365-filtering-correlation-id: 78711499-5f48-44ab-16b7-08d54a80a130
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:PU1APC01HT140; BCL:0; PCL:0;
	RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT140; 
x-forefront-prvs: 05315CBE52
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:PU1APC01HT140;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB0179D452E5D478511B46E0879D000PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 78711499-5f48-44ab-16b7-08d54a80a130
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2017 03:44:26.2408 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT140
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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: Tue, 26 Dec 2017 00:19:04 +0000
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction
 Priority For Ordering Transactions In Blocks
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: Sun, 24 Dec 2017 03:44:33 -0000

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

>.. This system has flaws, they all do.


>The simple fact is that there is currently no known system that works as w=
ell as the current system..


Alright, but, we seem to agree, the current system also has flaws. The tran=
saction bandwidth limit is a serious issue for transactional reliability.


What you have proposed is interesting but seems to do nothing for the issue=
 of transaction bandwidth, which seems to be approaching its threshold:

https://bitinfocharts.com/comparison/bitcoin-transactions.html


Regards,

Damian Williamson

________________________________
From: Spartacus Rex <spartacusrex99@gmail.com>
Sent: Saturday, 23 December 2017 5:07:49 AM
To: Damian Williamson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transactio=
n Priority For Ordering Transactions In Blocks

Hi Damian,

Thought I'd chip in.  This is a hard fork scenario. This system has flaws, =
they all do.

If you had a fixed fee per block, so that every txn in that block paid the =
same fee, that might make it easier to include all txns eventually, as you =
envisage.

The fee could be calculated as the average of the amount txns are prepared =
to pay in the last 1000 blocks.

A txn would say ' I'll pay up to X bitcoins ' and as long as that is more t=
han the value required for the block your txn can be added. This is to ensu=
re you don't pay more than you are willing.  It also ensures that putting a=
n enormous fee will not ensure your txn is processed quickly..

Calculating what the outputs are given a variable fee needs a new mechanism=
 all of it's own, but I'm sure it's possible.

The simple fact is that there is currently no known system that works as we=
ll as the current system..

But there are other systems.


On Dec 22, 2017 15:09, "Damian Williamson via bitcoin-dev" <bitcoin-dev@lis=
ts.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote=
:

If the cash value of Bitcoin was high enough and zero fee transactions were=
 never accepted and not counted when calculating the transaction pool size =
then I do not think it would be such an issue. Why is it even possible to c=
reate zero fee transactions?


Regards,

Damian Williamson

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org<mailto:bitcoin-dev-boun=
ces@lists.linuxfoundation.org> <bitcoin-dev-bounces@lists.linuxfoundation.o=
rg<mailto:bitcoin-dev-bounces@lists.linuxfoundation.org>> on behalf of Dami=
an Williamson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto=
:bitcoin-dev@lists.linuxfoundation.org>>
Sent: Tuesday, 19 December 2017 6:51 PM
To: Mark Friedenbach
Cc: bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfou=
ndation.org>
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Pr=
iority For Ordering Transactions In Blocks


Thank you for your constructive feedback. I now see that the proposal intro=
duces a potential issue.


>Finally in terms of the broad goal, having block size based on the number =
of transactions is NOT something desirable in the first place, even if it d=
id work. That=92s effectively the same as an infinite block size since anyo=
ne anywhere can create transactions in the mempool at no cost.


Do you have any critical suggestion as to how transaction bandwidth limit c=
ould be addressed, it will eventually become an issue if nothing is changed=
 regardless of how high fees go?


Regards,

Damian Williamson



________________________________
From: Mark Friedenbach <mark@friedenbach.org<mailto:mark@friedenbach.org>>
Sent: Tuesday, 19 December 2017 3:08 AM
To: Damian Williamson
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transactio=
n Priority For Ordering Transactions In Blocks

Damian, you seem to be misunderstanding that either

(1) the strong form of your proposal requires validating the commitment to =
the mempool properties, in which case the mempool becomes consensus critica=
l (an impossible requirement); or

(2) in the weak form where the current block is dependent on the commitment=
 in the last block only it is becomes a miner-selected field they can freel=
y parameterize with no repercussions for setting values totally independent=
 of the actual mempool.

If you want to make the block size dependent on the properties of the mempo=
ol in a consensus critical way, flex cap achieves this. If you want to make=
 the contents or properties of the mempool known to well-connected nodes, w=
eak blocks achieves that. But you can=92t stick the mempool in consensus be=
cause it fundamentally is not something the nodes have consensus over. That=
=92s a chicken-and-the-egg assumption.

Finally in terms of the broad goal, having block size based on the number o=
f transactions is NOT something desirable in the first place, even if it di=
d work. That=92s effectively the same as an infinite block size since anyon=
e anywhere can create transactions in the mempool at no cost.

On Dec 16, 2017, at 8:14 PM, Damian Williamson via bitcoin-dev <bitcoin-dev=
@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> w=
rote:

I do not know why people make the leap that the proposal requires a consens=
us on the transaction pool. It does not.

It may be helpful to have the discussion from the previous thread linked he=
re.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/01537=
0.html

Where I speak of validating that a block conforms to the broadcast next blo=
ck size, I do not propose validating the number broadcast for the next bloc=
k size itself, only that the next generated block is that size.

Regards,
Damian Williamson


________________________________
From: Damian Williamson <willtech@live.com.au<mailto:willtech@live.com.au>>
Sent: Saturday, 16 December 2017 7:59 AM
To: Rhavar
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transactio=
n Priority For Ordering Transactions In Blocks

There are really two separate problems to solve.


  1.  How does Bitcoin scale with fixed block size?
  2.  How do we ensure that all valid transactions are eventually included =
in the blockchain?

Those are the two issues that the proposal attempts to address. It makes se=
nse to resolve these two problems together. Using the proposed system for v=
ariable block sizes would solve the first problem but there would still be =
a whole bunch of never confirming transactions. I am not sure how to reliab=
ly solve the second problem at scale without first solving the first.

>* Every node has a (potentially) different mempool, you can't use it to de=
cide consensus values like the max block size.

I do not suggest a consensus. Depending on which node solves a block the va=
lue for next block size will be different. The consensus would be that bloc=
ks will adhere to the next block size value transmitted with the current bl=
ock. It is easy to verify that the consensus is being adhered to once in pl=
ace.

>* Increasing the entropy in a block to make it more unpredictable doesn't =
really make sense.

Not a necessary function, just an effect of using a probability-based distr=
ibution.

>* Bitcoin should be roughly incentive compatible. Your proposal explicits =
asks miners to ignore their best interests, and confirm transactions by "pr=
iority".  What are you going to do if a "malicious" miner decides to go aft=
er their profits and order by what makes them the most money. Add "ordered =
by priority" as a consensus requirement? And even if you miners can still s=
ort their mempool by fee, and then order the top 1MB by priority.

I entirely agree with your sentiment that Bitcoin must be incentive compati=
ble. It is necessary.

It is in only miners immediate interest to make the most profitable block f=
rom the available transaction pool. As with so many other things, it is nec=
essary to partially ignore short-term gain for long-term benefit. It is in =
miners and everybody's long-term interest to have a reliable transaction se=
rvice. A busy transaction service that confirms lots of transactions per ho=
ur will become more profitable as demand increases and more users are prepa=
red to pay for priority. As it is there is currently no way to fully scale =
because of the transaction bandwidth limit and that is problematic. If all =
valid transactions must eventually confirm then there must be a way to reso=
lve that problem.

Bitcoin deliberately removes traditional scale by ensuring blocks take ten =
minutes on average to solve, an ingenious idea and, incentive compatible bu=
t, fixed block sizes leaves us with a problem to solve when we want to scal=
e.

>If you could find a good solution that would allow you to know if miners w=
ere following your rule or not (and thus ignore it if it doesn't) then you =
wouldn't even need bitcoin in the first place.

I am confident that the math to verify blocks based on the proposal can be =
developed (and I think it will not be too complex for a mathematician with =
the relevant experience), however, I am nowhere near experienced enough wit=
h probability and statistical analysis to do it. Yes, if Bitcoin doesn't th=
en it might make another great opportunity for an altcoin but I am not even=
 nearly interested in promoting any altcoins.

If not the proposal that I have put forward, then, hopefully, someone can c=
ome up with a better solution. The important thing is that the issues are r=
esolved.

Regards,
Damian Williamson


________________________________
From: Rhavar <rhavar@protonmail.com<mailto:rhavar@protonmail.com>>
Sent: Saturday, 16 December 2017 3:38 AM
To: Damian Williamson
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transactio=
n Priority For Ordering Transactions In Blocks

> I understand that there would be technical issues to resolve in implement=
ation, but, are there no fundamental errors?

Unfortunately your proposal is really fundamentally broken, on a few levels=
. I think you might need to do a bit more research into how bitcoin works b=
efore coming up with such improvements =3D)

But just some quick notes:

* Every node has a (potentially) different mempool, you can't use it to dec=
ide consensus values like the max block size.

* Increasing the entropy in a block to make it more unpredictable doesn't r=
eally make sense.

* Bitcoin should be roughly incentive compatible. Your proposal explicits a=
sks miners to ignore their best interests, and confirm transactions by "pri=
ority".  What are you going to do if a "malicious" miner decides to go afte=
r their profits and order by what makes them the most money. Add "ordered b=
y priority" as a consensus requirement? And even if you miners can still so=
rt their mempool by fee, and then order the top 1MB by priority.

If you could find a good solution that would allow you to know if miners we=
re following your rule or not (and thus ignore it if it doesn't) then you w=
ouldn't even need bitcoin in the first place.




-Ryan


-------- Original Message --------
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Pr=
iority For Ordering Transactions In Blocks
Local Time: December 15, 2017 3:42 AM
UTC Time: December 15, 2017 9:42 AM
From: bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxf=
oundation.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org<mail=
to:bitcoin-dev@lists.linuxfoundation.org>>



I should not take it that the lack of critical feedback to this revised pro=
posal is a glowing endorsement. I understand that there would be technical =
issues to resolve in implementation, but, are there no fundamental errors?

I suppose that it if is difficult to determine how long a transaction has b=
een waiting in the pool then, each node could simply keep track of when a t=
ransaction was first seen. This may have implications for a verify routine,=
 however, for example, if a node was offline, how should it differentiate h=
ow long each transaction was waiting in that case? If a node was restarted =
daily would it always think that all transactions had been waiting in the p=
ool less than one day If each node keeps the current transaction pool in a =
file and updates it, as transactions are included in blocks and, as new tra=
nsactions appear in the pool, then that would go some way to alleviate the =
issue, apart from entirely new nodes. There should be no reason the content=
s of a transaction pool files cannot be shared without agreement as to the =
transaction pool between nodes, just as nodes transmit new transactions fre=
ely.

It has been questioned why miners could not cheat. For the question of how =
many transactions to include in a block, I say it is a standoff and miners =
will conform to the proposal, not wanting to leave transactions with valid =
fees standing, and, not wanting to shrink the transaction pool. In any case=
, if miners shrink the transaction pool then I am not immediately concerned=
 since it provides a more efficient service. For the question of including =
transactions according to the proposal, I say if it is possible to keep tra=
ck of how long transactions are waiting in the pool so that they can be inc=
luded on a probability curve then it is possible to verify that blocks conf=
orm to the proposal, since the input is a probability, the output should co=
nform to a probability curve.


If someone has the necessary skill, would anyone be willing to develop the =
math necessary for the proposal?

Regards,
Damian Williamson


________________________________

From: bitcoin-dev-bounces@lists.linuxfoundation.org<mailto:bitcoin-dev-boun=
ces@lists.linuxfoundation.org> <bitcoin-dev-bounces@lists.linuxfoundation.o=
rg<mailto:bitcoin-dev-bounces@lists.linuxfoundation.org>> on behalf of Dami=
an Williamson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto=
:bitcoin-dev@lists.linuxfoundation.org>>
Sent: Friday, 8 December 2017 8:01 AM
To: bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfou=
ndation.org>
Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Pr=
iority For Ordering Transactions In Blocks


Good afternoon,

The need for this proposal:

We all must learn to admit that transaction bandwidth is still lurking as a=
 serious issue for the operation, reliability, safety, consumer acceptance,=
 uptake and, for the value of Bitcoin.

I recently sent a payment which was not urgent so; I chose three-day target=
 confirmation from the fee recommendation. That transaction has still not c=
onfirmed after now more than six days - even waiting twice as long seems qu=
ite reasonable to me. That transaction is a valid transaction; it is not ru=
bbish, junk or, spam. Under the current model with transaction bandwidth li=
mitation, the longer a transaction waits, the less likely it is ever to con=
firm due to rising transaction numbers and being pushed back by transaction=
s with rising fees.

I argue that no transactions are rubbish or junk, only some zero fee transa=
ctions might be spam. Having an ever-increasing number of valid transaction=
s that do not confirm as more new transactions with higher fees are created=
 is the opposite of operating a robust, reliable transaction system.

Business cannot operate with a model where transactions may or may not conf=
irm. Even a business choosing a modest fee has no guarantee that their vali=
d transaction will not be shuffled down by new transactions to the realm of=
 never confirming after it is created. Consumers also will not accept this =
model as Bitcoin expands. If Bitcoin cannot be a reliable payment system fo=
r confirmed transactions then consumers, by and large, will simply not acce=
pt the model once they understand. Bitcoin will be a dirty payment system, =
and this will kill the value of Bitcoin.

Under the current system, a minority of transactions will eventually be the=
 lucky few who have fees high enough to escape being pushed down the list.

Once there are more than x transactions (transaction bandwidth limit) every=
 ten minutes, only those choosing twenty-minute confirmation (2 blocks) wil=
l have initially at most a fifty percent chance of ever having their paymen=
t confirm. Presently, not even using fee recommendations can ensure a suffi=
ciently high fee is paid to ensure transaction confirmation.

I also argue that the current auction model for limited transaction bandwid=
th is wrong, is not suitable for a reliable transaction system and, is wron=
g for Bitcoin. All transactions must confirm in due time. Currently, Bitcoi=
n is not a safe way to send payments.

I do not believe that consumers and business are against paying fees, even =
high fees. What is required is operational reliability.

This great issue needs to be resolved for the safety and reliability of Bit=
coin. The time to resolve issues in commerce is before they become great bi=
g issues. The time to resolve this issue is now. We must have the foresight=
 to identify and resolve problems before they trip us over.  Simply doublin=
g block sizes every so often is reactionary and is not a reliable permanent=
 solution. I have written a BIP proposal for a technical solution but, need=
 your help to write it up to an acceptable standard to be a full BIP.

I have formatted the following with markdown which is human readable so, I =
hope nobody minds. I have done as much with this proposal as I feel that I =
am able so far but continue to take your feedback.

# BIP Proposal: UTPFOTIB - Use Transaction Priority For Ordering Transactio=
ns In Blocks

## The problem:
Everybody wants value. Miners want to maximize revenue from fees (and we pr=
esume, to minimize block size). Consumers need transaction reliability and,=
 (we presume) want low fees.

The current transaction bandwidth limit is a limiting factor for both. As t=
he operational safety of transactions is limited, so is consumer confidence=
 as they realize the issue and, accordingly, uptake is limited. Fees are ar=
tificially inflated due to bandwidth limitations while failing to provide a=
 full confirmation service for all transactions.

Current fee recommendations provide no satisfaction for transaction reliabi=
lity and, as Bitcoin scales, this will worsen.

Bitcoin must be a fully scalable and reliable service, providing full trans=
action confirmation for every valid transaction.

The possibility to send a transaction with a fee lower than one that is acc=
eptable to allow eventual transaction confirmation should be removed from t=
he protocol and also from the user interface.

## Solution summary:
Provide each transaction with an individual transaction priority each time =
before choosing transactions to include in the current block, the priority =
being a function of the fee paid (on a curve), and the time waiting in the =
transaction pool (also on a curve) out to n days (n=3D60 ?). The transactio=
n priority to serve as the likelihood of a transaction being included in th=
e current block, and for determining the order in which transactions are tr=
ied to see if they will be included.

Use a target block size. Determine the target block size using; current tra=
nsaction pool size x ( 1 / (144 x n days ) ) =3D number of transactions to =
be included in the current block. Broadcast the next target block size with=
 the current block when it is solved so that nodes know the next target blo=
ck size for the block that they are building on.

The curves used for the priority of transactions would have to be appropria=
te. Perhaps a mathematician with experience in probability can develop the =
right formulae. My thinking is a steep curve. I suppose that the probabilit=
y of all transactions should probably account for a sufficient number of in=
clusions that the target block size is met although, it may not always be. =
As a suggestion, consider including some zero fee transactions to pad, high=
est BTC value first?

**Explanation of the operation of priority:**
> If transaction priority is, for example, a number between one (low) and o=
ne-hundred (high) it can be directly understood as the percentage chance in=
 one-hundred of a transaction being included in the block. Using probabilit=
y or likelihood infers that there is some function of random. If random (10=
0) < transaction priority then the transaction is included.

>To break it down further, if both the fee on a curve value and the time wa=
iting on a curve value are each a number between one and one-hundred, a rud=
imentary method may be to simply multiply those two numbers, to find the pr=
iority number. For example, a middle fee transaction waiting thirty days (i=
f n =3D 60 days) may have a value of five for each part  (yes, just five, t=
he values are on a curve). When multiplied that will give a priority value =
of twenty-five, or,  a twenty-five percent chance at that moment of being i=
ncluded in the block; it will likely be included in one of the next four bl=
ocks, getting more likely each chance. If it is still not included then the=
 value of time waiting will be higher, making for more probability. A very =
low fee transaction would have a value for the fee of one. It would not be =
until near sixty-days that the particular low fee transaction has a high li=
kelihood of being included in the block.

I am not concerned with low (or high) transaction fees, the primary reason =
for addressing the issue is to ensure transactional reliability and scalabi=
lity while having each transaction confirm in due time.

## Pros:
* Maximizes transaction reliability.
* Fully scalable.
* Maximizes possibility for consumer and business uptake.
* Maximizes total fees paid per block without reducing reliability; because=
 of reliability, in time confidence and overall uptake are greater; therefo=
re, more transactions.
* Market determines fee paid for transaction priority.
* Fee recommendations work all the way out to 30 days or greater.
* Provides additional block entropy; greater security since there is less p=
robability of predicting the next block.

## Cons:
* Could initially lower total transaction fees per block.
* Must be first be programmed.

## Solution operation:
This is a simplistic view of the operation. The actual operation will need =
to be determined in a spec for the programmer.

1. Determine the target block size for the current block.
2. Assign a transaction priority to each transaction in the pool.
3. Select transactions to include in the current block using probability in=
 transaction priority order until the target block size is met.
5. Solve block.
6. Broadcast the next target block size with the current block when it is s=
olved.
7. Block is received.
8. Block verification process.
9. Accept/reject block based on verification result.
10. Repeat.

## Closing comments:
It may be possible to verify blocks conform to the proposal by showing that=
 the probability for all transactions included in the block statistically c=
onforms to a probability distribution curve, *if* the individual transactio=
n priority can be recreated. I am not that deep into the mathematics; howev=
er, it may also be possible to use a similar method to do this just based o=
n the fee, that statistically, the blocks conform to a fee distribution. An=
y zero fee transactions would have to be ignored. This solution needs a cle=
ver mathematician.

I implore, at the very least, that we use some method that validates full t=
ransaction reliability and enables scalability of block sizes. If not this =
proposal, an alternative.

Regards,
Damian Williamson


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--_000_PS2P216MB0179D452E5D478511B46E0879D000PS2P216MB0179KORP_
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;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">&gt;.. <span>This system has flaw=
s, they all do.</span><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">&gt;<span>The simple fact is that=
 there is currently no known system that works as well as the current syste=
m..&nbsp;</span></p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">Alright, but, we seem to agree, t=
he current system also has flaws. The transaction bandwidth limit is a seri=
ous issue for transactional reliability.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">What you have proposed is interes=
ting but seems to do nothing for the issue of transaction bandwidth, which =
seems to be approaching its threshold:</p>
<p style=3D"margin-top:0;margin-bottom:0"><a href=3D"https://bitinfocharts.=
com/comparison/bitcoin-transactions.html" class=3D"OWAAutoLink" id=3D"LPlnk=
89791" previewremoved=3D"true">https://bitinfocharts.com/comparison/bitcoin=
-transactions.html</a><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">Regards,</p>
<p style=3D"margin-top:0;margin-bottom:0">Damian Williamson<br>
</p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Spartacus Rex &lt;spa=
rtacusrex99@gmail.com&gt;<br>
<b>Sent:</b> Saturday, 23 December 2017 5:07:49 AM<br>
<b>To:</b> Damian Williamson; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Tra=
nsaction Priority For Ordering Transactions In Blocks</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"auto">Hi Damian,
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Thought I'd chip in.&nbsp; This is a hard fork scenario. =
This system has flaws, they all do.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">If you had a fixed fee per block, so that every txn in th=
at block paid the same fee, that might make it easier to include all txns e=
ventually, as you envisage.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">The fee could be calculated as the average of the amount =
txns are prepared to pay in the last 1000 blocks.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">A txn would say ' I'll pay up to X bitcoins ' and as long=
 as that is more than the value required for the block your txn can be adde=
d. This is to ensure you don't pay more than you are willing.&nbsp; It also=
 ensures that putting an enormous fee will
 not ensure your txn is processed quickly..</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Calculating what the outputs are given a variable fee nee=
ds a new mechanism all of it's own, but I'm sure it's possible.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">The simple fact is that there is currently no known syste=
m that works as well as the current system..&nbsp;</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">But there are other systems.&nbsp;</div>
<div dir=3D"auto"><br>
</div>
</div>
<div class=3D"x_gmail_extra"><br>
<div class=3D"x_gmail_quote">On Dec 22, 2017 15:09, &quot;Damian Williamson=
 via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&g=
t; wrote:<br type=3D"attribution">
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex; border-left=
:1px #ccc solid; padding-left:1ex">
<div dir=3D"ltr">
<div id=3D"x_m_4574273483018812099divtagdefaultwrapper" dir=3D"ltr" style=
=3D"font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-se=
rif,&quot;EmojiFont&quot;,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoj=
i&quot;,NotoColorEmoji,&quot;Segoe UI Symbol&quot;,&quot;Android Emoji&quot=
;,EmojiSymbols">
<p style=3D"margin-top:0; margin-bottom:0"><span>If the cash value of Bitco=
in was high enough and zero fee transactions were never accepted and not co=
unted when calculating the transaction pool size then I do not think it wou=
ld be such an issue. Why is it even
 possible to create zero fee transactions?</span></p>
<p style=3D"margin-top:0; margin-bottom:0"><span><br>
</span></p>
<p style=3D"margin-top:0; margin-bottom:0"><span>Regards,</span></p>
<p style=3D"margin-top:0; margin-bottom:0"><span>Damian Williamson</span><b=
r>
</p>
<br>
<div style=3D"color:rgb(0,0,0)">
<hr style=3D"display:inline-block; width:98%">
<div id=3D"x_m_4574273483018812099divRplyFwdMsg" dir=3D"ltr"><font face=3D"=
Calibri, sans-serif" color=3D"#000000" style=3D"font-size:11pt"><b>From:</b=
>
<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev-bounces@lists.<wbr>linuxfoundation.org</a> &lt;<a href=
=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev-bounces@lists.<wbr>linuxfoundation.org</a>&gt;
 on behalf of Damian Williamson via bitcoin-dev &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>=
linuxfoundation.org</a>&gt;<br>
<b>Sent:</b> Tuesday, 19 December 2017 6:51 PM<br>
<b>To:</b> Mark Friedenbach<br>
<b>Cc:</b> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">
bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<b>Subject:</b> [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transac=
tion Priority For Ordering Transactions In Blocks</font>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr">
<div id=3D"x_m_4574273483018812099x_divtagdefaultwrapper" dir=3D"ltr" style=
=3D"font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-se=
rif,&quot;EmojiFont&quot;,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoj=
i&quot;,NotoColorEmoji,&quot;Segoe UI Symbol&quot;,&quot;Android Emoji&quot=
;,EmojiSymbols">
<p style=3D"margin-top:0; margin-bottom:0"></p>
<div>
<p style=3D"margin-top:0; margin-bottom:0">Thank you for your constructive =
feedback. I now see that the proposal introduces a potential issue.</p>
<p style=3D"margin-top:0; margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0; margin-bottom:0"><span>&gt;Finally in terms of th=
e broad goal, having block size based on the number of transactions is NOT =
something desirable in the first place, even if it did work. That=92s effec=
tively the same as an infinite block size
 since anyone anywhere can create transactions in the mempool at no cost.</=
span></p>
<p style=3D"margin-top:0; margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0; margin-bottom:0">Do you have any critical suggest=
ion as to how transaction bandwidth limit could be addressed, it will event=
ually become an issue if nothing is changed regardless of how high fees go?=
<br>
</p>
<p style=3D"margin-top:0; margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0; margin-bottom:0">Regards,</p>
Damian Williamson</div>
<br>
<p></p>
<br>
<br>
<div style=3D"color:rgb(0,0,0)">
<hr style=3D"display:inline-block; width:98%">
<div id=3D"x_m_4574273483018812099x_divRplyFwdMsg" dir=3D"ltr"><font face=
=3D"Calibri, sans-serif" color=3D"#000000" style=3D"font-size:11pt"><b>From=
:</b> Mark Friedenbach &lt;<a href=3D"mailto:mark@friedenbach.org" target=
=3D"_blank">mark@friedenbach.org</a>&gt;<br>
<b>Sent:</b> Tuesday, 19 December 2017 3:08 AM<br>
<b>To:</b> Damian Williamson<br>
<b>Subject:</b> Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Tra=
nsaction Priority For Ordering Transactions In Blocks</font>
<div>&nbsp;</div>
</div>
<div style=3D"word-wrap:break-word; line-break:after-white-space">Damian, y=
ou seem to be misunderstanding that either
<div><br>
</div>
<div>(1) the strong form of your proposal requires validating the commitmen=
t to the mempool properties, in which case the mempool becomes consensus cr=
itical (an impossible requirement); or</div>
<div><br>
</div>
<div>(2) in the weak form where the current block is dependent on the commi=
tment in the last block only it is becomes a miner-selected field they can =
freely parameterize with no repercussions for setting values totally indepe=
ndent of the actual mempool.</div>
<div><br>
</div>
<div>If you want to make the block size dependent on the properties of the =
mempool in a consensus critical way, flex cap achieves this. If you want to=
 make the contents or properties of the mempool known to well-connected nod=
es, weak blocks achieves that. But
 you can=92t stick the mempool in consensus because it fundamentally is not=
 something the nodes have consensus over. That=92s a chicken-and-the-egg as=
sumption.</div>
<div><br>
</div>
<div>Finally in terms of the broad goal, having block size based on the num=
ber of transactions is NOT something desirable in the first place, even if =
it did work. That=92s effectively the same as an infinite block size since =
anyone anywhere can create transactions
 in the mempool at no cost.<br>
<div>
<div><br>
<blockquote type=3D"cite">
<div>On Dec 16, 2017, at 8:14 PM, Damian Williamson via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:</div>
<br class=3D"x_m_4574273483018812099x_x_Apple-interchange-newline">
<div>
<div id=3D"x_m_4574273483018812099x_x_divtagdefaultwrapper" dir=3D"ltr" sty=
le=3D"font-style:normal; font-weight:normal; letter-spacing:normal; text-al=
ign:start; text-indent:0px; text-transform:none; white-space:normal; word-s=
pacing:0px; font-size:12pt; font-family:Calibri,Helvetica,sans-serif,EmojiF=
ont,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji=
,&quot;Segoe UI Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols">
<div style=3D"margin-top:0px; margin-bottom:0px">I do not know why people m=
ake the leap that the proposal requires a consensus on the transaction pool=
. It does not.<br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px">It may be helpful to have =
the discussion from the previous thread linked here.</div>
<div style=3D"margin-top:0px; margin-bottom:0px"><a href=3D"https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2017-December/015370.html" class=
=3D"x_m_4574273483018812099x_x_OWAAutoLink" id=3D"x_m_4574273483018812099LP=
lnk741490" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/piperma=
il/bitcoin-dev/<wbr>2017-December/015370.html</a><br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px">Where I speak of validatin=
g that a block conforms to the broadcast next block size, I do not propose =
validating the number broadcast for the next block size itself, only that t=
he next generated block is that size.<br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px">Regards,</div>
<div style=3D"margin-top:0px; margin-bottom:0px">Damian Williamson<br>
</div>
<br>
<br>
<div>
<hr style=3D"display:inline-block; width:654.625px">
<div id=3D"x_m_4574273483018812099x_x_divRplyFwdMsg" dir=3D"ltr"><font face=
=3D"Calibri, sans-serif" style=3D"font-size:11pt"><b>From:</b><span class=
=3D"x_m_4574273483018812099x_x_Apple-converted-space">&nbsp;</span>Damian W=
illiamson &lt;<a href=3D"mailto:willtech@live.com.au" target=3D"_blank">wil=
ltech@live.com.au</a>&gt;<br>
<b>Sent:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-space=
">&nbsp;</span>Saturday, 16 December 2017 7:59 AM<br>
<b>To:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">=
&nbsp;</span>Rhavar<br>
<b>Cc:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">=
&nbsp;</span>Bitcoin Protocol Discussion<br>
<b>Subject:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-sp=
ace">&nbsp;</span>Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use T=
ransaction Priority For Ordering Transactions In Blocks</font>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr">
<div id=3D"x_m_4574273483018812099x_x_x_divtagdefaultwrapper" dir=3D"ltr" s=
tyle=3D"font-size:12pt; font-family:Calibri,Helvetica,sans-serif,EmojiFont,=
&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&qu=
ot;Segoe UI Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols">
<div style=3D"margin-top:0px; margin-bottom:0px">There are really two separ=
ate problems to solve.</div>
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<ol style=3D"margin-bottom:0px; margin-top:0px">
<li>How does Bitcoin scale with fixed block size?</li><li>How do we ensure =
that all valid transactions are eventually included in the blockchain?</li>=
</ol>
<br>
<div style=3D"margin-top:0px; margin-bottom:0px">Those are the two issues t=
hat the proposal attempts to address. It makes sense to resolve these two p=
roblems together. Using the proposed system for variable block sizes would =
solve the first problem but there
 would still be a whole bunch of never confirming transactions. I am not su=
re how to reliably solve the second problem at scale without first solving =
the first.<br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px">&gt;* Every node has a (po=
tentially) different mempool, you can't use it to decide consensus values l=
ike the max block size.&nbsp;<br>
</div>
<div><br>
I do not suggest a consensus. Depending on which node solves a block the va=
lue for next block size will be different. The consensus would be that bloc=
ks will adhere to the next block size value transmitted with the current bl=
ock. It is easy to verify that the
 consensus is being adhered to once in place.<br>
&nbsp;<br>
</div>
<div>&gt;* Increasing the entropy in a block to make it more unpredictable =
doesn't really make sense.&nbsp;</div>
<div><br>
Not a necessary function, just an effect of using a probability-based distr=
ibution.<span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">&n=
bsp;</span><br>
<br>
</div>
<div>&gt;* Bitcoin should be roughly incentive compatible. Your proposal ex=
plicits asks miners to ignore their best interests, and confirm transaction=
s by &quot;priority&quot;.&nbsp; What are you going to do if a &quot;malici=
ous&quot; miner decides to go after their profits and order
 by what makes them the most money. Add &quot;ordered by priority&quot; as =
a consensus requirement? And even if you miners can still sort their mempoo=
l by fee, and then order the top 1MB by priority.<br>
<br>
I entirely agree with your sentiment that Bitcoin must be incentive compati=
ble. It is necessary.<br>
<br>
It is in only miners immediate interest to make the most profitable block f=
rom the available transaction pool. As with so many other things, it is nec=
essary to partially ignore short-term gain for long-term benefit. It is in =
miners and everybody's long-term
 interest to have a reliable transaction service. A busy transaction servic=
e that confirms lots of transactions per hour will become more profitable a=
s demand increases and more users are prepared to pay for priority. As it i=
s there is currently no way to fully
 scale because of the transaction bandwidth limit and that is problematic. =
If all valid transactions must eventually confirm then there must be a way =
to resolve that problem.<br>
<br>
Bitcoin deliberately removes traditional scale by ensuring blocks take ten =
minutes on average to solve, an ingenious idea and, incentive compatible bu=
t, fixed block sizes leaves us with a problem to solve when we want to scal=
e.<br>
<br>
</div>
<div>&gt;If you could find a good solution that would allow you to know if =
miners were following your rule or not (and thus ignore it if it doesn't) t=
hen you wouldn't even need bitcoin in the first place.<br>
<br>
I am confident that the math to verify blocks based on the proposal can be =
developed (and I think it will not be too complex for a mathematician with =
the relevant experience), however, I am nowhere near experienced enough wit=
h probability and statistical analysis
 to do it. Yes, if Bitcoin doesn't then it might make another great opportu=
nity for an altcoin but I am not even nearly interested in promoting any al=
tcoins.<br>
</div>
<p style=3D"margin-top:0px; margin-bottom:0px"></p>
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px">If not the proposal that I=
 have put forward, then, hopefully, someone can come up with a better solut=
ion. The important thing is that the issues are resolved.<br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px">Regards,</div>
<div style=3D"margin-top:0px; margin-bottom:0px">Damian Williamson<br>
</div>
<br>
<br>
<div>
<hr style=3D"display:inline-block; width:654.625px">
<div id=3D"x_m_4574273483018812099x_x_x_divRplyFwdMsg" dir=3D"ltr"><font fa=
ce=3D"Calibri, sans-serif" style=3D"font-size:11pt"><b>From:</b><span class=
=3D"x_m_4574273483018812099x_x_Apple-converted-space">&nbsp;</span>Rhavar &=
lt;<a href=3D"mailto:rhavar@protonmail.com" target=3D"_blank">rhavar@proton=
mail.com</a>&gt;<br>
<b>Sent:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-space=
">&nbsp;</span>Saturday, 16 December 2017 3:38 AM<br>
<b>To:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">=
&nbsp;</span>Damian Williamson<br>
<b>Cc:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">=
&nbsp;</span>Bitcoin Protocol Discussion<br>
<b>Subject:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-sp=
ace">&nbsp;</span>Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use T=
ransaction Priority For Ordering Transactions In Blocks</font>
<div>&nbsp;</div>
</div>
<div>
<div>&gt;&nbsp;I understand that there would be technical issues to resolve=
 in implementation, but, are there no fundamental errors?<br>
</div>
<div><br>
</div>
<div>Unfortunately your proposal is really fundamentally broken, on a few l=
evels. I think you might need to do a bit more research into how bitcoin wo=
rks before coming up with such improvements =3D)<br>
</div>
<div><br>
</div>
<div>But just some quick notes:<br>
</div>
<div><br>
</div>
<div>* Every node has a (potentially) different mempool, you can't use it t=
o decide consensus values like the max block size.&nbsp;<br>
</div>
<div><br>
</div>
<div>* Increasing the entropy in a block to make it more unpredictable does=
n't really make sense.&nbsp;</div>
<div><br>
</div>
<div>* Bitcoin should be roughly incentive compatible. Your proposal explic=
its asks miners to ignore their best interests, and confirm transactions by=
 &quot;priority&quot;.&nbsp; What are you going to do if a &quot;malicious&=
quot; miner decides to go after their profits and order by
 what makes them the most money. Add &quot;ordered by priority&quot; as a c=
onsensus requirement? And even if you miners can still sort their mempool b=
y fee, and then order the top 1MB by priority.<br>
</div>
<div><br>
</div>
<div>If you could find a good solution that would allow you to know if mine=
rs were following your rule or not (and thus ignore it if it doesn't) then =
you wouldn't even need bitcoin in the first place.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div class=3D"x_m_4574273483018812099x_x_x_x_protonmail_signature_block">
<div class=3D"x_m_4574273483018812099x_x_x_x_protonmail_signature_block-use=
r">
<div>-Ryan<br>
</div>
</div>
<div class=3D"x_m_4574273483018812099x_x_x_x_protonmail_signature_block-pro=
ton x_m_4574273483018812099x_x_x_x_protonmail_signature_block-empty">
<br>
</div>
</div>
<div><br>
</div>
<blockquote class=3D"x_m_4574273483018812099x_x_x_x_protonmail_quote" type=
=3D"cite">
<div>-------- Original Message --------<br>
</div>
<div>Subject: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transacti=
on Priority For Ordering Transactions In Blocks<br>
</div>
<div>Local Time: December 15, 2017 3:42 AM<br>
</div>
<div>UTC Time: December 15, 2017 9:42 AM<br>
</div>
<div>From:<span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">=
&nbsp;</span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
</div>
<div>To: Bitcoin Protocol Discussion &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfounda=
tion.org</a>&gt;<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div dir=3D"ltr" style=3D"font-size:12pt; font-family:Calibri,Helvetica,san=
s-serif,EmojiFont,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,=
NotoColorEmoji,&quot;Segoe UI Symbol&quot;,&quot;Android Emoji&quot;,EmojiS=
ymbols">
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<div>
<div>I should not take it that the lack of critical feedback to this revise=
d proposal is a glowing endorsement. I understand that there would be techn=
ical issues to resolve in implementation, but, are there no fundamental err=
ors?<br>
</div>
<div><br>
</div>
<div>I suppose that it if is difficult to determine how long a transaction =
has been waiting in the pool then, each node could simply keep track of whe=
n a transaction was first seen. This may have implications for a verify rou=
tine, however, for example, if a
 node was offline, how should it differentiate how long each transaction wa=
s waiting in that case? If a node was restarted daily would it always think=
 that all transactions had been waiting in the pool less than one day If ea=
ch node keeps the current transaction
 pool in a file and updates it, as transactions are included in blocks and,=
 as new transactions appear in the pool, then that would go some way to all=
eviate the issue, apart from entirely new nodes. There should be no reason =
the contents of a transaction pool
 files cannot be shared without agreement as to the transaction pool<span c=
lass=3D"x_m_4574273483018812099x_x_Apple-converted-space">&nbsp;</span><spa=
n>between nodes</span>, just as nodes transmit new transactions freely.<br>
</div>
<div><br>
</div>
<div>It has been questioned why miners could not cheat. For the question of=
 how many transactions to include in a block, I say it is a standoff and mi=
ners will conform to the proposal, not wanting to leave transactions with v=
alid fees standing, and, not wanting
 to shrink the transaction pool. In any case, if miners shrink the transact=
ion pool then I am not immediately concerned since it provides a more effic=
ient service. For the question of including transactions according to the p=
roposal, I say if it is possible
 to keep track of how long transactions are waiting in the pool so that the=
y can be included on a probability curve then it is possible to verify that=
 blocks conform to the proposal, since the input is a probability, the outp=
ut should conform to a probability
 curve.<br>
</div>
</div>
<div><br>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<div>If someone has the necessary skill, would anyone be willing to develop=
 the math necessary for the proposal?<br>
</div>
<div><br>
</div>
<div>Regards,<br>
</div>
<div>Damian Williamson<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<hr style=3D"display:inline-block; width:644.828125px">
<span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">&nbsp;</sp=
an><br>
</div>
<div dir=3D"ltr">
<div><span class=3D"x_m_4574273483018812099x_x_x_x_font" style=3D"font-fami=
ly:Calibri,sans-serif"><span class=3D"x_m_4574273483018812099x_x_x_x_colour=
"><b>From:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-spa=
ce">&nbsp;</span><a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev-bounces@<wbr>lists.linuxfoundation.org=
</a><span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">&nbsp;=
</span>&lt;<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org"=
 target=3D"_blank">bit<wbr>coin-dev-bounces@lists.<wbr>linuxfoundation.org<=
/a>&gt;
 on behalf of Damian Williamson via bitcoin-dev &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>=
linuxfoundation.org</a>&gt;<br>
<b>Sent:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-space=
">&nbsp;</span>Friday, 8 December 2017 8:01 AM<br>
<b>To:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">=
&nbsp;</span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<b>Subject:</b><span class=3D"x_m_4574273483018812099x_x_Apple-converted-sp=
ace">&nbsp;</span>[bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Trans=
action Priority For Ordering Transactions In Blocks</span></span></div>
<div>&nbsp;<br>
</div>
</div>
<div dir=3D"ltr">
<div dir=3D"ltr" style=3D"font-size:12pt; font-family:Calibri,Helvetica,san=
s-serif,EmojiFont,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,=
NotoColorEmoji,&quot;Segoe UI Symbol&quot;,&quot;Android Emoji&quot;,EmojiS=
ymbols">
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
<div>
<div>Good afternoon,<br>
</div>
<div><br>
</div>
<div>The need for this proposal:<br>
</div>
<div><br>
</div>
<div>We all must learn to admit that transaction bandwidth is still lurking=
 as a serious issue for the operation, reliability, safety, consumer accept=
ance, uptake and, for the value of Bitcoin.<br>
</div>
<div><br>
</div>
<div>I recently sent a payment which was not urgent so; I chose three-day t=
arget confirmation from the fee recommendation. That transaction has still =
not confirmed after now more than six days - even waiting twice as long see=
ms quite reasonable to me. That
 transaction is a valid transaction; it is not rubbish, junk or, spam. Unde=
r the current model with transaction bandwidth limitation, the longer a tra=
nsaction waits, the less likely it is ever to confirm due to rising transac=
tion numbers and being pushed back
 by transactions with rising fees.<br>
</div>
<div><br>
</div>
<div>I argue that no transactions are rubbish or junk, only some zero fee t=
ransactions might be spam. Having an ever-increasing number of valid transa=
ctions that do not confirm as more new transactions with higher fees are cr=
eated is the opposite of operating
 a robust, reliable transaction system.<br>
</div>
<div><br>
</div>
<div>Business cannot operate with a model where transactions may or may not=
 confirm. Even a business choosing a modest fee has no guarantee that their=
 valid transaction will not be shuffled down by new transactions to the rea=
lm of never confirming after it
 is created. Consumers also will not accept this model as Bitcoin expands. =
If Bitcoin cannot be a reliable payment system for confirmed transactions t=
hen consumers, by and large, will simply not accept the model once they und=
erstand. Bitcoin will be a dirty
 payment system, and this will kill the value of Bitcoin.<br>
</div>
<div><br>
</div>
<div>Under the current system, a minority of transactions will eventually b=
e the lucky few who have fees high enough to escape being pushed down the l=
ist.<br>
</div>
<div><br>
</div>
<div>Once there are more than x transactions (transaction bandwidth limit) =
every ten minutes, only those choosing twenty-minute confirmation (2 blocks=
) will have initially at most a fifty percent chance of ever having their p=
ayment confirm. Presently, not even
 using fee recommendations can ensure a sufficiently high fee is paid to en=
sure transaction confirmation.<br>
</div>
<div><br>
</div>
<div>I also argue that the current auction model for limited transaction ba=
ndwidth is wrong, is not suitable for a reliable transaction system and, is=
 wrong for Bitcoin. All transactions must confirm in due time. Currently, B=
itcoin is not a safe way to send
 payments.<br>
</div>
<div><br>
</div>
<div>I do not believe that consumers and business are against paying fees, =
even high fees. What is required is operational reliability.<br>
</div>
<div><br>
</div>
<div>This great issue needs to be resolved for the safety and reliability o=
f Bitcoin. The time to resolve issues in commerce is before they become gre=
at big issues. The time to resolve this issue is now. We must have the fore=
sight to identify and resolve problems
 before they trip us over.&nbsp; Simply doubling block sizes every so often=
 is reactionary and is not a reliable permanent solution. I have written a =
BIP proposal for a technical solution but, need your help to write it up to=
 an acceptable standard to be a full
 BIP.<br>
</div>
<div><br>
</div>
<div>I have formatted the following with markdown which is human readable s=
o, I hope nobody minds. I have done as much with this proposal as I feel th=
at I am able so far but continue to take your feedback.<br>
</div>
<div><br>
</div>
<div># BIP Proposal: UTPFOTIB - Use Transaction Priority For Ordering Trans=
actions In Blocks<br>
</div>
<div><br>
</div>
<div>## The problem:<br>
</div>
<div>Everybody wants value. Miners want to maximize revenue from fees (and =
we presume, to minimize block size). Consumers need transaction reliability=
 and, (we presume) want low fees.<br>
</div>
<div><br>
</div>
<div>The current transaction bandwidth limit is a limiting factor for both.=
 As the operational safety of transactions is limited, so is consumer confi=
dence as they realize the issue and, accordingly, uptake is limited. Fees a=
re artificially inflated due to
 bandwidth limitations while failing to provide a full confirmation service=
 for all transactions.<br>
</div>
<div><br>
</div>
<div>Current fee recommendations provide no satisfaction for transaction re=
liability and, as Bitcoin scales, this will worsen.<br>
</div>
<div><br>
</div>
<div>Bitcoin must be a fully scalable and reliable service, providing full =
transaction confirmation for every valid transaction.<br>
</div>
<div><br>
</div>
<div>The possibility to send a transaction with a fee lower than one that i=
s acceptable to allow eventual transaction confirmation should be removed f=
rom the protocol and also from the user interface.<br>
</div>
<div><br>
</div>
<div>## Solution summary:<br>
</div>
<div>Provide each transaction with an individual transaction priority each =
time before choosing transactions to include in the current block, the prio=
rity being a function of the fee paid (on a curve), and the time waiting in=
 the transaction pool (also on a
 curve) out to n days (n=3D60 ?). The transaction priority to serve as the =
likelihood of a transaction being included in the current block, and for de=
termining the order in which transactions are tried to see if they will be =
included.<span class=3D"x_m_4574273483018812099x_x_Apple-converted-space">&=
nbsp;</span><br>
</div>
<div><br>
</div>
<div>Use a target block size. Determine the target block size using; curren=
t transaction pool size x ( 1 / (144 x n days ) ) =3D number of transaction=
s to be included in the current block. Broadcast the next target block size=
 with the current block when it is
 solved so that nodes know the next target block size for the block that th=
ey are building on.<br>
</div>
<div><br>
</div>
<div>The curves used for the priority of transactions would have to be appr=
opriate. Perhaps a mathematician with experience in probability can develop=
 the right formulae. My thinking is a steep curve. I suppose that the proba=
bility of all transactions should
 probably account for a sufficient number of inclusions that the target blo=
ck size is met although, it may not always be. As a suggestion, consider in=
cluding some zero fee transactions to pad, highest BTC value first?<br>
</div>
<div><br>
</div>
<div>**Explanation of the operation of priority:**<br>
</div>
<div>&gt; If transaction priority is, for example, a number between one (lo=
w) and one-hundred (high) it can be directly understood as the percentage c=
hance in one-hundred of a transaction being included in the block. Using pr=
obability or likelihood infers that
 there is some function of random. If random (100) &lt; transaction priorit=
y then the transaction is included.<br>
</div>
<div><br>
</div>
<div>&gt;To break it down further, if both the fee on a curve value and the=
 time waiting on a curve value are each a number between one and one-hundre=
d, a rudimentary method may be to simply multiply those two numbers, to fin=
d the priority number. For example,
 a middle fee transaction waiting thirty days (if n =3D 60 days) may have a=
 value of five for each part&nbsp; (yes, just five, the values are on a cur=
ve). When multiplied that will give a priority value of twenty-five, or,&nb=
sp; a twenty-five percent chance at that moment
 of being included in the block; it will likely be included in one of the n=
ext four blocks, getting more likely each chance. If it is still not includ=
ed then the value of time waiting will be higher, making for more probabili=
ty. A very low fee transaction would
 have a value for the fee of one. It would not be until near sixty-days tha=
t the particular low fee transaction has a high likelihood of being include=
d in the block.<br>
</div>
<div><br>
</div>
<div>I am not concerned with low (or high) transaction fees, the primary re=
ason for addressing the issue is to ensure transactional reliability and sc=
alability while having each transaction confirm in due time.<br>
</div>
<div><br>
</div>
<div>## Pros:<br>
</div>
<div>* Maximizes transaction reliability.<br>
</div>
<div>* Fully scalable.<br>
</div>
<div>* Maximizes possibility for consumer and business uptake.<br>
</div>
<div>* Maximizes total fees paid per block without reducing reliability; be=
cause of reliability, in time confidence and overall uptake are greater; th=
erefore, more transactions.<br>
</div>
<div>* Market determines fee paid for transaction priority.<br>
</div>
<div>* Fee recommendations work all the way out to 30 days or greater.<br>
</div>
<div>* Provides additional block entropy; greater security since there is l=
ess probability of predicting the next block.<br>
</div>
<div><br>
</div>
<div>## Cons:<br>
</div>
<div>* Could initially lower total transaction fees per block.<br>
</div>
<div>* Must be first be programmed.<br>
</div>
<div><br>
</div>
<div>## Solution operation:<br>
</div>
<div>This is a simplistic view of the operation. The actual operation will =
need to be determined in a spec for the programmer.<br>
</div>
<div><br>
</div>
<div>1. Determine the target block size for the current block.<br>
</div>
<div>2. Assign a transaction priority to each transaction in the pool.<br>
</div>
<div>3. Select transactions to include in the current block using probabili=
ty in transaction priority order until the target block size is met.<br>
</div>
<div>5. Solve block.<br>
</div>
<div>6. Broadcast the next target block size with the current block when it=
 is solved.<br>
</div>
<div>7. Block is received.<br>
</div>
<div>8. Block verification process.<br>
</div>
<div>9. Accept/reject block based on verification result.<br>
</div>
<div>10. Repeat.<br>
</div>
<div><br>
</div>
<div>## Closing comments:<br>
</div>
<div>It may be possible to verify blocks conform to the proposal by showing=
 that the probability for all transactions included in the block statistica=
lly conforms to a probability distribution curve, *if* the individual trans=
action priority can be recreated.
 I am not that deep into the mathematics; however, it may also be possible =
to use a similar method to do this just based on the fee, that statisticall=
y, the blocks conform to a fee distribution. Any zero fee transactions woul=
d have to be ignored. This solution
 needs a clever mathematician.<br>
</div>
<div><br>
</div>
<div>I implore, at the very least, that we use some method that validates f=
ull transaction reliability and enables scalability of block sizes. If not =
this proposal, an alternative.<br>
</div>
<div><br>
</div>
<div>Regards,<br>
</div>
<div>Damian Williamson<br>
</div>
</div>
<div style=3D"margin-top:0px; margin-bottom:0px"><br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<span style=3D"font-family:Helvetica; font-size:12px; font-style:normal; fo=
nt-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px;=
 text-transform:none; white-space:normal; word-spacing:0px; float:none; dis=
play:inline!important">______________________________<wbr>_________________=
</span><br style=3D"font-family:Helvetica; font-size:12px; font-style:norma=
l; font-weight:normal; letter-spacing:normal; text-align:start; text-indent=
:0px; text-transform:none; white-space:normal; word-spacing:0px">
<span style=3D"font-family:Helvetica; font-size:12px; font-style:normal; fo=
nt-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px;=
 text-transform:none; white-space:normal; word-spacing:0px; float:none; dis=
play:inline!important">bitcoin-dev
 mailing list</span><br style=3D"font-family:Helvetica; font-size:12px; fon=
t-style:normal; font-weight:normal; letter-spacing:normal; text-align:start=
; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0p=
x">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
style=3D"font-family:Helvetica; font-size:12px; font-style:normal; font-wei=
ght:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-=
transform:none; white-space:normal; word-spacing:0px">bitcoin-dev@lists.<wb=
r>linuxfoundation.org</a><br style=3D"font-family:Helvetica; font-size:12px=
; font-style:normal; font-weight:normal; letter-spacing:normal; text-align:=
start; text-indent:0px; text-transform:none; white-space:normal; word-spaci=
ng:0px">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank" style=3D"font-family:Helvetica; font-size:12px; font-styl=
e:normal; font-weight:normal; letter-spacing:normal; text-align:start; text=
-indent:0px; text-transform:none; white-space:normal; word-spacing:0px">htt=
ps://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a></=
div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
</blockquote>
</div>
</div>
</div>
</body>
</html>

--_000_PS2P216MB0179D452E5D478511B46E0879D000PS2P216MB0179KORP_--