summaryrefslogtreecommitdiff
path: root/66/a012191094e4deec3be879dc73e7e666f9abef
blob: 9207e14777cf2ed592b3764bf289c3555b5be1a6 (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
Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B16EE1159
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 27 Mar 2018 23:32:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f43.google.com (mail-it0-f43.google.com
	[209.85.214.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 50AAD5E1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 27 Mar 2018 23:32:02 +0000 (UTC)
Received: by mail-it0-f43.google.com with SMTP id z7-v6so17587894iti.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 27 Mar 2018 16:32:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:from:date:message-id:subject:to;
	bh=6xvv5asIox93sdNoB+J1bK+zhpUn263X/oPOerkXB5Y=;
	b=rVlq2EDppspnZfwZk2sza9rfTYk1zPQqtC6NMemPmaDiPZeEYFzP/He3vBHslIBwsS
	sqVozwuXyQ/mR83PZSQ8MZZD95vJkyJrQts+5XpRCGw90CxDUXkZgNLJ58ISzIMM7qZo
	6nap3EIDzN8MWA3l3Jd46pl82OwenxAyDogSnHzkinZBkAxEeuuq517C88mGSJA5pMT9
	nom/Or1aNq4DItnG7chM2j8MvByiIopNQGpTz4T1/Awcmt5k4I8lRo8PzXmxLwnVdPtf
	qmm7fcixGNvhMXkH5KngJuZGPB3rGFycq29V1Vs+uTMQR/7cJcZsR61+uvczqFSG4bI8
	Uc9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=6xvv5asIox93sdNoB+J1bK+zhpUn263X/oPOerkXB5Y=;
	b=Qjc+ravjdX+cfpVJAVulTeevn3SYpPh4tBCDfY61aWV5pyPq8vAMz9cHl4qa5+YEWN
	ZPmkWlzRBlwzy7U142qj2zko+SD2W3DIwhC9CzDVd3ynrLt9ZE4SeXoEbyCAsNP38EA/
	iD8j6XyGjHUxtZraszLEqdn0Qs5VocWVFChXEXkyo4zIxJANmSZimtF3UQwCGas6ijsP
	xRHOpp2tOsmSEZiPylnA9XTcBqdHUj6dYiuS/8TT2jnrsfqYHv1tvyxnhi4VlIvJvOQc
	0IOoat7dEG5IJDZZjvpWoFa1p8ppPKyBRXF7J896iinHXUUcGJuRnSh4t4xZogl/5ldz
	13hw==
X-Gm-Message-State: AElRT7E5LCLQxzza6OtVAd+irydh/XIMJNQub6n2HC/2zORsILJjaDJ7
	MUCHtwYhJ0pxMiAc98LqjoaXvFAno3nRM3ISK2C2OUko
X-Google-Smtp-Source: AIpwx490KgBDk9b9Ov1A0TIPKoaa7a/gJ0Q4TxmmOba6s0ozz33+Ka/Z7UrV2z4No0ZbLu//m3ySBxuamr1UPUML8pw=
X-Received: by 2002:a24:67d7:: with SMTP id
	u206-v6mr1290849itc.138.1522193520997; 
	Tue, 27 Mar 2018 16:32:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.52.80 with HTTP; Tue, 27 Mar 2018 16:31:58 -0700 (PDT)
From: Jim Posen <jim.posen@gmail.com>
Date: Tue, 27 Mar 2018 16:31:58 -0700
Message-ID: <CADZtCSg7+x-sg-ysgacXobRexOVwT+k9fr6a9S-6xU2w8f8m3A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000193c7705686d4c09"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 27 Mar 2018 23:33:58 +0000
Subject: [bitcoin-dev] Optimized Header Sync
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2018 23:32:04 -0000

--000000000000193c7705686d4c09
Content-Type: text/plain; charset="UTF-8"

Based on some ideas that were thrown around in this thread (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015385.html),
I have been working on a P2P extension that will allow faster header sync
mechanisms. The one-sentence summary is that by encoding headers more
efficiently (eg. omitting prev_hash) and downloading evenly spaced
checkpoints throughout history (say every 1,000th) from all peers first, we
could speed up header sync, which would be a huge improvement for light
clients. Here is a draft of the BIP:
https://github.com/jimpo/bips/blob/headers-sync/headersv2.mediawiki. The
full text is below as well.

I'd love to hear any feedback people have.

----------------------------------------------------------

== Abstract ==

This BIP describes a P2P network extension enabling faster, more
reliable methods for syncing the block header chain. New P2P messages
are proposed as more efficient replacements for
<code>getheaders</code> and <code>headers</code> during initial block
download. The proposed header download protocol reduces bandwidth
usage by ~40%-50% and supports downloading headers ranges from
multiple peers in parallel, which is not possible with the current
mechanism. This also enables sync strategies with better resistance to
denial-of-service attacks.

== Motivation ==

Since 2015, optimized Bitcoin clients fetch all block headers before
blocks themselves in order to avoid downloading ones that are not part
of the most work chain. The protocol currently in use for fetching
headers leaves room for further optimization, specifically by
compressing header data and downloading more headers
simulaneously<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015385.html</ref>.
Any savings here should have a large impact given that both full nodes
and light clients must sync the header chain as a first step, and that
the time to validate and index the headers is negligible compared to
the time spent downloading them from the network. Furthermore, some
current implementations of headers syncing rely on preconfigured
checkpoints to discourage attackers attempting to fill up a victim's
disk space with low-work headers. The proposed messages enable sync
strategies that are resilient against these types of attacks. The P2P
messages are designed to be flexible, supporting multiple header sync
strategies and leaving room for future innovations, while also
compact.

== Definitions ==

''double-SHA256'' is a hash algorithm defined by two invocations of
SHA-256: <code>double-SHA256(x) = SHA256(SHA256(x))</code>.

== Specification ==

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

=== New Structures ===

==== Compressed Headers ====

Bitcoin headers are serialized by default in 80 bytes as follows:

{| class="wikitable"
! Field Name
! Data Type
! Byte Size
! Description
|-
| version
| int32_t
| 4
| Block version information
|-
| prev_block
| uint256
| 32
| The hash of the previous block
|-
| merkle_root
| uint256
| 32
| The root hash of the transaction Merkle tree
|-
| timestamp
| uint32_t
| 4
| A Unix timestamp of the block creation time, as reported by the miner
|-
| bits
| uint32_t
| 4
| The calculated difficulty target for this block
|-
| nonce
| uint32_t
| 4
| A nonce that is set such that the header's hash matches the difficulty target
|}

When deserializing a correctly-formed sequence of block headers
encoded in this way, it can be noted that:

* The prev_block field should always match the double-SHA256 hash of
the previous header, making it redundant
* According to Bitcoin consensus rules, the bits field only changes
every 2016 blocks
* The version often matches that of a recent ancestor block
* The timestamp is often a small delta from the preceding header's timestamp

To take advantage of these possible savings, this document defines a
variable-sized ''compressed encoding'' of block headers that occur in
a range. Note that no savings are possible when serializing a single
header; it should only be used for vectors of sequential headers. The
full headers are reconstructed using data from previous headers in the
range. The serialization begins with an ''encoding indicator'', which
is a bitfield specifying how each field is serialized. The bits of the
indicator have the following semantics:

{| class="wikitable"
! Bit Index
! Reconstruction
! Description
|-
| 0
| <code>prev_block[i] = DSHA256(header[i-1])</code>
| The prev_block field is ommitted and assigned to the double-SHA256
hash of the previous uncompressed header.
|-
| 1
| <code>nbits[i] = nbits[i-1]</code>
| The nbits field is omitted and matches that of the previous header.
|-
| 2
| <code>timestamp[i] = timestamp[i-1] + value</code>
| The timestamp is replaced by a 2-byte signed short int, representing
an offset from the previous block's timestamp
|-
| 3
|
| Interpreted along with bits 4 & 5.
|-
| 4
|
| Interpreted along with bits 3 & 5.
|-
| 5
| <code>version[i] = version[i - ((bit[3] << 2) + (bit[4] << 1) +
bit[5])]</code>
| Bits 3, 4, and 5 are first interpreted as a 3-bit offset, with bit
index 3 as the most significant and bit index 5 as the least
significant. If the offset is non-zero, the version field is omitted
and assigned to the version of the block at the offset number of
blocks prior.
|-
| 6
|
| Reserved.
|-
| 7
|
| Reserved. May be used in a future encoding version to signal another
indicator byte.
|}

The compressed header format is versioned by a 256-bit unsigned
integer. This document defines version 0.

==== VarInt ====

''VarInt'' is a variable-length unsigned integer encoding that
supports a greater range of numbers than the standard ''CompactSize''.
This encoding was introduced at the database layer in Bitcoin
Core<ref>https://github.com/bitcoin/bitcoin/commit/4d6144f97faf9d2a6c89f41d7d2360f21f0b71e2</ref>
in 2012, but is new to the Bitcoin P2P layer.

This definition is per the code comments in Bitcoin Core written by
Pieter Wuille:

<pre>
Variable-length integers: bytes are a MSB base-128 encoding of the number.
The high bit in each byte signifies whether another digit follows. To make
the encoding is one-to-one, one is subtracted from all but the last digit.
Thus, the byte sequence a[] with length len, where all but the last byte
has bit 128 set, encodes the number:

  (a[len-1] & 0x7F) + sum(i=1..len-1, 128^i*((a[len-i-1] & 0x7F)+1))

Properties:
* Very small (0-127: 1 byte, 128-16511: 2 bytes, 16512-2113663: 3 bytes)
* Every integer has exactly one encoding
* Encoding does not depend on size of original integer type
* No redundancy: every (infinite) byte sequence corresponds to a list
  of encoded integers.

0:         [0x00]  256:        [0x81 0x00]
1:         [0x01]  16383:      [0xFE 0x7F]
127:       [0x7F]  16384:      [0xFF 0x00]
128:  [0x80 0x00]  16511: [0x80 0xFF 0x7F]
255:  [0x80 0x7F]  65535: [0x82 0xFD 0x7F]
2^32:           [0x8E 0xFE 0xFE 0xFF 0x00]
</pre>

==== Checkpoints ====

A ''checkpoint'' is defined for a block as a tuple of its hash and the
chain work:

{| class="wikitable"
! Field Name
! Data Type
! Byte Size
! Description
|-
| block_hash
| uint256
| 32
| The hash of the block
|-
| chain_work
| VarInt
| Variable(1-20)
| A delta between the total work in the chain at the checkpoint block
and a previous checkpoint, determined by context
|}

=== Service Bit ===

This BIP allocates a new service bit:

{| class="wikitable"
|-
| NODE_HEADERS_V2
| <code>1 << ?</code>
| If enabled, the node MUST respond to <code>getcheckpts</code> and
<code>getheaders2</code> queries
|}

=== New Messages ===

==== getcheckpts ====
<code>getcheckpts</code> is used to request block headers at a
specified distance from each other which serve as checkpoints during
parallel header download. The message contains the following fields:

{| class="wikitable"
! Field Name
! Data Type
! Byte Size
! Description
|-
| block_locator
| uint256[]
| Variable
| A vector of block hashes in descending order by height used to
identify the header chain of the requesting node
|-
| interval
| uint32_t
| 4
| The distance in block height between requested block hashes
|}

# Nodes SHOULD NOT send <code>getcheckpts</code> unless the peer has
set the <code>NODE_HEADERS_V2</code> service bit
# The hashes in <code>block_locator</code> MUST be in descending order
by block height
# The block locator SHOULD be generated as it is in
<code>getheaders</code> requests
# The receiving node MUST respond to valid requests with a
<code>checkpts</code> response where the interval is the same as in
the request and the first checkpoint hash matches the first common
block hash in the block locator

==== checkpts ====
<code>checkpts</code> is sent in response to <code>getcheckpts</code>,
listing block hashes at the specified interval. The message contains
the following fields:

{| class="wikitable"
! Field Name
! Data Type
! Byte Size
! Description
|-
| start_height
| uint32_t
| 4
| The height of the first block in the active chain matching the
request's block locator
|-
| end_height
| uint32_t
| 4
| The height of the last block in the active chain
|-
| start_checkpoint
| Checkpoint
| 48
| The checkpoint structure for the block in the active chain at height
start_height
|-
| end_checkpoint
| Checkpoint
| 48
| The checkpoint structure for the block in the active chain at height
end_height
|-
| interval
| uint32_t
| 4
| The distance in block height between checkpoints
|-
| checkpoints_length
| CompactSize
| Variable(1-5)
| The number of checkpoints to follow
|-
| checkpoints
| Checkpoint[]
| checkoints_length * Variable(33-52)
| The checkpoints as specified below
|}

# The interval SHOULD match the field in the <code>getcheckpts</code> request
# The start_checkpoint SHOULD correspond to the first block hash in
the locator from the <code>getcheckpts</code> request that is part of
the active chain
# The end_checkpoint SHOULD correspond to the tip of the node's active chain
# The start_height MOST be set to the block height of the start_checkpoint
# The end_height MOST be set to the block height of the end_checkpoint
# If the interval is zero, the checkpoints vector MUST be empty
# If the interval is non-zero, checkpoints MUST correspond to blocks
on the active chain between the start_checkpoint and the
end_checkpoint (exclusive), where the difference in block height
between each entry and the previous one is equal to the interval
# The checkpoints_length MUST be less than or equal to 2,000
# The node SHOULD include as many checkpoints on its active chain as
are available, up to the limit of 2,000
# The chain_work field in the first checkpoint MUST be the total work
in the chain ending at that block
# The chain_work field in each subsequent checkpoint MUST be the
difference in chain work between that block and the previous
checkpoint
# The chain_work field in each checkpoint MUST be a properly-encoded
VarInt, not exceeding 20 bytes

==== getheaders2 ====
<code>getheaders2</code> is used to request compressed headers for a
range of blocks. The message contains the following fields:

{| class="wikitable"
! Field Name
! Data Type
! Byte Size
! Description
|-
| max_version
| uint8_t
| 1
| The maximum supported encoding version of the headers
|-
| flags
| uint8_t
| 1
| A bitfield of message encoding flags
|-
| start_height
| uint32_t
| 4
| The height of the first block header in the requested range
|-
| end_hash
| uint256
| 32
| The hash of the last block header in the requested range
|}

# Nodes SHOULD NOT send <code>getheaders2</code> unless the peer has
set the <code>NODE_HEADERS_V2</code> service bit
# The height of the block with hash end_hash MUST be greater than or
equal to start_height, and the difference MUST be strictly less than
3,000
# The end_hash SHOULD match one in a previously received
<code>checkpts</code> message, otherwise the receiving node MAY
disconnect
# The 0th bit (least significant order) of the flags field MAY be set
to request the coinbase transaction and merkle branch for the block at
height start_height

==== headers2 ====
<code>headers2</code> is sent in response to <code>getheaders2</code>,
listing the compressed headers in the requested range. The message
contains the following fields:

{| class="wikitable"
! Field Name
! Data Type
! Byte Size
! Description
|-
| version
| uint8_t
| 1
| The encoding version of the headers
|-
| flags
| uint8_t
| 1
| A bitfield of message encoding flags
|-
| start_height
| uint32_t
| 4
| The height of the first block header returned
|-
| headers_length
| CompactSize
| 1-3
| The number of block headers to follow
|-
| headers
| CompressedHeader[]
| Variable
| The compressed block headers
|-
| start_block_coinbase_tx
| CTransaction
| Variable
| The coinbase transaction in the block at start_height
|-
| start_block_coinbase_branch
| uint256[]
| Variable
| A merkle branch linking the coinbase transaction in the block at
start_height to its header
|}

# The version MUST be less than or equal to the max_version field of
the <code>getheaders2</code> request
# Any bits set in the flags field of the <code>getheaders2</code>
request MAY be set in the response field
# Any bits not set in the flags field of the <code>getheaders2</code>
request MUST NOT be set in the response field
# The first header MUST be encoded with a 0-byte indicator (ie. the
header is uncompressed)
# start_height MUST be set to the block height of the first header
# The hash of the last block SHOULD equal the end_hash of the
<code>getheaders2</code> request, ''even if the block is no longer
part of the active chain''
# The length of the headers vector MUST be less than or equal to 3,000
# The headers MUST be sequential in order of height, with each header
a successor of the previous one
# Each header SHOULD be optimally compressed
# The start_block_coinbase_tx should be the serialized coinbase
transaction in the block corresponding to the first header
# The start_block_coinbase_branch should be a vector of
right-hand-side hashes in the merkle branch linking the coinbase
transaction to the first header, in order from bottom of the tree to
top
# If the 0th bit (least significant order) of the flags field is
unset, the start_block_coinbase_tx and start_block_coinbase_branch
fields MUST be omitted

=== Sync Strategies ===

The general header sync protocol for clients now is to first request
checkpoints from all peers with <code>getcheckpts</code>, then decide
which peers to fetch ranges of headers from and download them with
<code>getheaders2</code>.

==== Forward Sequential Syncing ====

Similar to the current sync protocol, a client may choose one peer to
download headers from, then fetch them in forward sequential order.
Once this peer is out of headers, the client performs the same routine
with any peers offering more headers.

With this strategy, the client is able to fully validate the block
headers in order and abort if the peer serves an invalid one. On the
other hand, the peer may be able to serve a longer, lower-work chain
than the global active chain, wasting the client's time, memory, and
storage space.

==== Parallel Header Download ====

In order to increase the throughput of header downloads, a node may
download multiple header ranges in parallel from all peers serving the
same checkpoints, then validate them in sequential order.

==== Random Sampling Proof-of-Work  ====

Similar the FlyClient<ref>https://www.youtube.com/watch?time_continue=8400&v=BPNs9EVxWrA</ref>
header download protocol, clients can select the peer claiming the
greatest total work chain and use random sampling to efficiently
determine if the peer is likely to be reporting its chain work
honestly.

The client treats the checkpoint message as a commitment to chain work
of intermediate ranges of headers, the client then randomly samples
ranges of headers weighted by total work to determine whether the
total chain work is valid before downloading all headers. To defend
against malicious peers attempting to reuse earlier headers later in
the chain to fake greater total work, the client should check the
block height in the coinbase transaction for all headers after the BIP
34 activation height. If the peer is found to be dishonest, they can
be banned before the client downloads too many headers, otherwise the
client chooses this as the primary sync peer for forward sequential
sync or parallel download.

== Rationale ==

* '''Why include the coinbase transaction in the headers messages?'''
The primary reason is that after BIP
34<ref>https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki</ref>
activation at block height 227,835, coinbase transactions constitute
cryptographic commitments to a block's height in the chain, which
mitigates certain attacks during header sync. Furthermore, the
<code>getheaders2</code> message can be used as a simple way of
requesting a coinbase transaction for a single header, which may be
independently useful.

* '''Why not omit nBits entirely?''' The compression is designed to
permit full decompression of all headers in a <code>headers2</code>
message ''without'' requiring any other chain context. This is
desirable so that proofs of work may be validated for arbitrary header
ranges. While nBits can be computed knowing previous headers, this
requires block headers that may not be sent in the same message.

== Compatibility ==

This is backwards compatible, as it defines new P2P messages which are
available if a service bit is signaled. There are no changes to
consensus rules.

== Acknowledgements ==

Thanks to Gregory Maxwell for suggestions on the compressed header
encoding and the DOS-resistant sync strategies. Thanks to Suhas
Daftuar for helpful discussions.

Credit for the VarInt encoding goes to Pieter Wuille.

--000000000000193c7705686d4c09
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Based on some ideas that were thrown around in this thread=
 (<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-D=
ecember/015385.html">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2017-December/015385.html</a>), I have been working on a P2P extension th=
at will allow faster header sync mechanisms. The one-sentence summary is th=
at by encoding headers more efficiently (eg. omitting prev_hash) and downlo=
ading evenly spaced checkpoints throughout history (say every 1,000th) from=
 all peers first, we could speed up header sync, which would be a huge impr=
ovement for light clients.=C2=A0Here is a draft of the BIP:=C2=A0<a href=3D=
"https://github.com/jimpo/bips/blob/headers-sync/headersv2.mediawiki">https=
://github.com/jimpo/bips/blob/headers-sync/headersv2.mediawiki</a>. The ful=
l text is below as well.<div><div><br></div><div>I&#39;d love to hear any f=
eedback people have.</div></div><div><br></div><div>-----------------------=
-----------------------------------</div><div><br></div><div><pre style=3D"=
color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-varia=
nt-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initi=
al;text-decoration-color:initial;word-wrap:break-word;white-space:pre-wrap"=
>=3D=3D Abstract =3D=3D

This BIP describes a P2P network extension enabling faster, more reliable m=
ethods for syncing the block header chain. New P2P messages are proposed as=
 more efficient replacements for &lt;code&gt;getheaders&lt;/code&gt; and &l=
t;code&gt;headers&lt;/code&gt; during initial block download. The proposed =
header download protocol reduces bandwidth usage by ~40%-50% and supports d=
ownloading headers ranges from multiple peers in parallel, which is not pos=
sible with the current mechanism. This also enables sync strategies with be=
tter resistance to denial-of-service attacks.

=3D=3D Motivation =3D=3D

Since 2015, optimized Bitcoin clients fetch all block headers before blocks=
 themselves in order to avoid downloading ones that are not part of the mos=
t work chain. The protocol currently in use for fetching headers leaves roo=
m for further optimization, specifically by compressing header data and dow=
nloading more headers simulaneously&lt;ref&gt;<a href=3D"https://lists.linu=
xfoundation.org/pipermail/bitcoin-dev/2017-December/015385.html">https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015385.html</a>=
&lt;/ref&gt;. Any savings here should have a large impact given that both f=
ull nodes and light clients must sync the header chain as a first step, and=
 that the time to validate and index the headers is negligible compared to =
the time spent downloading them from the network. Furthermore, some current=
 implementations of headers syncing rely on preconfigured checkpoints to di=
scourage attackers attempting to fill up a victim&#39;s disk space with low=
-work headers. The proposed messages enable sync strategies that are resili=
ent against these types of attacks. The P2P messages are designed to be fle=
xible, supporting multiple header sync strategies and leaving room for futu=
re innovations, while also compact.

=3D=3D Definitions =3D=3D

&#39;&#39;double-SHA256&#39;&#39; is a hash algorithm defined by two invoca=
tions of SHA-256: &lt;code&gt;double-SHA256(x) =3D SHA256(SHA256(x))&lt;/co=
de&gt;.

=3D=3D Specification =3D=3D

The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;,=
 &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD=
 NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&qu=
ot; in this document are to be interpreted as described in RFC 2119.

=3D=3D=3D New Structures =3D=3D=3D

=3D=3D=3D=3D Compressed Headers =3D=3D=3D=3D

Bitcoin headers are serialized by default in 80 bytes as follows:

{| class=3D&quot;wikitable&quot;
! Field Name
! Data Type
! Byte Size
! Description
|-
| version
| int32_t
| 4
| Block version information
|-
| prev_block
| uint256
| 32
| The hash of the previous block
|-
| merkle_root
| uint256
| 32
| The root hash of the transaction Merkle tree
|-
| timestamp
| uint32_t
| 4
| A Unix timestamp of the block creation time, as reported by the miner
|-
| bits
| uint32_t
| 4
| The calculated difficulty target for this block
|-
| nonce
| uint32_t
| 4
| A nonce that is set such that the header&#39;s hash matches the difficult=
y target
|}

When deserializing a correctly-formed sequence of block headers encoded in =
this way, it can be noted that:

* The prev_block field should always match the double-SHA256 hash of the pr=
evious header, making it redundant
* According to Bitcoin consensus rules, the bits field only changes every 2=
016 blocks
* The version often matches that of a recent ancestor block
* The timestamp is often a small delta from the preceding header&#39;s time=
stamp

To take advantage of these possible savings, this document defines a variab=
le-sized &#39;&#39;compressed encoding&#39;&#39; of block headers that occu=
r in a range. Note that no savings are possible when serializing a single h=
eader; it should only be used for vectors of sequential headers. The full h=
eaders are reconstructed using data from previous headers in the range. The=
 serialization begins with an &#39;&#39;encoding indicator&#39;&#39;, which=
 is a bitfield specifying how each field is serialized. The bits of the ind=
icator have the following semantics:

{| class=3D&quot;wikitable&quot;
! Bit Index
! Reconstruction
! Description
|-
| 0
| &lt;code&gt;prev_block[i] =3D DSHA256(header[i-1])&lt;/code&gt;
| The prev_block field is ommitted and assigned to the double-SHA256 hash o=
f the previous uncompressed header.
|-
| 1
| &lt;code&gt;nbits[i] =3D nbits[i-1]&lt;/code&gt;
| The nbits field is omitted and matches that of the previous header.
|-
| 2
| &lt;code&gt;timestamp[i] =3D timestamp[i-1] + value&lt;/code&gt;
| The timestamp is replaced by a 2-byte signed short int, representing an o=
ffset from the previous block&#39;s timestamp
|-
| 3
|
| Interpreted along with bits 4 &amp; 5.
|-
| 4
|
| Interpreted along with bits 3 &amp; 5.
|-
| 5
| &lt;code&gt;version[i] =3D version[i - ((bit[3] &lt;&lt; 2) + (bit[4] &lt=
;&lt; 1) + bit[5])]&lt;/code&gt;
| Bits 3, 4, and 5 are first interpreted as a 3-bit offset, with bit index =
3 as the most significant and bit index 5 as the least significant. If the =
offset is non-zero, the version field is omitted and assigned to the versio=
n of the block at the offset number of blocks prior.
|-
| 6
|
| Reserved.
|-
| 7
|
| Reserved. May be used in a future encoding version to signal another indi=
cator byte.
|}

The compressed header format is versioned by a 256-bit unsigned integer. Th=
is document defines version 0.

=3D=3D=3D=3D VarInt =3D=3D=3D=3D

&#39;&#39;VarInt&#39;&#39; is a variable-length unsigned integer encoding t=
hat supports a greater range of numbers than the standard &#39;&#39;Compact=
Size&#39;&#39;. This encoding was introduced at the database layer in Bitco=
in Core&lt;ref&gt;<a href=3D"https://github.com/bitcoin/bitcoin/commit/4d61=
44f97faf9d2a6c89f41d7d2360f21f0b71e2">https://github.com/bitcoin/bitcoin/co=
mmit/4d6144f97faf9d2a6c89f41d7d2360f21f0b71e2</a>&lt;/ref&gt; in 2012, but =
is new to the Bitcoin P2P layer.

This definition is per the code comments in Bitcoin Core written by Pieter =
Wuille:

&lt;pre&gt;
Variable-length integers: bytes are a MSB base-128 encoding of the number.
The high bit in each byte signifies whether another digit follows. To make
the encoding is one-to-one, one is subtracted from all but the last digit.
Thus, the byte sequence a[] with length len, where all but the last byte
has bit 128 set, encodes the number:

  (a[len-1] &amp; 0x7F) + sum(i=3D1..len-1, 128^i*((a[len-i-1] &amp; 0x7F)+=
1))

Properties:
* Very small (0-127: 1 byte, 128-16511: 2 bytes, 16512-2113663: 3 bytes)
* Every integer has exactly one encoding
* Encoding does not depend on size of original integer type
* No redundancy: every (infinite) byte sequence corresponds to a list
  of encoded integers.

0:         [0x00]  256:        [0x81 0x00]
1:         [0x01]  16383:      [0xFE 0x7F]
127:       [0x7F]  16384:      [0xFF 0x00]
128:  [0x80 0x00]  16511: [0x80 0xFF 0x7F]
255:  [0x80 0x7F]  65535: [0x82 0xFD 0x7F]
2^32:           [0x8E 0xFE 0xFE 0xFF 0x00]
&lt;/pre&gt;

=3D=3D=3D=3D Checkpoints =3D=3D=3D=3D

A &#39;&#39;checkpoint&#39;&#39; is defined for a block as a tuple of its h=
ash and the chain work:

{| class=3D&quot;wikitable&quot;
! Field Name
! Data Type
! Byte Size
! Description
|-
| block_hash
| uint256
| 32
| The hash of the block
|-
| chain_work
| VarInt
| Variable(1-20)
| A delta between the total work in the chain at the checkpoint block and a=
 previous checkpoint, determined by context
|}

=3D=3D=3D Service Bit =3D=3D=3D

This BIP allocates a new service bit:

{| class=3D&quot;wikitable&quot;
|-
| NODE_HEADERS_V2
| &lt;code&gt;1 &lt;&lt; ?&lt;/code&gt;
| If enabled, the node MUST respond to &lt;code&gt;getcheckpts&lt;/code&gt;=
 and &lt;code&gt;getheaders2&lt;/code&gt; queries
|}

=3D=3D=3D New Messages =3D=3D=3D

=3D=3D=3D=3D getcheckpts =3D=3D=3D=3D
&lt;code&gt;getcheckpts&lt;/code&gt; is used to request block headers at a =
specified distance from each other which serve as checkpoints during parall=
el header download. The message contains the following fields:

{| class=3D&quot;wikitable&quot;
! Field Name
! Data Type
! Byte Size
! Description
|-
| block_locator
| uint256[]
| Variable
| A vector of block hashes in descending order by height used to identify t=
he header chain of the requesting node
|-
| interval
| uint32_t
| 4
| The distance in block height between requested block hashes
|}

# Nodes SHOULD NOT send &lt;code&gt;getcheckpts&lt;/code&gt; unless the pee=
r has set the &lt;code&gt;NODE_HEADERS_V2&lt;/code&gt; service bit
# The hashes in &lt;code&gt;block_locator&lt;/code&gt; MUST be in descendin=
g order by block height
# The block locator SHOULD be generated as it is in &lt;code&gt;getheaders&=
lt;/code&gt; requests
# The receiving node MUST respond to valid requests with a &lt;code&gt;chec=
kpts&lt;/code&gt; response where the interval is the same as in the request=
 and the first checkpoint hash matches the first common block hash in the b=
lock locator

=3D=3D=3D=3D checkpts =3D=3D=3D=3D
&lt;code&gt;checkpts&lt;/code&gt; is sent in response to &lt;code&gt;getche=
ckpts&lt;/code&gt;, listing block hashes at the specified interval. The mes=
sage contains the following fields:

{| class=3D&quot;wikitable&quot;
! Field Name
! Data Type
! Byte Size
! Description
|-
| start_height
| uint32_t
| 4
| The height of the first block in the active chain matching the request&#3=
9;s block locator
|-
| end_height
| uint32_t
| 4
| The height of the last block in the active chain
|-
| start_checkpoint
| Checkpoint
| 48
| The checkpoint structure for the block in the active chain at height star=
t_height
|-
| end_checkpoint
| Checkpoint
| 48
| The checkpoint structure for the block in the active chain at height end_=
height
|-
| interval
| uint32_t
| 4
| The distance in block height between checkpoints
|-
| checkpoints_length
| CompactSize
| Variable(1-5)
| The number of checkpoints to follow
|-
| checkpoints
| Checkpoint[]
| checkoints_length * Variable(33-52)
| The checkpoints as specified below
|}

# The interval SHOULD match the field in the &lt;code&gt;getcheckpts&lt;/co=
de&gt; request
# The start_checkpoint SHOULD correspond to the first block hash in the loc=
ator from the &lt;code&gt;getcheckpts&lt;/code&gt; request that is part of =
the active chain
# The end_checkpoint SHOULD correspond to the tip of the node&#39;s active =
chain
# The start_height MOST be set to the block height of the start_checkpoint
# The end_height MOST be set to the block height of the end_checkpoint
# If the interval is zero, the checkpoints vector MUST be empty
# If the interval is non-zero, checkpoints MUST correspond to blocks on the=
 active chain between the start_checkpoint and the end_checkpoint (exclusiv=
e), where the difference in block height between each entry and the previou=
s one is equal to the interval
# The checkpoints_length MUST be less than or equal to 2,000
# The node SHOULD include as many checkpoints on its active chain as are av=
ailable, up to the limit of 2,000
# The chain_work field in the first checkpoint MUST be the total work in th=
e chain ending at that block
# The chain_work field in each subsequent checkpoint MUST be the difference=
 in chain work between that block and the previous checkpoint
# The chain_work field in each checkpoint MUST be a properly-encoded VarInt=
, not exceeding 20 bytes

=3D=3D=3D=3D getheaders2 =3D=3D=3D=3D
&lt;code&gt;getheaders2&lt;/code&gt; is used to request compressed headers =
for a range of blocks. The message contains the following fields:

{| class=3D&quot;wikitable&quot;
! Field Name
! Data Type
! Byte Size
! Description
|-
| max_version
| uint8_t
| 1
| The maximum supported encoding version of the headers
|-
| flags
| uint8_t
| 1
| A bitfield of message encoding flags
|-
| start_height
| uint32_t
| 4
| The height of the first block header in the requested range
|-
| end_hash
| uint256
| 32
| The hash of the last block header in the requested range
|}

# Nodes SHOULD NOT send &lt;code&gt;getheaders2&lt;/code&gt; unless the pee=
r has set the &lt;code&gt;NODE_HEADERS_V2&lt;/code&gt; service bit
# The height of the block with hash end_hash MUST be greater than or equal =
to start_height, and the difference MUST be strictly less than 3,000
# The end_hash SHOULD match one in a previously received &lt;code&gt;checkp=
ts&lt;/code&gt; message, otherwise the receiving node MAY disconnect
# The 0th bit (least significant order) of the flags field MAY be set to re=
quest the coinbase transaction and merkle branch for the block at height st=
art_height

=3D=3D=3D=3D headers2 =3D=3D=3D=3D
&lt;code&gt;headers2&lt;/code&gt; is sent in response to &lt;code&gt;gethea=
ders2&lt;/code&gt;, listing the compressed headers in the requested range. =
The message contains the following fields:

{| class=3D&quot;wikitable&quot;
! Field Name
! Data Type
! Byte Size
! Description
|-
| version
| uint8_t
| 1
| The encoding version of the headers
|-
| flags
| uint8_t
| 1
| A bitfield of message encoding flags
|-
| start_height
| uint32_t
| 4
| The height of the first block header returned
|-
| headers_length
| CompactSize
| 1-3
| The number of block headers to follow
|-
| headers
| CompressedHeader[]
| Variable
| The compressed block headers
|-
| start_block_coinbase_tx
| CTransaction
| Variable
| The coinbase transaction in the block at start_height
|-
| start_block_coinbase_branch
| uint256[]
| Variable
| A merkle branch linking the coinbase transaction in the block at start_he=
ight to its header
|}

# The version MUST be less than or equal to the max_version field of the &l=
t;code&gt;getheaders2&lt;/code&gt; request
# Any bits set in the flags field of the &lt;code&gt;getheaders2&lt;/code&g=
t; request MAY be set in the response field
# Any bits not set in the flags field of the &lt;code&gt;getheaders2&lt;/co=
de&gt; request MUST NOT be set in the response field
# The first header MUST be encoded with a 0-byte indicator (ie. the header =
is uncompressed)
# start_height MUST be set to the block height of the first header
# The hash of the last block SHOULD equal the end_hash of the &lt;code&gt;g=
etheaders2&lt;/code&gt; request, &#39;&#39;even if the block is no longer p=
art of the active chain&#39;&#39;
# The length of the headers vector MUST be less than or equal to 3,000
# The headers MUST be sequential in order of height, with each header a suc=
cessor of the previous one
# Each header SHOULD be optimally compressed
# The start_block_coinbase_tx should be the serialized coinbase transaction=
 in the block corresponding to the first header
# The start_block_coinbase_branch should be a vector of right-hand-side has=
hes in the merkle branch linking the coinbase transaction to the first head=
er, in order from bottom of the tree to top
# If the 0th bit (least significant order) of the flags field is unset, the=
 start_block_coinbase_tx and start_block_coinbase_branch fields MUST be omi=
tted

=3D=3D=3D Sync Strategies =3D=3D=3D

The general header sync protocol for clients now is to first request checkp=
oints from all peers with &lt;code&gt;getcheckpts&lt;/code&gt;, then decide=
 which peers to fetch ranges of headers from and download them with &lt;cod=
e&gt;getheaders2&lt;/code&gt;.

=3D=3D=3D=3D Forward Sequential Syncing =3D=3D=3D=3D

Similar to the current sync protocol, a client may choose one peer to downl=
oad headers from, then fetch them in forward sequential order. Once this pe=
er is out of headers, the client performs the same routine with any peers o=
ffering more headers.

With this strategy, the client is able to fully validate the block headers =
in order and abort if the peer serves an invalid one. On the other hand, th=
e peer may be able to serve a longer, lower-work chain than the global acti=
ve chain, wasting the client&#39;s time, memory, and storage space.

=3D=3D=3D=3D Parallel Header Download =3D=3D=3D=3D

In order to increase the throughput of header downloads, a node may downloa=
d multiple header ranges in parallel from all peers serving the same checkp=
oints, then validate them in sequential order.

=3D=3D=3D=3D Random Sampling Proof-of-Work  =3D=3D=3D=3D

Similar the FlyClient&lt;ref&gt;<a href=3D"https://www.youtube.com/watch?ti=
me_continue=3D8400&amp;v=3DBPNs9EVxWrA">https://www.youtube.com/watch?time_=
continue=3D8400&amp;v=3DBPNs9EVxWrA</a>&lt;/ref&gt; header download protoco=
l, clients can select the peer claiming the greatest total work chain and u=
se random sampling to efficiently determine if the peer is likely to be rep=
orting its chain work honestly.

The client treats the checkpoint message as a commitment to chain work of i=
ntermediate ranges of headers, the client then randomly samples ranges of h=
eaders weighted by total work to determine whether the total chain work is =
valid before downloading all headers. To defend against malicious peers att=
empting to reuse earlier headers later in the chain to fake greater total w=
ork, the client should check the block height in the coinbase transaction f=
or all headers after the BIP 34 activation height. If the peer is found to =
be dishonest, they can be banned before the client downloads too many heade=
rs, otherwise the client chooses this as the primary sync peer for forward =
sequential sync or parallel download.

=3D=3D Rationale =3D=3D

* &#39;&#39;&#39;Why include the coinbase transaction in the headers messag=
es?&#39;&#39;&#39; The primary reason is that after BIP 34&lt;ref&gt;<a hre=
f=3D"https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki">https:=
//github.com/bitcoin/bips/blob/master/bip-0034.mediawiki</a>&lt;/ref&gt; ac=
tivation at block height 227,835, coinbase transactions constitute cryptogr=
aphic commitments to a block&#39;s height in the chain, which mitigates cer=
tain attacks during header sync. Furthermore, the &lt;code&gt;getheaders2&l=
t;/code&gt; message can be used as a simple way of requesting a coinbase tr=
ansaction for a single header, which may be independently useful.

* &#39;&#39;&#39;Why not omit nBits entirely?&#39;&#39;&#39; The compressio=
n is designed to permit full decompression of all headers in a &lt;code&gt;=
headers2&lt;/code&gt; message &#39;&#39;without&#39;&#39; requiring any oth=
er chain context. This is desirable so that proofs of work may be validated=
 for arbitrary header ranges. While nBits can be computed knowing previous =
headers, this requires block headers that may not be sent in the same messa=
ge.

=3D=3D Compatibility =3D=3D

This is backwards compatible, as it defines new P2P messages which are avai=
lable if a service bit is signaled. There are no changes to consensus rules=
.

=3D=3D Acknowledgements =3D=3D

Thanks to Gregory Maxwell for suggestions on the compressed header encoding=
 and the DOS-resistant sync strategies. Thanks to Suhas Daftuar for helpful=
 discussions.

Credit for the VarInt encoding goes to Pieter Wuille.</pre></div></div>

--000000000000193c7705686d4c09--