Repository navigation
Expand file tree
/
Copy pathch09_fees.html
More file actions
1254 lines (1254 loc) · 68.1 KB
/
Copy pathch09_fees.html
File metadata and controls
1254 lines (1254 loc) · 68.1 KB
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
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 2.0.20">
<title>Transaction Fees</title>
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700">
<style>
/*! Asciidoctor default stylesheet | MIT License | https://asciidoctor.org */
/* Uncomment the following line when using as a custom stylesheet */
/* @import "https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"; */
html{font-family:sans-serif;-webkit-text-size-adjust:100%}
a{background:none}
a:focus{outline:thin dotted}
a:active,a:hover{outline:0}
h1{font-size:2em;margin:.67em 0}
b,strong{font-weight:bold}
abbr{font-size:.9em}
abbr[title]{cursor:help;border-bottom:1px dotted #dddddf;text-decoration:none}
dfn{font-style:italic}
hr{height:0}
mark{background:#ff0;color:#000}
code,kbd,pre,samp{font-family:monospace;font-size:1em}
pre{white-space:pre-wrap}
q{quotes:"\201C" "\201D" "\2018" "\2019"}
small{font-size:80%}
sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}
sup{top:-.5em}
sub{bottom:-.25em}
img{border:0}
svg:not(:root){overflow:hidden}
figure{margin:0}
audio,video{display:inline-block}
audio:not([controls]){display:none;height:0}
fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em}
legend{border:0;padding:0}
button,input,select,textarea{font-family:inherit;font-size:100%;margin:0}
button,input{line-height:normal}
button,select{text-transform:none}
button,html input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer}
button[disabled],html input[disabled]{cursor:default}
input[type=checkbox],input[type=radio]{padding:0}
button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0}
textarea{overflow:auto;vertical-align:top}
table{border-collapse:collapse;border-spacing:0}
*,::before,::after{box-sizing:border-box}
html,body{font-size:100%}
body{background:#fff;color:rgba(0,0,0,.8);padding:0;margin:0;font-family:"Noto Serif","DejaVu Serif",serif;line-height:1;position:relative;cursor:auto;-moz-tab-size:4;-o-tab-size:4;tab-size:4;word-wrap:anywhere;-moz-osx-font-smoothing:grayscale;-webkit-font-smoothing:antialiased}
a:hover{cursor:pointer}
img,object,embed{max-width:100%;height:auto}
object,embed{height:100%}
img{-ms-interpolation-mode:bicubic}
.left{float:left!important}
.right{float:right!important}
.text-left{text-align:left!important}
.text-right{text-align:right!important}
.text-center{text-align:center!important}
.text-justify{text-align:justify!important}
.hide{display:none}
img,object,svg{display:inline-block;vertical-align:middle}
textarea{height:auto;min-height:50px}
select{width:100%}
.subheader,.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{line-height:1.45;color:#7a2518;font-weight:400;margin-top:0;margin-bottom:.25em}
div,dl,dt,dd,ul,ol,li,h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6,pre,form,p,blockquote,th,td{margin:0;padding:0}
a{color:#2156a5;text-decoration:underline;line-height:inherit}
a:hover,a:focus{color:#1d4b8f}
a img{border:0}
p{line-height:1.6;margin-bottom:1.25em;text-rendering:optimizeLegibility}
p aside{font-size:.875em;line-height:1.35;font-style:italic}
h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{font-family:"Open Sans","DejaVu Sans",sans-serif;font-weight:300;font-style:normal;color:#ba3925;text-rendering:optimizeLegibility;margin-top:1em;margin-bottom:.5em;line-height:1.0125em}
h1 small,h2 small,h3 small,#toctitle small,.sidebarblock>.content>.title small,h4 small,h5 small,h6 small{font-size:60%;color:#e99b8f;line-height:0}
h1{font-size:2.125em}
h2{font-size:1.6875em}
h3,#toctitle,.sidebarblock>.content>.title{font-size:1.375em}
h4,h5{font-size:1.125em}
h6{font-size:1em}
hr{border:solid #dddddf;border-width:1px 0 0;clear:both;margin:1.25em 0 1.1875em}
em,i{font-style:italic;line-height:inherit}
strong,b{font-weight:bold;line-height:inherit}
small{font-size:60%;line-height:inherit}
code{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;font-weight:400;color:rgba(0,0,0,.9)}
ul,ol,dl{line-height:1.6;margin-bottom:1.25em;list-style-position:outside;font-family:inherit}
ul,ol{margin-left:1.5em}
ul li ul,ul li ol{margin-left:1.25em;margin-bottom:0}
ul.circle{list-style-type:circle}
ul.disc{list-style-type:disc}
ul.square{list-style-type:square}
ul.circle ul:not([class]),ul.disc ul:not([class]),ul.square ul:not([class]){list-style:inherit}
ol li ul,ol li ol{margin-left:1.25em;margin-bottom:0}
dl dt{margin-bottom:.3125em;font-weight:bold}
dl dd{margin-bottom:1.25em}
blockquote{margin:0 0 1.25em;padding:.5625em 1.25em 0 1.1875em;border-left:1px solid #ddd}
blockquote,blockquote p{line-height:1.6;color:rgba(0,0,0,.85)}
@media screen and (min-width:768px){h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2}
h1{font-size:2.75em}
h2{font-size:2.3125em}
h3,#toctitle,.sidebarblock>.content>.title{font-size:1.6875em}
h4{font-size:1.4375em}}
table{background:#fff;margin-bottom:1.25em;border:1px solid #dedede;word-wrap:normal}
table thead,table tfoot{background:#f7f8f7}
table thead tr th,table thead tr td,table tfoot tr th,table tfoot tr td{padding:.5em .625em .625em;font-size:inherit;color:rgba(0,0,0,.8);text-align:left}
table tr th,table tr td{padding:.5625em .625em;font-size:inherit;color:rgba(0,0,0,.8)}
table tr.even,table tr.alt{background:#f8f8f7}
table thead tr th,table tfoot tr th,table tbody tr td,table tr td,table tfoot tr td{line-height:1.6}
h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2;word-spacing:-.05em}
h1 strong,h2 strong,h3 strong,#toctitle strong,.sidebarblock>.content>.title strong,h4 strong,h5 strong,h6 strong{font-weight:400}
.center{margin-left:auto;margin-right:auto}
.stretch{width:100%}
.clearfix::before,.clearfix::after,.float-group::before,.float-group::after{content:" ";display:table}
.clearfix::after,.float-group::after{clear:both}
:not(pre).nobreak{word-wrap:normal}
:not(pre).nowrap{white-space:nowrap}
:not(pre).pre-wrap{white-space:pre-wrap}
:not(pre):not([class^=L])>code{font-size:.9375em;font-style:normal!important;letter-spacing:0;padding:.1em .5ex;word-spacing:-.15em;background:#f7f7f8;border-radius:4px;line-height:1.45;text-rendering:optimizeSpeed}
pre{color:rgba(0,0,0,.9);font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;line-height:1.45;text-rendering:optimizeSpeed}
pre code,pre pre{color:inherit;font-size:inherit;line-height:inherit}
pre>code{display:block}
pre.nowrap,pre.nowrap pre{white-space:pre;word-wrap:normal}
em em{font-style:normal}
strong strong{font-weight:400}
.keyseq{color:rgba(51,51,51,.8)}
kbd{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;display:inline-block;color:rgba(0,0,0,.8);font-size:.65em;line-height:1.45;background:#f7f7f7;border:1px solid #ccc;border-radius:3px;box-shadow:0 1px 0 rgba(0,0,0,.2),inset 0 0 0 .1em #fff;margin:0 .15em;padding:.2em .5em;vertical-align:middle;position:relative;top:-.1em;white-space:nowrap}
.keyseq kbd:first-child{margin-left:0}
.keyseq kbd:last-child{margin-right:0}
.menuseq,.menuref{color:#000}
.menuseq b:not(.caret),.menuref{font-weight:inherit}
.menuseq{word-spacing:-.02em}
.menuseq b.caret{font-size:1.25em;line-height:.8}
.menuseq i.caret{font-weight:bold;text-align:center;width:.45em}
b.button::before,b.button::after{position:relative;top:-1px;font-weight:400}
b.button::before{content:"[";padding:0 3px 0 2px}
b.button::after{content:"]";padding:0 2px 0 3px}
p a>code:hover{color:rgba(0,0,0,.9)}
#header,#content,#footnotes,#footer{width:100%;margin:0 auto;max-width:62.5em;*zoom:1;position:relative;padding-left:.9375em;padding-right:.9375em}
#header::before,#header::after,#content::before,#content::after,#footnotes::before,#footnotes::after,#footer::before,#footer::after{content:" ";display:table}
#header::after,#content::after,#footnotes::after,#footer::after{clear:both}
#content{margin-top:1.25em}
#content::before{content:none}
#header>h1:first-child{color:rgba(0,0,0,.85);margin-top:2.25rem;margin-bottom:0}
#header>h1:first-child+#toc{margin-top:8px;border-top:1px solid #dddddf}
#header>h1:only-child,body.toc2 #header>h1:nth-last-child(2){border-bottom:1px solid #dddddf;padding-bottom:8px}
#header .details{border-bottom:1px solid #dddddf;line-height:1.45;padding-top:.25em;padding-bottom:.25em;padding-left:.25em;color:rgba(0,0,0,.6);display:flex;flex-flow:row wrap}
#header .details span:first-child{margin-left:-.125em}
#header .details span.email a{color:rgba(0,0,0,.85)}
#header .details br{display:none}
#header .details br+span::before{content:"\00a0\2013\00a0"}
#header .details br+span.author::before{content:"\00a0\22c5\00a0";color:rgba(0,0,0,.85)}
#header .details br+span#revremark::before{content:"\00a0|\00a0"}
#header #revnumber{text-transform:capitalize}
#header #revnumber::after{content:"\00a0"}
#content>h1:first-child:not([class]){color:rgba(0,0,0,.85);border-bottom:1px solid #dddddf;padding-bottom:8px;margin-top:0;padding-top:1rem;margin-bottom:1.25rem}
#toc{border-bottom:1px solid #e7e7e9;padding-bottom:.5em}
#toc>ul{margin-left:.125em}
#toc ul.sectlevel0>li>a{font-style:italic}
#toc ul.sectlevel0 ul.sectlevel1{margin:.5em 0}
#toc ul{font-family:"Open Sans","DejaVu Sans",sans-serif;list-style-type:none}
#toc li{line-height:1.3334;margin-top:.3334em}
#toc a{text-decoration:none}
#toc a:active{text-decoration:underline}
#toctitle{color:#7a2518;font-size:1.2em}
@media screen and (min-width:768px){#toctitle{font-size:1.375em}
body.toc2{padding-left:15em;padding-right:0}
#toc.toc2{margin-top:0!important;background:#f8f8f7;position:fixed;width:15em;left:0;top:0;border-right:1px solid #e7e7e9;border-top-width:0!important;border-bottom-width:0!important;z-index:1000;padding:1.25em 1em;height:100%;overflow:auto}
#toc.toc2 #toctitle{margin-top:0;margin-bottom:.8rem;font-size:1.2em}
#toc.toc2>ul{font-size:.9em;margin-bottom:0}
#toc.toc2 ul ul{margin-left:0;padding-left:1em}
#toc.toc2 ul.sectlevel0 ul.sectlevel1{padding-left:0;margin-top:.5em;margin-bottom:.5em}
body.toc2.toc-right{padding-left:0;padding-right:15em}
body.toc2.toc-right #toc.toc2{border-right-width:0;border-left:1px solid #e7e7e9;left:auto;right:0}}
@media screen and (min-width:1280px){body.toc2{padding-left:20em;padding-right:0}
#toc.toc2{width:20em}
#toc.toc2 #toctitle{font-size:1.375em}
#toc.toc2>ul{font-size:.95em}
#toc.toc2 ul ul{padding-left:1.25em}
body.toc2.toc-right{padding-left:0;padding-right:20em}}
#content #toc{border:1px solid #e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;border-radius:4px}
#content #toc>:first-child{margin-top:0}
#content #toc>:last-child{margin-bottom:0}
#footer{max-width:none;background:rgba(0,0,0,.8);padding:1.25em}
#footer-text{color:hsla(0,0%,100%,.8);line-height:1.44}
#content{margin-bottom:.625em}
.sect1{padding-bottom:.625em}
@media screen and (min-width:768px){#content{margin-bottom:1.25em}
.sect1{padding-bottom:1.25em}}
.sect1:last-child{padding-bottom:0}
.sect1+.sect1{border-top:1px solid #e7e7e9}
#content h1>a.anchor,h2>a.anchor,h3>a.anchor,#toctitle>a.anchor,.sidebarblock>.content>.title>a.anchor,h4>a.anchor,h5>a.anchor,h6>a.anchor{position:absolute;z-index:1001;width:1.5ex;margin-left:-1.5ex;display:block;text-decoration:none!important;visibility:hidden;text-align:center;font-weight:400}
#content h1>a.anchor::before,h2>a.anchor::before,h3>a.anchor::before,#toctitle>a.anchor::before,.sidebarblock>.content>.title>a.anchor::before,h4>a.anchor::before,h5>a.anchor::before,h6>a.anchor::before{content:"\00A7";font-size:.85em;display:block;padding-top:.1em}
#content h1:hover>a.anchor,#content h1>a.anchor:hover,h2:hover>a.anchor,h2>a.anchor:hover,h3:hover>a.anchor,#toctitle:hover>a.anchor,.sidebarblock>.content>.title:hover>a.anchor,h3>a.anchor:hover,#toctitle>a.anchor:hover,.sidebarblock>.content>.title>a.anchor:hover,h4:hover>a.anchor,h4>a.anchor:hover,h5:hover>a.anchor,h5>a.anchor:hover,h6:hover>a.anchor,h6>a.anchor:hover{visibility:visible}
#content h1>a.link,h2>a.link,h3>a.link,#toctitle>a.link,.sidebarblock>.content>.title>a.link,h4>a.link,h5>a.link,h6>a.link{color:#ba3925;text-decoration:none}
#content h1>a.link:hover,h2>a.link:hover,h3>a.link:hover,#toctitle>a.link:hover,.sidebarblock>.content>.title>a.link:hover,h4>a.link:hover,h5>a.link:hover,h6>a.link:hover{color:#a53221}
details,.audioblock,.imageblock,.literalblock,.listingblock,.stemblock,.videoblock{margin-bottom:1.25em}
details{margin-left:1.25rem}
details>summary{cursor:pointer;display:block;position:relative;line-height:1.6;margin-bottom:.625rem;outline:none;-webkit-tap-highlight-color:transparent}
details>summary::-webkit-details-marker{display:none}
details>summary::before{content:"";border:solid transparent;border-left:solid;border-width:.3em 0 .3em .5em;position:absolute;top:.5em;left:-1.25rem;transform:translateX(15%)}
details[open]>summary::before{border:solid transparent;border-top:solid;border-width:.5em .3em 0;transform:translateY(15%)}
details>summary::after{content:"";width:1.25rem;height:1em;position:absolute;top:.3em;left:-1.25rem}
.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{text-rendering:optimizeLegibility;text-align:left;font-family:"Noto Serif","DejaVu Serif",serif;font-size:1rem;font-style:italic}
table.tableblock.fit-content>caption.title{white-space:nowrap;width:0}
.paragraph.lead>p,#preamble>.sectionbody>[class=paragraph]:first-of-type p{font-size:1.21875em;line-height:1.6;color:rgba(0,0,0,.85)}
.admonitionblock>table{border-collapse:separate;border:0;background:none;width:100%}
.admonitionblock>table td.icon{text-align:center;width:80px}
.admonitionblock>table td.icon img{max-width:none}
.admonitionblock>table td.icon .title{font-weight:bold;font-family:"Open Sans","DejaVu Sans",sans-serif;text-transform:uppercase}
.admonitionblock>table td.content{padding-left:1.125em;padding-right:1.25em;border-left:1px solid #dddddf;color:rgba(0,0,0,.6);word-wrap:anywhere}
.admonitionblock>table td.content>:last-child>:last-child{margin-bottom:0}
.exampleblock>.content{border:1px solid #e6e6e6;margin-bottom:1.25em;padding:1.25em;background:#fff;border-radius:4px}
.sidebarblock{border:1px solid #dbdbd6;margin-bottom:1.25em;padding:1.25em;background:#f3f3f2;border-radius:4px}
.sidebarblock>.content>.title{color:#7a2518;margin-top:0;text-align:center}
.exampleblock>.content>:first-child,.sidebarblock>.content>:first-child{margin-top:0}
.exampleblock>.content>:last-child,.exampleblock>.content>:last-child>:last-child,.exampleblock>.content .olist>ol>li:last-child>:last-child,.exampleblock>.content .ulist>ul>li:last-child>:last-child,.exampleblock>.content .qlist>ol>li:last-child>:last-child,.sidebarblock>.content>:last-child,.sidebarblock>.content>:last-child>:last-child,.sidebarblock>.content .olist>ol>li:last-child>:last-child,.sidebarblock>.content .ulist>ul>li:last-child>:last-child,.sidebarblock>.content .qlist>ol>li:last-child>:last-child{margin-bottom:0}
.literalblock pre,.listingblock>.content>pre{border-radius:4px;overflow-x:auto;padding:1em;font-size:.8125em}
@media screen and (min-width:768px){.literalblock pre,.listingblock>.content>pre{font-size:.90625em}}
@media screen and (min-width:1280px){.literalblock pre,.listingblock>.content>pre{font-size:1em}}
.literalblock pre,.listingblock>.content>pre:not(.highlight),.listingblock>.content>pre[class=highlight],.listingblock>.content>pre[class^="highlight "]{background:#f7f7f8}
.literalblock.output pre{color:#f7f7f8;background:rgba(0,0,0,.9)}
.listingblock>.content{position:relative}
.listingblock code[data-lang]::before{display:none;content:attr(data-lang);position:absolute;font-size:.75em;top:.425rem;right:.5rem;line-height:1;text-transform:uppercase;color:inherit;opacity:.5}
.listingblock:hover code[data-lang]::before{display:block}
.listingblock.terminal pre .command::before{content:attr(data-prompt);padding-right:.5em;color:inherit;opacity:.5}
.listingblock.terminal pre .command:not([data-prompt])::before{content:"$"}
.listingblock pre.highlightjs{padding:0}
.listingblock pre.highlightjs>code{padding:1em;border-radius:4px}
.listingblock pre.prettyprint{border-width:0}
.prettyprint{background:#f7f7f8}
pre.prettyprint .linenums{line-height:1.45;margin-left:2em}
pre.prettyprint li{background:none;list-style-type:inherit;padding-left:0}
pre.prettyprint li code[data-lang]::before{opacity:1}
pre.prettyprint li:not(:first-child) code[data-lang]::before{display:none}
table.linenotable{border-collapse:separate;border:0;margin-bottom:0;background:none}
table.linenotable td[class]{color:inherit;vertical-align:top;padding:0;line-height:inherit;white-space:normal}
table.linenotable td.code{padding-left:.75em}
table.linenotable td.linenos,pre.pygments .linenos{border-right:1px solid;opacity:.35;padding-right:.5em;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none}
pre.pygments span.linenos{display:inline-block;margin-right:.75em}
.quoteblock{margin:0 1em 1.25em 1.5em;display:table}
.quoteblock:not(.excerpt)>.title{margin-left:-1.5em;margin-bottom:.75em}
.quoteblock blockquote,.quoteblock p{color:rgba(0,0,0,.85);font-size:1.15rem;line-height:1.75;word-spacing:.1em;letter-spacing:0;font-style:italic;text-align:justify}
.quoteblock blockquote{margin:0;padding:0;border:0}
.quoteblock blockquote::before{content:"\201c";float:left;font-size:2.75em;font-weight:bold;line-height:.6em;margin-left:-.6em;color:#7a2518;text-shadow:0 1px 2px rgba(0,0,0,.1)}
.quoteblock blockquote>.paragraph:last-child p{margin-bottom:0}
.quoteblock .attribution{margin-top:.75em;margin-right:.5ex;text-align:right}
.verseblock{margin:0 1em 1.25em}
.verseblock pre{font-family:"Open Sans","DejaVu Sans",sans-serif;font-size:1.15rem;color:rgba(0,0,0,.85);font-weight:300;text-rendering:optimizeLegibility}
.verseblock pre strong{font-weight:400}
.verseblock .attribution{margin-top:1.25rem;margin-left:.5ex}
.quoteblock .attribution,.verseblock .attribution{font-size:.9375em;line-height:1.45;font-style:italic}
.quoteblock .attribution br,.verseblock .attribution br{display:none}
.quoteblock .attribution cite,.verseblock .attribution cite{display:block;letter-spacing:-.025em;color:rgba(0,0,0,.6)}
.quoteblock.abstract blockquote::before,.quoteblock.excerpt blockquote::before,.quoteblock .quoteblock blockquote::before{display:none}
.quoteblock.abstract blockquote,.quoteblock.abstract p,.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{line-height:1.6;word-spacing:0}
.quoteblock.abstract{margin:0 1em 1.25em;display:block}
.quoteblock.abstract>.title{margin:0 0 .375em;font-size:1.15em;text-align:center}
.quoteblock.excerpt>blockquote,.quoteblock .quoteblock{padding:0 0 .25em 1em;border-left:.25em solid #dddddf}
.quoteblock.excerpt,.quoteblock .quoteblock{margin-left:0}
.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{color:inherit;font-size:1.0625rem}
.quoteblock.excerpt .attribution,.quoteblock .quoteblock .attribution{color:inherit;font-size:.85rem;text-align:left;margin-right:0}
p.tableblock:last-child{margin-bottom:0}
td.tableblock>.content{margin-bottom:1.25em;word-wrap:anywhere}
td.tableblock>.content>:last-child{margin-bottom:-1.25em}
table.tableblock,th.tableblock,td.tableblock{border:0 solid #dedede}
table.grid-all>*>tr>*{border-width:1px}
table.grid-cols>*>tr>*{border-width:0 1px}
table.grid-rows>*>tr>*{border-width:1px 0}
table.frame-all{border-width:1px}
table.frame-ends{border-width:1px 0}
table.frame-sides{border-width:0 1px}
table.frame-none>colgroup+*>:first-child>*,table.frame-sides>colgroup+*>:first-child>*{border-top-width:0}
table.frame-none>:last-child>:last-child>*,table.frame-sides>:last-child>:last-child>*{border-bottom-width:0}
table.frame-none>*>tr>:first-child,table.frame-ends>*>tr>:first-child{border-left-width:0}
table.frame-none>*>tr>:last-child,table.frame-ends>*>tr>:last-child{border-right-width:0}
table.stripes-all>*>tr,table.stripes-odd>*>tr:nth-of-type(odd),table.stripes-even>*>tr:nth-of-type(even),table.stripes-hover>*>tr:hover{background:#f8f8f7}
th.halign-left,td.halign-left{text-align:left}
th.halign-right,td.halign-right{text-align:right}
th.halign-center,td.halign-center{text-align:center}
th.valign-top,td.valign-top{vertical-align:top}
th.valign-bottom,td.valign-bottom{vertical-align:bottom}
th.valign-middle,td.valign-middle{vertical-align:middle}
table thead th,table tfoot th{font-weight:bold}
tbody tr th{background:#f7f8f7}
tbody tr th,tbody tr th p,tfoot tr th,tfoot tr th p{color:rgba(0,0,0,.8);font-weight:bold}
p.tableblock>code:only-child{background:none;padding:0}
p.tableblock{font-size:1em}
ol{margin-left:1.75em}
ul li ol{margin-left:1.5em}
dl dd{margin-left:1.125em}
dl dd:last-child,dl dd:last-child>:last-child{margin-bottom:0}
li p,ul dd,ol dd,.olist .olist,.ulist .ulist,.ulist .olist,.olist .ulist{margin-bottom:.625em}
ul.checklist,ul.none,ol.none,ul.no-bullet,ol.no-bullet,ol.unnumbered,ul.unstyled,ol.unstyled{list-style-type:none}
ul.no-bullet,ol.no-bullet,ol.unnumbered{margin-left:.625em}
ul.unstyled,ol.unstyled{margin-left:0}
li>p:empty:only-child::before{content:"";display:inline-block}
ul.checklist>li>p:first-child{margin-left:-1em}
ul.checklist>li>p:first-child>.fa-square-o:first-child,ul.checklist>li>p:first-child>.fa-check-square-o:first-child{width:1.25em;font-size:.8em;position:relative;bottom:.125em}
ul.checklist>li>p:first-child>input[type=checkbox]:first-child{margin-right:.25em}
ul.inline{display:flex;flex-flow:row wrap;list-style:none;margin:0 0 .625em -1.25em}
ul.inline>li{margin-left:1.25em}
.unstyled dl dt{font-weight:400;font-style:normal}
ol.arabic{list-style-type:decimal}
ol.decimal{list-style-type:decimal-leading-zero}
ol.loweralpha{list-style-type:lower-alpha}
ol.upperalpha{list-style-type:upper-alpha}
ol.lowerroman{list-style-type:lower-roman}
ol.upperroman{list-style-type:upper-roman}
ol.lowergreek{list-style-type:lower-greek}
.hdlist>table,.colist>table{border:0;background:none}
.hdlist>table>tbody>tr,.colist>table>tbody>tr{background:none}
td.hdlist1,td.hdlist2{vertical-align:top;padding:0 .625em}
td.hdlist1{font-weight:bold;padding-bottom:1.25em}
td.hdlist2{word-wrap:anywhere}
.literalblock+.colist,.listingblock+.colist{margin-top:-.5em}
.colist td:not([class]):first-child{padding:.4em .75em 0;line-height:1;vertical-align:top}
.colist td:not([class]):first-child img{max-width:none}
.colist td:not([class]):last-child{padding:.25em 0}
.thumb,.th{line-height:0;display:inline-block;border:4px solid #fff;box-shadow:0 0 0 1px #ddd}
.imageblock.left{margin:.25em .625em 1.25em 0}
.imageblock.right{margin:.25em 0 1.25em .625em}
.imageblock>.title{margin-bottom:0}
.imageblock.thumb,.imageblock.th{border-width:6px}
.imageblock.thumb>.title,.imageblock.th>.title{padding:0 .125em}
.image.left,.image.right{margin-top:.25em;margin-bottom:.25em;display:inline-block;line-height:0}
.image.left{margin-right:.625em}
.image.right{margin-left:.625em}
a.image{text-decoration:none;display:inline-block}
a.image object{pointer-events:none}
sup.footnote,sup.footnoteref{font-size:.875em;position:static;vertical-align:super}
sup.footnote a,sup.footnoteref a{text-decoration:none}
sup.footnote a:active,sup.footnoteref a:active{text-decoration:underline}
#footnotes{padding-top:.75em;padding-bottom:.75em;margin-bottom:.625em}
#footnotes hr{width:20%;min-width:6.25em;margin:-.25em 0 .75em;border-width:1px 0 0}
#footnotes .footnote{padding:0 .375em 0 .225em;line-height:1.3334;font-size:.875em;margin-left:1.2em;margin-bottom:.2em}
#footnotes .footnote a:first-of-type{font-weight:bold;text-decoration:none;margin-left:-1.05em}
#footnotes .footnote:last-of-type{margin-bottom:0}
#content #footnotes{margin-top:-.625em;margin-bottom:0;padding:.75em 0}
div.unbreakable{page-break-inside:avoid}
.big{font-size:larger}
.small{font-size:smaller}
.underline{text-decoration:underline}
.overline{text-decoration:overline}
.line-through{text-decoration:line-through}
.aqua{color:#00bfbf}
.aqua-background{background:#00fafa}
.black{color:#000}
.black-background{background:#000}
.blue{color:#0000bf}
.blue-background{background:#0000fa}
.fuchsia{color:#bf00bf}
.fuchsia-background{background:#fa00fa}
.gray{color:#606060}
.gray-background{background:#7d7d7d}
.green{color:#006000}
.green-background{background:#007d00}
.lime{color:#00bf00}
.lime-background{background:#00fa00}
.maroon{color:#600000}
.maroon-background{background:#7d0000}
.navy{color:#000060}
.navy-background{background:#00007d}
.olive{color:#606000}
.olive-background{background:#7d7d00}
.purple{color:#600060}
.purple-background{background:#7d007d}
.red{color:#bf0000}
.red-background{background:#fa0000}
.silver{color:#909090}
.silver-background{background:#bcbcbc}
.teal{color:#006060}
.teal-background{background:#007d7d}
.white{color:#bfbfbf}
.white-background{background:#fafafa}
.yellow{color:#bfbf00}
.yellow-background{background:#fafa00}
span.icon>.fa{cursor:default}
a span.icon>.fa{cursor:inherit}
.admonitionblock td.icon [class^="fa icon-"]{font-size:2.5em;text-shadow:1px 1px 2px rgba(0,0,0,.5);cursor:default}
.admonitionblock td.icon .icon-note::before{content:"\f05a";color:#19407c}
.admonitionblock td.icon .icon-tip::before{content:"\f0eb";text-shadow:1px 1px 2px rgba(155,155,0,.8);color:#111}
.admonitionblock td.icon .icon-warning::before{content:"\f071";color:#bf6900}
.admonitionblock td.icon .icon-caution::before{content:"\f06d";color:#bf3400}
.admonitionblock td.icon .icon-important::before{content:"\f06a";color:#bf0000}
.conum[data-value]{display:inline-block;color:#fff!important;background:rgba(0,0,0,.8);border-radius:50%;text-align:center;font-size:.75em;width:1.67em;height:1.67em;line-height:1.67em;font-family:"Open Sans","DejaVu Sans",sans-serif;font-style:normal;font-weight:bold}
.conum[data-value] *{color:#fff!important}
.conum[data-value]+b{display:none}
.conum[data-value]::after{content:attr(data-value)}
pre .conum[data-value]{position:relative;top:-.125em}
b.conum *{color:inherit!important}
.conum:not([data-value]):empty{display:none}
dt,th.tableblock,td.content,div.footnote{text-rendering:optimizeLegibility}
h1,h2,p,td.content,span.alt,summary{letter-spacing:-.01em}
p strong,td.content strong,div.footnote strong{letter-spacing:-.005em}
p,blockquote,dt,td.content,td.hdlist1,span.alt,summary{font-size:1.0625rem}
p{margin-bottom:1.25rem}
.sidebarblock p,.sidebarblock dt,.sidebarblock td.content,p.tableblock{font-size:1em}
.exampleblock>.content{background:#fffef7;border-color:#e0e0dc;box-shadow:0 1px 4px #e0e0dc}
.print-only{display:none!important}
@page{margin:1.25cm .75cm}
@media print{*{box-shadow:none!important;text-shadow:none!important}
html{font-size:80%}
a{color:inherit!important;text-decoration:underline!important}
a.bare,a[href^="#"],a[href^="mailto:"]{text-decoration:none!important}
a[href^="http:"]:not(.bare)::after,a[href^="https:"]:not(.bare)::after{content:"(" attr(href) ")";display:inline-block;font-size:.875em;padding-left:.25em}
abbr[title]{border-bottom:1px dotted}
abbr[title]::after{content:" (" attr(title) ")"}
pre,blockquote,tr,img,object,svg{page-break-inside:avoid}
thead{display:table-header-group}
svg{max-width:100%}
p,blockquote,dt,td.content{font-size:1em;orphans:3;widows:3}
h2,h3,#toctitle,.sidebarblock>.content>.title{page-break-after:avoid}
#header,#content,#footnotes,#footer{max-width:none}
#toc,.sidebarblock,.exampleblock>.content{background:none!important}
#toc{border-bottom:1px solid #dddddf!important;padding-bottom:0!important}
body.book #header{text-align:center}
body.book #header>h1:first-child{border:0!important;margin:2.5em 0 1em}
body.book #header .details{border:0!important;display:block;padding:0!important}
body.book #header .details span:first-child{margin-left:0!important}
body.book #header .details br{display:block}
body.book #header .details br+span::before{content:none!important}
body.book #toc{border:0!important;text-align:left!important;padding:0!important;margin:0!important}
body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-break-before:always}
.listingblock code[data-lang]::before{display:block}
#footer{padding:0 .9375em}
.hide-on-print{display:none!important}
.print-only{display:block!important}
.hide-for-print{display:none!important}
.show-for-print{display:inherit!important}}
@media amzn-kf8,print{#header>h1:first-child{margin-top:1.25rem}
.sect1{padding:0!important}
.sect1+.sect1{border:0}
#footer{background:none}
#footer-text{color:rgba(0,0,0,.6);font-size:.9em}}
@media amzn-kf8{#header,#content,#footnotes,#footer{padding:0}}
</style>
</head>
<body class="article">
<div id="header">
</div>
<div id="content">
<div class="sect1">
<h2 id="tx_fees">Transaction Fees</h2>
<div class="sectionbody">
<p class="fix_tracking">
The digital signature we saw Alice create in <a data-type="xref" href="#c_signatures">#c_signatures</a> only
proves that she knows her private key and that she committed to a
transaction that pays Bob. She can create another signature that
instead commits to a transaction paying Carol—a transaction that spends
the same output (bitcoins) that she used to pay Bob. Those two
transactions are now <em>conflicting transactions</em> because only one
transaction spending a particular output can be included in the valid
blockchain with the most proof of work—the blockchain that full nodes
use to determine which keys control which bitcoins.
</p>
<div class="paragraph">
<p>To protect himself against conflicting transactions, it would be wise
for Bob to wait until the transaction from Alice is included in the
blockchain to a sufficient depth before he considers the money he
received as his to spend (see <a href="#confirmations">[confirmations]</a>).
For Alice’s transaction to be included in the
blockchain, it must be included in a <em>block</em> of transactions. There are
a limited number of blocks produced in a given amount of time, and each
block only has a limited amount of space. Only the miner who creates
that block gets to choose which transactions to include. Miners may
select transactions by any criteria they want, including refusing to
include any transactions at all.</p>
</div>
<div data-type="note">
<p class="fix_tracking"> When we say "transactions" in this chapter, we refer to every
transaction in a block except for the first transaction. The first
transaction in a block is a <em>coinbase transaction</em>, described in
<a data-type="xref" href="#coinbase_transactions">#coinbase_transactions</a>, which allows the miner of the block to
collect their reward for producing the block. Unlike other
transactions, a coinbase transaction doesn't spend the output of a
previous transaction and is also an exception to several other rules
that apply to other transactions. Coinbase transactions don't pay
transaction fees, don't need to be fee bumped, aren't subject to
transaction pinning, and are largely uninteresting to the following
discussion about fees—so we're going to ignore them in this chapter.
</p>
</div>
<div class="paragraph">
<p>The criterion that almost all miners use to select which transactions to
include in their blocks is to maximize their revenue. Bitcoin was
specifically designed to accommodate this by providing a mechanism that
allows a transaction to give money to the miner who includes that
transaction in a block. We call that mechanism <em>transaction fees</em>,
although it’s not a fee in the usual sense of that word. It’s not an
amount set by the protocol or by any particular miner—​it’s much more
like a bid in an auction. The good being purchased is the portion of
limited space in a block that a transaction will consume. Miners choose
the set of transactions whose bids will allow them to earn the greatest
revenue.</p>
</div>
<div class="paragraph">
<p>In this chapter, we’ll explore various aspects of those
bids—​transaction fees—​and how they influence the creation and
management of Bitcoin transactions.</p>
</div>
<div class="sect2">
<h3 id="_who_pays_the_transaction_fee">Who Pays the Transaction Fee?</h3>
<div class="paragraph">
<p>Most payment systems involve some sort of fee for transacting, but
often this fee is hidden from typical buyers. For example, a merchant
may advertise the same item for the same price whether you pay with cash
or a credit card even though their payment processor may charge them
a higher fee for credit transactions than their bank charges them for
cash deposits.</p>
</div>
<div class="paragraph">
<p>In Bitcoin, every spend of bitcoins must be authenticated (typically
with a signature), so it’s not possible for a transaction to pay a fee
without the permission of the spender. It is possible for the receiver
of a transaction to pay a fee in a different transaction—​and we’ll see
that in use later—​but if we want a single transaction to pay its own
fee, that fee needs to be something agreed upon by the spender. It
can’t be hidden.</p>
</div>
<div class="paragraph">
<p>Bitcoin transactions are designed so that it doesn’t take any extra
space in a transaction for a spender to commit to the fee it pays. That
means that, even though it’s possible to pay the fee in a different
transaction, it’s most efficient (and thus cheapest) to pay the fee in a
single transaction.</p>
</div>
<div class="paragraph">
<p>In Bitcoin,
the fee is a bid and the amount paid contributes to determining how long
it will take the transaction to confirm. Both spenders and receivers of
a payment typically have an interest in having it confirming quickly, so
normally allowing only spenders to choose fees can sometimes be a
problem; we’ll look at a solution to that problem in <a href="#cpfp">Child Pays for Parent (CPFP) Fee Bumping</a>. However,
in many common payment flows, the parties with the highest desire to see a
transaction confirm quickly—​that is, the parties who would be the most
willing to pay higher fees—​are the spenders.</p>
</div>
<div class="paragraph">
<p>For those reasons, both technical and practical, it is customary in
Bitcoin for spenders to pay transaction fees. There are exceptions,
such as for merchants that accept unconfirmed transactions and in
protocols that don’t immediately broadcast <span class="keep-together">transactions</span> after they are
signed (preventing the spender from being able to choose an appropriate
fee for the current market). We’ll explore those exceptions later.</p>
</div>
</div>
<div class="sect2">
<h3 id="_fees_and_fee_rates">Fees and Fee Rates</h3>
<div class="paragraph">
<p>Each transaction only pays a single fee—​it doesn’t matter how large the
transaction is. However, the larger transactions become, the fewer of
them a miner will be able to fit in a block. For that reason, miners
evaluate transactions the same way you might comparison shop between
several equivalent items at the market: they divide the price by the
quantity.</p>
</div>
<div class="paragraph">
<p>Whereas you might divide the cost of several different bags of rice by
each bag’s weight to find the lowest price per weight (best deal), miners
divide the fee of a transaction by its size (also called its weight) to
find the highest fee per weight (most revenue). In Bitcoin, we use the
term <em>fee rate</em> for a transaction’s size divided by weight. Due to
changes in Bitcoin over the years, fee rate can be expressed in
different units:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>BTC/Bytes (a legacy unit rarely used anymore)</p>
</li>
<li>
<p>BTC/Kilobytes (a legacy unit rarely used anymore)</p>
</li>
<li>
<p>BTC/Vbytes (rarely used)</p>
</li>
<li>
<p>BTC/Kilo-vbyte (used mainly in Bitcoin Core)</p>
</li>
<li>
<p>Satoshi/Vbyte (most commonly used today)</p>
</li>
<li>
<p>Satoshi/Weight (also commonly used today)</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>We recommend either the sat/vbyte or sat/weight units for displaying
fee rates.</p>
</div>
<div class="admonitionblock warning">
<table>
<tr>
<td class="icon">
<div class="title">Warning</div>
</td>
<td class="content">
<div class="paragraph">
<p>Be careful accepting input for fee rates. If a user copies and pastes a
fee rate printed in one denominator into a field using a different
denominator, they could overpay fees by 1,000 times. If they instead
switch the numerator, they could theoretically overpay by 100,000,000
times. Wallets should make it hard for the user to pay an excessive
fee rate and may want to prompt the user to confirm any fee rate that was
not generated by the wallet itself using a trusted data source.</p>
</div>
<div class="paragraph">
<p>An excessive fee, also called an <em>absurd fee</em>, is any fee rate that’s
significantly higher than the amount that fee rate estimators currently
expect is necessary to get a transaction confirmed in the next block.
Note that wallets should not entirely prevent users from choosing an
excessive fee rate—​they should only make using such a fee rate hard to do
by accident. There are legitimate reasons for users to overpay fees on
rare occasions.</p>
</div>
</td>
</tr>
</table>
</div>
</div>
<div class="sect2">
<h3 id="_estimating_appropriate_fee_rates">Estimating Appropriate Fee Rates</h3>
<div class="paragraph">
<p>We’ve established that you can pay a lower fee rate if you’re willing to
wait longer for your transaction to be confirmed, with the exception
that paying too low of a fee rate could result in your transaction never
confirming. Because fee rates are bids in an open auction for block
space, it’s not possible to perfectly predict what fee rate you need to
pay to get your transaction confirmed by a certain time. However, we
can generate a rough estimate based on what fee rates other transactions
have paid in the recent past.</p>
</div>
<div class="paragraph">
<p>A full node can record three pieces of information about each
transactions it sees: the time (block height) when it first received
that transaction, the block height when that transaction was confirmed,
and the fee rate paid by that transaction. By grouping together
transactions that arrived at similar heights, were confirmed at similar
heights, and which paid similar fees, we can calculate how many blocks it
took to confirm transactions paying a certain fee rate. We can then
assume that a transaction paying a similar fee rate now will take a
similar number of blocks to confirm. Bitcoin Core includes a fee rate
estimator that uses these principles, which can be called using the
<code>estimatesmartfee</code> RPC with a parameter specifying how many blocks
you’re willing to wait before the transaction is highly likely to
confirm (for example, 144 blocks is about 1 day):</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ bitcoin-cli -named estimatesmartfee conf_target=144
{
"feerate": 0.00006570,
"blocks": 144
}</pre>
</div>
</div>
<div class="paragraph">
<p>Many web-based services also provide fee estimation as an API. For a
current list, see <a href="https://oreil.ly/TB6IN" class="bare">https://oreil.ly/TB6IN</a>.</p>
</div>
<div class="paragraph">
<p>As mentioned, fee rate estimation can never be perfect. One common
problem is that the fundamental demand might change, adjusting the
equilibrium and either increasing prices (fees) to new heights or
decreasing them toward the minimum.
If fee rates go down, then a transaction
that previously paid a normal fee rate might now be paying a high fee
rate and it will be confirmed earlier than expected. There’s no way to
lower the fee rate on a transaction you’ve already sent, so you’re stuck
paying a higher fee rate. But, when fee rates go up, there’s a need for
methods to be able to increase the fee rates on those transactions,
which is called <em>fee bumping</em>. There are two commonly used types of fee
bumping in Bitcoin, replace by fee (RBF) and child pays for parent
(CPFP).</p>
</div>
</div>
<div class="sect2">
<h3 id="rbf">Replace By Fee (RBF) Fee Bumping</h3>
<div class="paragraph">
<p>To increase the fee of a transaction using RBF fee bumping, you create
a conflicting version of the transaction that pays a higher fee. Two
or more transactions are considered to be <em>conflicting transactions</em> if
only one of them can be included in a valid blockchain, forcing a miner
to choose only one of them. Conflicts occur when two or more transactions
each try to spend one of the same UTXOs, i.e., they each include an input
that has the same outpoint (reference to the output of a previous
transaction).</p>
</div>
<div class="paragraph">
<p>To prevent someone from consuming large amounts of bandwidth by creating
an unlimited number of conflicting transactions and sending them through
the network of relaying full nodes, Bitcoin Core and other full nodes
that support transaction replacement require each replacement
transaction to pay a higher fee rate than the transaction being
replaced. Bitcoin Core also currently requires the replacement
transaction to pay a higher total fee than the original transaction, but
this requirement has undesired side effects and developers have been
looking for ways to remove it at the time of writing.</p>
</div>
<div class="paragraph">
<p>Bitcoin Core currently supports two variations of RBF:</p>
</div>
<div class="dlist">
<dl>
<dt class="hdlist1">Opt-in RBF</dt>
<dd>
<p>An unconfirmed transaction can signal to miners and full nodes that
the creator of the transaction wants to allow it to be replaced by a
higher fee rate version. This signal and the rules for using it
are specified in BIP125. As of this writing, this has been enabled by
default in Bitcoin Core for several years.</p>
</dd>
<dt class="hdlist1">Full RBF</dt>
<dd>
<p>Any unconfirmed transaction can be replaced by a higher fee rate
version. As of this writing, this can be optionally enabled in
Bitcoin Core (but it is disabled by default).</p>
</dd>
</dl>
</div>
<div class="sidebarblock">
<div class="content">
<div class="title">Why Are There Two Variants of RBF?</div>
<div class="paragraph">
<p>The reason for the two different versions of RBF is that full RBF has
been controversial. Early versions of Bitcoin allowed transaction
replacement, but this behavior was disabled for several releases. During
that time, a miner or full node using the software now called Bitcoin
Core would not replace the first version of an unconfirmed transaction
they received with any different version. Some merchants came to expect
this behavior: they assumed that any valid unconfirmed transaction that
paid an appropriate fee rate would eventually become a confirmed
transaction, so they provided their goods or services shortly after
receiving such an unconfirmed transaction.</p>
</div>
<div class="paragraph">
<p>However, there’s no way for the Bitcoin protocol to guarantee that any
unconfirmed transaction will eventually be confirmed. As mentioned
earlier in this chapter, every miner gets to choose for themselves which
transactions they will try to confirm—​including which versions of those
transactions. Bitcoin Core is open source software, so anyone with a
copy of its source code can add (or remove) transaction replacement.
Even if Bitcoin Core wasn’t open source, Bitcoin is an open protocol
that can be reimplemented from scratch by a sufficiently competent
programmer, allowing the reimplementor to include or not include
transaction replacement.</p>
</div>
<div class="paragraph">
<p>Transaction replacement breaks the assumption of some merchants that
every reasonable unconfirmed transaction will eventually be confirmed.
An alternative version of a transaction can pay the same outputs as the
original, but it isn’t required to pay any of those outputs. If the
first version of an unconfirmed transaction pays a merchant, the second
version might not pay them. If the merchant provided goods or services
based on the first version, but the second version gets confirmed, then
the merchant will not receive payment for its costs.</p>
</div>
<div class="paragraph">
<p>Some merchants, and people supporting them, requested that transaction
replacement not be reenabled in Bitcoin Core. Other people pointed out
that transaction replacement provides benefits, including the ability to
fee bump transactions that initially paid too low of a fee rate.</p>
</div>
<div class="paragraph">
<p>Eventually, developers working on Bitcoin Core implemented a compromise:
instead of allowing every unconfirmed transaction to be replaced (full
RBF), they only programmed Bitcoin Core to allow replacement of
transactions that signaled they wanted to allow replacement (opt-in RBF).
Merchants can check the transactions they receive for the opt-in
signal and treat those transactions differently than those without the
signal.</p>
</div>
<div class="paragraph">
<p>This doesn’t change the fundamental concern: anyone can still alter
their copy of Bitcoin Core, or create a reimplementation, to allow full
RBF—​and some developers even did this, but seemingly few people used
their software.</p>
</div>
<div class="paragraph">
<p>After several years, developers working on Bitcoin Core changed the
compromise slightly. In addition to keeping opt-in RBF by default, they
added an option that allows users to enable full RBF. If enough mining
hash rate and relaying full nodes enable this option, it will be
possible for any unconfirmed transaction to eventually be replaced by a
version paying a higher fee rate. As of this writing, it’s not clear
whether or not that has happened yet.</p>
</div>
</div>
</div>
<div class="paragraph">
<p>As a user, if you plan to use RBF fee bumping, you will first need to
choose a wallet that supports it, such as one of the wallets listed as
having "Sending support" on
<a href="https://oreil.ly/IhMzx" class="bare">https://oreil.ly/IhMzx</a>.</p>
</div>
<div class="paragraph">
<p>As a developer, if you plan to implement RBF fee bumping, you will first
need to decide whether to perform opt-in RBF or full RBF. At the time
of writing, opt-in RBF is the only method that’s sure to work. Even if
full RBF becomes reliable, there will likely be several years where
replacements of opt-in transactions get confirmed slightly faster than
full-RBF replacements. If you choose opt-in RBF, your wallet will need
to implement the signaling specified in BIP125, which is a simple
modification to any one of the sequence fields in a transaction (see
<a href="#sequence">[sequence]</a>). If you choose full RBF, you don’t need to include any
signaling in your transactions. Everything else related to RBF is the
same for both approaches.</p>
</div>
<div class="paragraph">
<p>When you need to fee bump a transaction, you will simply create a new
transaction that spends at least one of the same UTXOs as the original
transaction you want to replace. You will likely want to keep the
same outputs in the transaction that pay the receiver (or receivers).
You may pay the increased fee by reducing the value of your change
output or by adding additional inputs to the transaction. Developers
should provide users with a fee-bumping interface that does all of this
work for them and simply asks them (or suggests to them) how much the
fee rate should be increased.</p>
</div>
<div class="admonitionblock warning">
<table>
<tr>
<td class="icon">
<div class="title">Warning</div>
</td>
<td class="content">
<div class="paragraph">
<p>Be very careful when creating more than one replacement of the same
transaction. You must ensure than all versions of the transactions
conflict with each other. If they aren’t all conflicts, it may be
possible for multiple separate transactions to confirm, leading you to
overpay the receivers. For example:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Transaction version 0 includes input <em>A</em>.</p>
</li>
<li>
<p>Transaction version 1 includes inputs <em>A</em> and <em>B</em> (e.g., you had to add
input <em>B</em> to pay the extra fees)</p>
</li>
<li>
<p>Transaction version 2 includes inputs <em>B</em> and <em>C</em> (e.g., you had to add input
<em>C</em> to pay the extra fees but <em>C</em> was large enough that you no longer
need input <em>A</em>).</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>In this scenario, any miner who saved version 0 of the transaction
will be able to confirm both it and version 2 of the transaction. If
both versions pay the same receivers, they’ll be paid twice (and the
miner will receive transaction fees from two separate transactions).</p>
</div>
<div class="paragraph">
<p>A simple method to avoid this problem is to ensure the replacement
transaction always includes all of the same inputs as the previous
version of the transaction.</p>
</div>
</td>
</tr>
</table>
</div>
<div class="paragraph">
<p>The advantage of RBF fee bumping over other types of fee bumping is that
it can be very efficient at using block space. Often, a replacement
transaction is the same size as the transaction it replaces. Even when
it’s larger, it’s often the same size as the transaction the user would
have created if they had paid the increased fee rate in the first place.</p>
</div>
<div class="paragraph">
<p>The fundamental disadvantage of RBF fee bumping is that it can normally
only be performed by the creator of the transaction—​the person or
people who were required to provide signatures or other authentication
data for the transaction. An exception to this is transactions that
were designed to allow additional inputs to be added by using sighash
flags (see <a href="#sighash_types">[sighash_types]</a>), but that presents its own challenges. In
general, if you’re the receiver of an unconfirmed transaction and you
want to make it confirm faster (or at all), you can’t use an RBF fee
bump; you need some other method.</p>
</div>
<div class="paragraph">
<p>There are additional problems with RBF that we’ll explore in <a href="#transaction_pinning">Transaction Pinning</a>.</p>
</div>
</div>
<div class="sect2">
<h3 id="cpfp">Child Pays for Parent (CPFP) Fee Bumping</h3>
<div class="paragraph">
<p>Anyone who receives the output of an unconfirmed transaction can
incentivize miners to confirm that transaction by spending that output.
The transaction you want to get confirmed is called the <em>parent
transaction</em>. A transaction that spends an output of the parent
transaction is called a <em>child transaction</em>.</p>
</div>
<div class="paragraph">
<p>As we learned in <a href="#outpoints">[outpoints]</a>, every input in a confirmed transaction
must reference the unspent output of a transaction that appears earlier
in the blockchain (whether earlier in the same block or in a previous
block). That means a miner who wants to confirm a child transaction
must also ensure that its parent transaction is confirmed. If the
parent transaction hasn’t been confirmed yet but the child transaction
pays a high enough fee, the miner can consider whether it would be
profitable to confirm both of them in the same block.</p>
</div>
<div class="paragraph">
<p>To evaluate the profitability of mining both a parent and child
transaction, the miner looks at them as a <em>package of transactions</em> with
an aggregate size and aggregate fees, from which the fees can be divided
by the size to calculate a <em>package fee rate</em>. The miner can then sort
all of the individual transactions and transaction packages they know
about by fee rate and include the highest-revenue ones in the block
they’re attempting to mine, up to the maximum size (weight) allowed to
be included in a block. To find even more packages that might be
profitable to mine, the miner can evaluate packages across multiple
generations (e.g., an unconfirmed parent transaction being combined with
both its child and grandchild). This is called <em>ancestor fee rate
mining</em>.</p>
</div>
<div class="paragraph">
<p>Bitcoin Core has implemented ancestor fee rate mining for many years,
and it’s believed that almost all miners use it at the time of writing.
That means it’s practical for wallets to use this feature to fee bump an
incoming transaction by using a child transaction to pay for its parent
(CPFP).</p>
</div>
<div class="paragraph">
<p>CPFP has several advantages over RBF. Anyone who receives an output
from a transaction can use CPFP—​that includes both the receivers of
payments and the spender (if the spender included a change output). It
also doesn’t require replacing the original transaction, which makes it
less disruptive to some merchants than RBF.</p>
</div>
<div class="paragraph">
<p>The primary disadvantage of CPFP compared to RBF is that CPFP typically
uses more block space. In RBF, a fee bump transaction is often the same
size as the transaction it replaces. In CPFP, a fee bump adds a whole
separate transaction. Using extra block space requires paying extra
fees beyond the cost of the fee bump.</p>
</div>
<div class="paragraph">
<p>There are several challenges with CPFP, some of which we’ll explore in
<a href="#transaction_pinning">Transaction Pinning</a>. One other problem that we
specifically need to mention is the minimum relay fee rate problem,
which is addressed by package relay.</p>
</div>
</div>
<div class="sect2">
<h3 id="_package_relay">Package Relay</h3>
<div class="paragraph">
<p>Early versions of Bitcoin Core didn’t place any limits on the number of
unconfirmed transactions they stored for later relay and mining in their
mempools (see <a href="#mempool">[mempool]</a>). Of course, computers have physical limits, whether
it’s the memory (RAM) or disk space—​it’s not possible for a full node
to store an unlimited number of unconfirmed transactions. Later
versions of Bitcoin Core limited the size of the mempool to hold about
one day’s worth of transactions, storing only the transactions or packages
with the highest fee rate.</p>
</div>
<div class="paragraph">
<p>That works extremely well for most things, but it creates a dependency
problem. In order to calculate the fee rate for a transaction package,
we need both the parent and descendant transactions—​but if the parent
transaction doesn’t pay a high enough fee rate, it won’t be kept in a
node’s mempool. If a node receives a child transaction without having
access to its parent, it can’t do anything with that transaction.</p>
</div>
<div class="paragraph">
<p>The solution to this problem is the ability to relay transactions as a
package, called <em>package relay</em>, allowing the receiving node to evaluate
the fee rate of the entire package before operating on any individual
transaction. As of this writing, developers working on Bitcoin Core
have made significant progress on implementing package relay, and a
limited early version of it may be available by the time this book is
published.</p>
</div>
<div class="paragraph">
<p>Package relay is especially important for protocols based on
time-sensitive presigned transactions, such as Lightning Network (LN). In
non-cooperative cases, some presigned transactions can’t be fee bumped
using RBF, forcing them to depend on CPFP. In those protocols, some
transactions may also be created long before they need to be broadcast,
making it effectively impossible to estimate an appropriate fee rate.
If a presigned transaction pays a fee rate below the amount necessary to
get into a node’s mempool, there’s no way to fee bump it with a child.
If that prevents the transaction from confirming in time, an honest user
might lose money. Package relay is the solution for this critical
problem.</p>
</div>
</div>
<div class="sect2">
<h3 id="transaction_pinning">Transaction Pinning</h3>
<p class="fix_tracking">
Although both RBF and CPFP fee bumping work in the basic cases we
described, there are rules related to both
methods that are designed to prevent denial-of-service attacks on miners
and relaying full nodes. An unfortunate side effect of those rules
is that they can sometimes prevent someone from being able to use fee
bumping. Making it impossible or difficult to fee bump a transaction is
called <em>transaction pinning</em>.</p>
<div class="paragraph">