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
|
Return-Path: <sjors@sprovoost.nl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 09919C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Aug 2021 14:36:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id D682960767
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Aug 2021 14:36:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=sprovoost.nl header.b="XFrbWjBV";
dkim=pass (2048-bit key) header.d=messagingengine.com
header.b="dy9GxCLx"
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id swz_PUsNm48t
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Aug 2021 14:36:05 +0000 (UTC)
X-Greylist: delayed 00:08:45 by SQLgrey-1.8.0
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28])
by smtp3.osuosl.org (Postfix) with ESMTPS id 4A4C060758
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Aug 2021 14:36:05 +0000 (UTC)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
by mailout.nyi.internal (Postfix) with ESMTP id EBAF05C010F;
Thu, 5 Aug 2021 10:27:15 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute5.internal (MEProxy); Thu, 05 Aug 2021 10:27:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
from:content-type:mime-version:subject:date:references:to
:in-reply-to:message-id; s=fm3; bh=NwbQjxzvkeLtlC1K8GqCAsMDtOIeP
AzgKm59TNiYXEA=; b=XFrbWjBVIeWaLtVh+AghdJKHvlXCJS74VA2VvVuULLuv0
+rH48PSMk6Knd5knZlf45LFKXnUjO1LQbmJT6m/Y7PHg28wiu+K1Xd6hS8p7Io1n
QfEg2/X9wmbrhzAddK5+7+W3UQBkHCIM8ZfQxtqQaTEinFm0hZ8mYfXTYGP5p6wu
7M/LhTuQTgAP4eXoPM5Z2YgCVTI3oi9sfJw5YHpqgJy3DEerQQf/5w8z2T0VnvWK
x/b/Nc6mjcPZOJXW68VppmgZ2ogYO1y4modsmI/upqn8zwBlAYAN8Q/IoKXARjO1
Ym8QWrxoTHMAqWOewKg548xuYJZrn5UMIiw1Kl9Aw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-type:date:from:in-reply-to
:message-id:mime-version:references:subject:to:x-me-proxy
:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=NwbQjx
zvkeLtlC1K8GqCAsMDtOIePAzgKm59TNiYXEA=; b=dy9GxCLxzGgHAwQZNXNbq8
ii9doCZgJjPmUyUXiSNaXD16zL2i4zAUvZCyB9nRTK2AnxwTfJYdnqnKjS/sq+NS
ZyaXJ2vx6cDK5bBrR32PFtAIXdNXgRRzALCQHJUizcIeUrwHV8IFPYPXTXt3P3wq
1x2FcpOYIlYrfqYiaUOcnul5pMVw7WuY48gCNqWuv8MMAteKJWM5FFDteXqLwLWc
1an14tbiwp+OuuBTDdvSiiBf158QwD45uVcCeQqhqNBDu6FRplhMYJI3Y2/yMbCH
CjCPCHG9OufeDENLKys55a09ZHibYu2qIkRhzQQFYYGI+QwWBvwAXybWUnGF5lCg
==
X-ME-Sender: <xms:Q_ULYWpItMOhTjyC6NpeoyI0U1YtR-yR9eaas323xrsJow1hf9nrrA>
<xme:Q_ULYUotgEIA-7KjlrAhQJteV7O4xUCXhr1xm9uvNSk9tbfxdCXOi74HhAdcNlLg9
VBPUtuiKiIO5-TlHg>
X-ME-Received: <xmr:Q_ULYbMc3FwH2xEm7zIcZzFKNARj-xbu3KiTv74nlpnIixtFv20d0X93sFUrQcfpV2XanX_ujgpmXsv4zbPTj_L32_HwXZI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieelgdejgecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefhtggguffffhfvjgfkofesghdtmherhhdtvdenucfhrhhomhepufhjohhrshcu
rfhrohhvohhoshhtuceoshhjohhrshesshhprhhovhhoohhsthdrnhhlqeenucggtffrrg
htthgvrhhnpefggefggeeufeevheeuheetleektdejvddvjedtteffgeeiffehudelieej
leelueenucffohhmrghinhepghhithhhuhgsrdgtohhmpdgsihhttghoihhnrdhithdplh
hinhhugihfohhunhgurghtihhonhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecu
rfgrrhgrmhepmhgrihhlfhhrohhmpehsjhhorhhssehsphhrohhvohhoshhtrdhnlh
X-ME-Proxy: <xmx:Q_ULYV52aD8jmOLcsUqwUvMX-rlmf9SnWyM5SmA-IqWnoiSRs7LjnA>
<xmx:Q_ULYV6evrhlq5REcNEeqBXFMfKPL07sQ-DtUQdV9moYw1-H8qr3wQ>
<xmx:Q_ULYVh-AO8H-i2SCHV8_1i3dkvS-gUrv-dYWo-h0e8w09CfkH640w>
<xmx:Q_ULYSj9XikYwae4p9DL20rESKdkqKbUQOucRnbTnAiYUDiSEFFM-w>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
5 Aug 2021 10:27:14 -0400 (EDT)
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
boundary="Apple-Mail=_A38682E3-D2A1-42A2-82F5-096C24AF5825";
protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 5 Aug 2021 16:27:12 +0200
References: <1eb7b635-094c-a583-7dc0-21cea58ed1fb@achow101.com>
To: Andrew Chow <achow101-lists@achow101.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <1eb7b635-094c-a583-7dc0-21cea58ed1fb@achow101.com>
Message-Id: <38AE919F-7EA2-4CF4-9AF8-7E38C7542C59@sprovoost.nl>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Mailman-Approved-At: Thu, 05 Aug 2021 15:06:42 +0000
Subject: Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2021 14:36:08 -0000
--Apple-Mail=_A38682E3-D2A1-42A2-82F5-096C24AF5825
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Thanks for writing this up!
I think your modular BIP approach makes sense. (the abstract should =
mention this too)
Contents look good to me, modulo missing test vectors. I also suggest =
dropping combo(), see below.
Regarding the use of h vs ', especially since they result in a different =
checksum, and equality is more tedious to verify, should we just pick =
one and recommend that software normalises to that?
For bip-descriptors-segwit, regardless of what Bitcoin Core does, is any =
hex encoded script allowed for wsh()? If so is it mandatory and/or =
allowed to use raw() as a sub descriptor?
Conversely, its BIP says: "The <tt>raw(HEX)</tt> expression can only be =
used as a top level descriptor". That answers the above, but not the =
why.
In the backwards compatibility section it may be worth pointing out that =
descriptors are also used by:
* Specter since at least v1.2.2: =
https://github.com/cryptoadvance/specter-desktop/releases/tag/v1.2.2
* Coldcard since 2.0.1: =
https://github.com/Coldcard/firmware/commit/af00f8778947664f2d74f19879b98f=
7925feb327
* HWI since 1.0.3: =
https://github.com/bitcoin-core/HWI/releases/tag/1.0.3
None of these support the tr(), raw() and addr() descriptors afaik. HWI =
doesn't implement (sorted_)multi.
Does anyone actually use combo? It seems useless, because even with the =
help of BIP 88 there's no way to compress all three in a single =
descriptor, since BIP 44/49/84 each have a different derivation. Afaik =
Bitcoin Core doesn't really use them either. And for future wallet =
migration, we might as well make separate descriptors for each key type.
One thing on my wish list - for this BIP, BIP 88 (Hierarchical =
Deterministic Path Templates) or yet another one - is to include a birth =
date (minimum block height). E.g. =
tr([m/86'/0'/0']xpub.../{0-1}/*)>709631
And then of course there's the gap limit. Perhaps we just need a =
"metadata" format to go along with descriptors to track the birth data, =
gap limit and anything else you need (nonce collection for musig2 =
setup?). E.g. a simple dictionary: =
tr([m/86'/0'/0']xpub.../{0-1}/*){dob:709631,gap:1000}
- Sjors
> Op 29 jun. 2021, om 23:14 heeft Andrew Chow via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> Hi All,
>=20
> I've been working on formalizing the Output Script Descriptors that =
have
> been available in Bitcoin Core for a while into BIPs. Since =
descriptors
> are modular and have optional components, I've decided to split it =
into
> 7 BIPs, rather than a single one. The first describes descriptors in
> general and does not specify any particular descriptor. However it =
does
> describe the general operation, key expressions (including derivation
> paths and key origin info), and the descriptor checksum. The following =
6
> BIPs specify the actual descriptors themselves. These are non-segwit
> descriptor (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig
> descriptors (multi, sortedmulti), the taproot descriptor (tr), the =
combo
> descriptor, and opaque descriptors (raw, addr). This separation is so
> that implementors can choose to not implement some descriptors and =
still
> say which descriptors they support without being too difficult to
> understand.
>=20
> The text of all of the documents are below, and they can also be found
> on github:https://github.com/achow101/bips/tree/descriptors/
>=20
> Thanks,
> Andrew Chow
>=20
> ---
>=20
> <pre>
> BIP: bip-descriptors-general
> Layer: Applications
> Title: Output Script Descriptors General Operation
> Author: Pieter Wuille <pieter@wuille.net>
> Andrew Chow <andrew@achow101.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-general
> Status: Draft
> Type: Informational
> Created: 2021-06-27
> License: BSD-2-Clause
> </pre>
>=20
> =3D=3DAbstract=3D=3D
>=20
> Output Script Descriptors are a simple language which can be used to
> describe collections ofoutput scripts.
> There can be many different descriptor fragments and functions.
> This document describes the general syntax for descriptors, descriptor
> checksums, and common expressions.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> Bitcoin wallets traditionally have stored a set of keys which are =
later
> serialized and mutated to produce the output scripts that the wallet
> watches and the addresses it provides to users.
> Typically backups have consisted of solely the private keys, nowadays
> primarily in the form of BIP 39 mnemonics.
> However this backup solution is insuffient, especially since the
> introduction of Segregated Witness which added new output types.
> Given just the private keys, it is not possible for restored wallets =
to
> know which kinds of output scripts and addresses to produce.
> This has lead to incompatibilities between wallets when restoring a
> backup or exporting data for a watch only wallet.
>=20
> Further complicating matters are BIP 32 derivation paths.
> Although BIPs 44, 49, and 84 have specified standard BIP 32 derivation
> paths for different output scripts and addresses, not all wallets
> support them nor use those derivation paths.
> The lack of derivation path information in these backups and exports
> leads to further incompatibilities between wallets.
>=20
> Current solutions to these issues have not been generic and can be
> viewed as being layer violations.
> Solutions such as introducing different version bytes for extended key
> serialization both are a layer violation (key derivation should be
> separate from script type meaning) and specific only to a particular
> derivation path and script type.
>=20
> Output Script Descriptors introduces a generic solution to these =
issues.
> Script types are specified explicitly through the use of Script =
Expressions.
> Key derivation paths are specified explicitly in Key Expressions.
> These allow for creating wallet backups and exports which specify the
> exact scripts, subscripts (redeemScript, witnessScript, etc.), and =
keys
> to produce.
> With the general structure specified in this BIP, new Script =
Expressions
> can be introduced as new script types are added.
> Lastly, the use of common terminology and existing standards allow for
> Output Script Descriptors to be engineer readable so that the results
> can be understood at a glance.
>=20
> =3D=3DSpecification=3D=3D
>=20
> Descriptors consist of several types of expressions.
> The top level expression is a <tt>SCRIPT</tt>.
> This expression may be followed by <tt>#CHECKSUM</tt>, where
> <tt>CHECKSUM</tt> is an 8 character alphanumeric descriptor checksum.
>=20
> =3D=3D=3DScript Expressions=3D=3D=3D
>=20
> Script Expressions (denoted <tt>SCRIPT</tt>) are expressions which
> correspond directly with a Bitcoin script.
> These expressions are written as functions and take arguments.
> Such expressions have a script template which is filled with the
> arguments correspondingly.
> Expressions are written with a human readable identifier string with =
the
> arguments enclosed with parentheses.
> The identifier string should be alphanumeric and may include =
underscores.
>=20
> The arguments to a script expression are defined by that expression =
itself.
> They could be a script expression, a key expression, or some other
> expression entirely.
>=20
> =3D=3D=3DKey Expressions=3D=3D=3D
>=20
> A common expression used as an argument to script expressions are key
> expressions (denoted <tt>KEY</tt>).
> These represent a public or private key and, optionally, information
> about the origin of that key.
> Key expressions can only be used as arguments to script expressions.
>=20
> Key expressions consist of:
> * Optionally, key origin information, consisting of:
> ** An open bracket <tt>[</tt>
> ** Exactly 8 hex characters for the fingerprint of the key where the
> derivation starts (see BIP 32 for details)
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUM'</tt> path
> elements to indicate the unhardened or hardened derivation steps =
between
> the fingerprint and the key that follows.
> ** A closing bracket <tt>]</tt>
> * Followed by the actual key, which is either:
> ** A hex encoded public key, which depending the script expression, =
may
> be either:
> *** 66 hex character string beginning with <tt>02</tt> or <tt>03</tt>
> representing a compressed public key
> *** 130 hex character string beginning with <tt>04</tt> representing =
an
> uncompressed public key
> *** 64 hex character string representing an x-only public key
> ** A [[https://en.bitcoin.it/wiki/Wallet_import_format|WIF]] encoded
> private key
> ** <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
> extended private key (as defined in BIP 32)
> *** Followed by zero or more <tt>/NUM</tt> or <tt>/NUM'</tt> path
> elements indicating BIP 32 derivation steps to be taken after the =
given
> extended key.
> *** Optionally followed by a single <tt>/*</tt> or <tt>/*'</tt> final
> step to denote all direct unhardened or hardened children.
>=20
> If the <tt>KEY</tt> is a BIP 32 extended key, before output scripts =
can
> be created, child keys must be derived using the derivation =
information
> that follows the extended key.
> When the final step is <tt>/*</tt> or <tt>/*'</tt>, an output script
> will be produced for every child key index.
> The derived key must be serialized as a compressed public key.
>=20
> In the above specification, the hardened indicator <tt>'</tt> may be
> replaced with alternative hardnened indicators of <tt>h</tt> or =
<tt>H</tt>.
>=20
> =3D=3D=3DCharacter Set=3D=3D=3D
>=20
> The expressions used in descriptors must only contain characters =
within
> this character set so that the descriptor checksum will work.
>=20
> The allowed characters are:
> <pre>
> 0123456789()[],'/*abcdefgh@:$%{}
> IJKLMNOPQRSTUVWXYZ&+-.;<=3D>?!^_|~
> ijklmnopqrstuvwxyzABCDEFGH`#"\<space>
> </pre>
> Note that <tt><space></tt> on the last line is a space character.
>=20
> This character set is written as 3 groups of 32 characters in this
> specific order so that the checksum below can identify more errors.
> The first group are the most common "unprotected" characters (i.e.
> things such as hex and keypaths that do not already have their own
> checksums).
> Case errors cause an offset that is a multiple of 32 while as many
> alphabetic characters are in the same group while following the =
previous
> restrictions.
>=20
> =3D=3D=3DChecksum=3D=3D=3D
>=20
> Follwing the top level script expression is a single octothorpe
> (<tt>#</tt>) followed by the 8 character checksum.
> The checksum is an error correcting checksum similar to bech32.
>=20
> The checksum has the following properties:
> * Mistakes in a descriptor string are measured in "symbol errors". The
> higher the number of symbol errors, the harder it is to detect:
> ** An error substituting a character from
> <tt>0123456789()[],'/*abcdefgh@:$%{}</tt> for another in that set =
always
> counts as 1 symbol error.
> *** Note that hex encoded keys are covered by these characters. =
Extended
> keys (<tt>xpub</tt> and <tt>xprv</tt>) use other characters too, but
> also have their own checksum mechansim.
> *** <tt>SCRIPT</tt> expression function names use other characters, =
but
> mistakes in these would generally result in an unparsable descriptor.
> ** A case error always counts as 1 symbol error.
> ** Any other 1 character substitution error counts as 1 or 2 symbol =
errors.
> * Any 1 symbol error is always detected.
> * Any 2 or 3 symbol error in a descriptor of up to 49154 characters is
> always detected.
> * Any 4 symbol error in a descriptor of up to 507 characters is always
> detected.
> * Any 5 symbol error in a descriptor of up to 77 characters is always
> detected.
> * Is optimized to minimize the chance of a 5 symbol error in a
> descriptor up to 387 characters is undetected
> * Random errors have a chance of 1 in 2<super>40</super> of being
> undetected.
>=20
> The checksum itself uses the same character set as bech32:
> <tt>qpzry9x8gf2tvdw0s3jn54khce6mua7l</tt>
>=20
> Valid descriptor strings with a checksum must pass the criteria for
> validity specified by the Python3 code snippet below.
> The function <tt>descsum_check</tt> must return true when its argument
> <tt>s</tt> is a descriptor consisting in the form =
<tt>SCRIPT#CHECKSUM</tt>.
>=20
> <pre>
> INPUT_CHARSET =3D
> =
"0123456789()[],'/*abcdefgh@:$%{}IJKLMNOPQRSTUVWXYZ&+-.;<=3D>?!^_|~ijklmno=
pqrstuvwxyzABCDEFGH`#\"\\
> "
> CHECKSUM_CHARSET =3D "qpzry9x8gf2tvdw0s3jn54khce6mua7l"
> GENERATOR =3D [0xf5dee51989, 0xa9fdca3312, 0x1bab10e32d, 0x3706b1677a,
> 0x644d626ffd]
>=20
> def descsum_polymod(symbols):
> """Internal function that computes the descriptor checksum."""
> chk =3D 1
> for value in symbols:
> top =3D chk >> 35
> chk =3D (chk & 0x7ffffffff) << 5 ^ value
> for i in range(5):
> chk ^=3D GENERATOR[i] if ((top >> i) & 1) else 0
> return chk
>=20
> def descsum_expand(s):
> """Internal function that does the character to symbol =
expansion"""
> groups =3D []
> symbols =3D []
> for c in s:
> if not c in INPUT_CHARSET:
> return None
> v =3D INPUT_CHARSET.find(c)
> symbols.append(v & 31)
> groups.append(v >> 5)
> if len(groups) =3D=3D 3:
> symbols.append(groups[0] * 9 + groups[1] * 3 + groups[2])
> groups =3D []
> if len(groups) =3D=3D 1:
> symbols.append(groups[0])
> elif len(groups) =3D=3D 2:
> symbols.append(groups[0] * 3 + groups[1])
> return symbols
>=20
> def descsum_check(s):
> """Verify that the checksum is correct in a descriptor"""
> if s[-9] !=3D '#':
> return False
> if not all(x in CHECKSUM_CHARSET for x in s[-8:]):
> return False
> symbols =3D descsum_expand(s[:-9]) + [CHECKSUM_CHARSET.find(x) for =
x
> in s[-8:]]
> return descsum_polymod(symbols) =3D=3D 1
> </pre>
>=20
> This implements a BCH code that has the properties described above.
> The entire descriptor string is first processed into an array of =
symbols.
> The symbol for each character is its position within its group.
> After every 3rd symbol, a 4th symbol is inserted which represents the
> group numbers combined together.
> This means that a change that only affects the position within a =
group,
> or only a group number change, will only affect a single symbol.
>=20
> To construct a valid checksum given a script expression, the code =
below
> can be used:
>=20
> <pre>
> def descsum_create(s):
> """Add a checksum to a descriptor without"""
> symbols =3D descsum_expand(s) + [0, 0, 0, 0, 0, 0, 0, 0]
> checksum =3D descsum_polymod(symbols) ^ 1
> return s + '#' + ''.join(CHECKSUM_CHARSET[(checksum >> (5 * (7 -
> i))) & 31] for i in range(8))
>=20
> </pre>
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> Output script descriptors are an entirely new language which is not
> compatible with any existing software.
> However many components of the expressions reuse encodings and
> serializations defined by previous BIPs.
>=20
> Output script descriptors are designed for future extension with =
further
> fragment types and new script expressions.
> These will be specified in additional BIPs.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> Descriptors have been implemented in Bitcoin Core since version 0.17.
>=20
> ---
>=20
> <pre>
> BIP: bip-descriptors-segwit
> Layer: Applications
> Title: segwit Output Script Descriptors
> Author: Pieter Wuille <pieter@wuille.net>
> Andrew Chow <andrew@achow101.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-segwit
> Status: Draft
> Type: Informational
> Created: 2021-06-27
> License: BSD-2-Clause
> </pre>
>=20
> =3D=3DAbstract=3D=3D
>=20
> This document specifies <tt>wpkh()</tt>, and <tt>wsh()</tt> output
> script descriptors.
> <tt>wpkh()</tt> descriptors take a key and produces a P2WPKH output =
script.
> <tt>wsh()</tt> descriptors take a script and produces a P2WSH output =
script.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> Segregated Witness added 2 additional standard output script formats:
> P2WPKH and P2WSH.
> These expressions allow specifying those formats as a descriptor.
>=20
> =3D=3DSpecification=3D=3D
>=20
> Two new script expressions are defined: <tt>wpkh()</tt>, and =
<tt>wsh()</tt>.
>=20
> =3D=3D=3D<tt>wpkh()</tt>=3D=3D=3D
>=20
> The <tt>wpkh(KEY)</tt> expression can be used as a top level =
expression,
> or inside of a <tt>sh()</tt> descriptor.
> It takes a single key expression as an argument and produces a P2WPKH
> output script.
> Only keys which are/has compressed public keys can be contained in a
> <tt>wpkh()</tt> expression.
>=20
> The output script produced is:
> <pre>
> OP_0 <KEY_hash160>
> </pre>
>=20
> =3D=3D=3D<tt>wsh()</tt>=3D=3D=3D
>=20
> The <tt>wsh(SCRIPT)</tt> expression can be used as a top level
> expression, or inside of a <tt>sh()</tt> descriptor.
> It takes a single script expression as an argument and produces a =
P2WSH
> output script.
> <tt>wsh()</tt> expressions also create a witnessScript which is =
required
> in order to spend outputs which use its output script.
> This redeemScript is the output script produced by the <tt>SCRIPT</tt>
> argument to <tt>wsh()</tt>.
> Any key expression found in any script expression contained by a
> <tt>wsh()</tt> expression must only produce compresed public keys.
>=20
> The output script produced is:
> <pre>
> OP_0 <SCRIPT_sha256>
> </pre>
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors use the format and
> general operation specified in
> [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
> As these are a wholly new descriptors, they are not compatible with =
any
> implementation.
> However the scripts produced are standard scripts so existing software
> are likely to be familiar with them.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>wpkh()</tt>, and <tt>wsh()</tt> descriptors have been implemented =
in
> Bitcoin Core since version 0.17.
>=20
> ---
>=20
> <pre>
> BIP: bip-descriptors-non-segwit
> Layer: Applications
> Title: Non-segwit Output Script Descriptors
> Author: Pieter Wuille <pieter@wuille.net>
> Andrew Chow <andrew@achow101.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> =
https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-non-segwit
> Status: Draft
> Type: Informational
> Created: 2021-06-27
> License: BSD-2-Clause
> </pre>
>=20
> =3D=3DAbstract=3D=3D
>=20
> This document specifies <tt>pk()</tt>, <tt>pkh()</tt>, and =
<tt>sh()</tt>
> output script descriptors.
> <tt>pk()</tt> descriptors take a key and produces a P2PK output =
script.
> <tt>pkh()</tt> descriptors take a key and produces a P2PKH output =
script.
> <tt>sh()</tt> descriptors take a script and produces a P2SH output =
script.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> Prior to the activation of Segregated Witness, there were 3 main
> standard output script formats: P2PK, P2PKH, and P2SH.
> These expressions allow specifying those formats as a descriptor.
>=20
> =3D=3DSpecification=3D=3D
>=20
> Three new script expressions are defined: <tt>pk()</tt>, =
<tt>pkh()</tt>,
> and <tt>sh()</tt>.
>=20
> =3D=3D=3D<tt>pk()</tt>=3D=3D=3D
>=20
> The <tt>pk(KEY)</tt> expression can be used in any context or level of =
a
> descriptor.
> It takes a single key expression as an argument and produces a P2PK
> output script.
> Depending on the higher level descriptors, there may be restrictions =
on
> the type of public keys that can be included.
> Such restrictions will be specified by those descriptors.
>=20
> The output script produced is:
> <pre>
> <KEY> OP_CHECKSIG
> </pre>
>=20
> =3D=3D=3D<tt>pkh()</tt>=3D=3D=3D
>=20
> The <tt>pkh(KEY)</tt> expression can be used as a top level =
expression,
> or inside of either a <tt>sh()</tt> or <tt>wsh()</tt> descriptor.
> It takes a single key expression as an argument and produces a P2PKH
> output script.
> Depending on the higher level descriptors, there may be restrictions =
on
> the type of public keys that can be included.
> Such restrictions will be specified by those descriptors.
>=20
> The output script produced is:
> <pre>
> OP_DUP OP_HASH160 <KEY_hash160> OP_EQUALVERIFY OP_CHECKSIG
> </pre>
>=20
> =3D=3D=3D<tt>sh()</tt>=3D=3D=3D
>=20
> The <tt>sh(SCRIPT)</tt> expression can only be used as a top level
> expression.
> It takes a single script expression as an argument and produces a P2SH
> output script.
> <tt>sh()</tt> expressions also create a redeemScript which is required
> in order to spend outputs which use its output script.
> This redeemScript is the output script produced by the <tt>SCRIPT</tt>
> argument to <tt>sh()</tt>.
>=20
> The output script produced is:
> <pre>
> OP_HASH160 <SCRIPT_hash160> OP_EQUAL
> </pre>
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors use the
> format and general operation specified in
> [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
> As these are a wholly new descriptors, they are not compatible with =
any
> implementation.
> However the scripts produced are standard scripts so existing software
> are likely to be familiar with them.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> descriptors have been
> implemented in Bitcoin Core since version 0.17.
>=20
> ---
>=20
> <pre>
> BIP: bip-descriptors-tr
> Layer: Applications
> Title: tr() Output Script Descriptors
> Author: Pieter Wuille <pieter@wuille.net>
> Andrew Chow <andrew@achow101.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-tr
> Status: Draft
> Type: Informational
> Created: 2021-06-27
> License: BSD-2-Clause
> </pre>
>=20
> =3D=3DAbstract=3D=3D
>=20
> This document specifies <tt>tr()</tt> output script descriptors.
> <tt>tr()</tt> descriptors take a key and optionally a tree of scripts
> and produces a P2TR output script.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> Taproot added one additional standard output script format: P2TR.
> These expressions allow specifying those formats as a descriptor.
>=20
> =3D=3DSpecification=3D=3D
>=20
> A new script expressions are defined: <tt>tr()</tt>.
> A new expression is defined: Tree Expressions
>=20
> =3D=3D=3DTree Expression=3D=3D=3D
>=20
> A Tree Expression (denoted <tt>TREE</tt>) is an expression which
> represents a tree of scripts.
> The way the tree is represented in an output script is dependent on =
the
> higher level expressions.
>=20
> A Tree Expression is:
> * Any Script Expression that is allowed at the level this Tree
> Expression is in.
> * A pair of Tree Expressions consisting of:
> ** An open brace <tt>{</tt>
> ** A Tree Expression
> ** A comma <tt>,</tt>
> ** A Tree Expression
> ** A closing brance <tt>}</tt>
>=20
> =3D=3D=3D<tt>tr()</tt>=3D=3D=3D
>=20
> The <tt>tr(KEY)</tt> or <tt>tr(KEY, TREE)</tt> expression can only be
> used as a top level expression.
> All key expressions under any <tt>tr()</tt> expression must create
> x-only public keys.
>=20
> <tt>tr(KEY</tt> takes a single key expression as an argument and
> produces a P2TR output script which does not have a script path.
> The keys produced by the key expression are used as the internal key =
as
> specified by [[bip-0341.mediawiki#cite_ref-22-0|BIP 341]].
> Specifically, "If the spending conditions do not require a script =
path,
> the output key should commit to an unspendable script path instead of
> having no script path.
> This can be achieved by computing the output key point as ''Q =3D P +
> int(hash<sub>TapTweak</sub>(bytes(P)))G''."
>=20
> <pre>
> internal_key: lift_x(KEY)
> 32_byte_output_key: internal_key + =
int(HashTapTweak(bytes(internal_key)))G
> scriptPubKey: OP_1 <32_byte_output_key>
> </pre>
>=20
> <tt>tr(KEY, TREE)</tt> takes a key expression as the first argument, =
and
> a tree expression as the second argument and produces a P2TR output
> script which has a script path.
> The keys produced by the first key expression are used as the internal
> key as specified by
> [[bip-0341.mediawiki#Constructing_and_spending_Taproot_outputs|BIP =
341]].
> The Tree expression becomes the Taproot script tree as described in =
BIP 341.
> A merkle root is computed from this tree and combined with the =
internal
> key to create the Taproot output key.
>=20
> <pre>
> internal_key: lift_x(KEY)
> merkle_root: HashTapBranch(TREE)
> 32_byte_output_key: internal_key + =
int(HashTapTweak(bytes(internal_key)
> || merkle_root))G
> scriptPubKey: OP_1 <32_byte_output_key>
> </pre>
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <tt>tr()</tt> descriptors use the format and general operation =
specified
> in [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
> As these are a wholly new descriptors, they are not compatible with =
any
> implementation.
> However the scripts produced are standard scripts so existing software
> are likely to be familiar with them.
>=20
> Tree Expressions are largely incompatible with existing script
> expressions due to the restrictions in those expressions.
> As of 2021-06-27, the only allowed script expression that can be used =
in
> a tree expression is <tt>pk()</tt>.
> However there will be future BIPs that specify script expressions that
> can be used in tree expressions.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>tr()</tt> descriptors have been implemented in Bitcoin Core since
> version 22.0.
>=20
> ---
>=20
> <pre>
> BIP: bip-descriptors-multi
> Layer: Applications
> Title: Multisig Output Script Descriptors
> Author: Pieter Wuille <pieter@wuille.net>
> Andrew Chow <andrew@achow101.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-multi
> Status: Draft
> Type: Informational
> Created: 2021-06-27
> License: BSD-2-Clause
> </pre>
>=20
> =3D=3DAbstract=3D=3D
>=20
> This document specifies <tt>multi()</tt>, and <tt>sortedmulti()</tt>
> output script descriptors.
> Both functions take a threshold and one or more public keys and =
produce
> a multisig output script.
> <tt>multi()</tt> specifies the public keys in the output script in the
> order given in the descriptor while <tt>sortedmulti()</tt> sorts the
> public keys lexicographically when the output script is produced.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> The most common complex script used in Bitcoin is a threshold =
multisig.
> These expressions allow specifying multisig scripts as a descriptor.
>=20
> =3D=3DSpecification=3D=3D
>=20
> Two new script expressions are defined: <tt>multi()</tt>, and
> <tt>sortedmulti()</tt>.
> Both expressions produce the scripts of the same template and take the
> same arguments.
> They are written as <tt>multi(k,KEY_1,KEY_2,...,KEY_n)</tt>.
> <tt>k</tt> is the threshold - the number of keys that must sign the
> input for the script to be valid.
> <tt>KEY_1,KEY_2,...,KEY_n</tt> are the key expressions for the =
multisig.
> <tt>k</tt> must be less than or equal to <tt>n<tt>.
>=20
> <tt>multi()</tt> and <tt>sortedmulti()</tt> expressions can be used as =
a
> top level expression, or inside of either a <tt>sh()</tt> or
> <tt>wsh()</tt> descriptor.
> Depending on the higher level descriptors, there may be restrictions =
on
> the type of public keys that can be included.
>=20
> Depending on the higher level descriptors, there are also restrictions
> on the number of keys that can be present, i.e. the maximum value of
> <tt>n</tt>.
> When used at the top level, there can only be at most 3 keys.
> When used inside of a <tt>sh()</tt> expression, there can only be most
> 15 compressed public keys (this is limited by the P2SH script limit).
> Otherwise the maximum number of keys is 20.
>=20
> The output script produced also depends on the value of <tt>k</tt>. If
> <tt>k</tt> is less than or equal to 16:
> <pre>
> OP_k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
> </pre>
>=20
> if <tt>k</tt> is greater than 16:
> <pre>
> k KEY_1 KEY_2 ... KEY_n OP_CHECKMULTISIG
> </pre>
>=20
> =3D=3D=3D<tt>sortedmulti()</tt>=3D=3D=3D
>=20
> The only change for <tt>sortedmulti()</tt> is that the keys are sorted
> lexicographically prior to the creation of the output script.
> This sorting is on the keys that are to be put into the output script,
> i.e. after all extended keys are derived.
>=20
> =3D=3D=3DMultiple Extended Keys</tt>=3D=3D=3D
>=20
> When one or more the key expressions in a <tt>multi()</tt> or
> <tt>sortedmulti()</tt> expression are extended keys, the derived keys
> use the same child index.
> This changes the keys in lockstep and allows for output scripts to be
> indexed in the same way that the derived keys are indexed.
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <tt>multi()</tt>, and <tt>sortedmulti()</tt> descriptors use the =
format
> and general operation specified in
> [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
> As these are a wholly new descriptors, they are not compatible with =
any
> implementation.
> However the scripts produced are standard scripts so existing software
> are likely to be familiar with them.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>multi()</tt>, and <tt>multi()</tt> descriptors have been =
implemented
> in Bitcoin Core since version 0.17.
>=20
> ---
>=20
> <pre>
> BIP: bip-descriptors-combo
> Layer: Applications
> Title: combo() Output Script Descriptors
> Author: Pieter Wuille <pieter@wuille.net>
> Andrew Chow <andrew@achow101.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-combo
> Status: Draft
> Type: Informational
> Created: 2021-06-27
> License: BSD-2-Clause
> </pre>
>=20
> =3D=3DAbstract=3D=3D
>=20
> This document specifies <tt>combo()</tt> output script descriptors.
> These take a key and produce P2PK, P2PKH, P2WPKH, and P2SH-P2WPKH =
output
> scripts if applicable to the key.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> In order to make the transition from traditional key based wallets to
> descriptor based wallets easier, it is useful to be able to take a key
> and produce the scripts which have traditionally been produced by =
wallet
> software.
>=20
> =3D=3DSpecification=3D=3D
>=20
> A new top level script expression is defined: <tt>combo(KEY)</tt>.
> This expression can only be used as a top level expression.
> It takes a single key expression as an argument and produces either 2 =
or
> 4 output scripts, depending on the key.
> A <tt>combo()</tt> expression always produces a P2PK and P2PKH script,
> the same as putting the key in both a <tt>pk()</tt> and a =
<tt>pkh()</tt>
> expression.
> If the key is/has a compressed public key, then P2WPKH and P2SH-P2WPKH
> scripts are also produced, the same as putting the key in both a
> <tt>wpkh()</tt> and <tt>sh(wpkh())</tt> expression.
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <tt>combo()</tt> descriptors use the format and general operation
> specified in =
[[bip-descriptor-general.mediawiki|bip-descriptor-general]].
> As this is a wholly new descriptor, it is not compatible with any
> implementation.
> However the scripts produced are standard scripts so existing software
> are likely to be familiar with them.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>combo</tt> descriptors have been implemented in Bitcoin Core since
> version 0.17.
>=20
> ---
>=20
> <pre>
> BIP: bip-descriptors-encap
> Layer: Applications
> Title: raw() and addr() Output Script Descriptors
> Author: Andrew Chow <andrew@achow101.com>
> Pieter Wuille <pieter@wuille.net>
> Comments-Summary: No comments yet.
> Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-descriptors-raw
> Status: Draft
> Type: Informational
> Created: 2021-06-27
> License: BSD-2-Clause
> </pre>
>=20
> =3D=3DAbstract=3D=3D
>=20
> This document specifies <tt>raw()</tt> and <tt>addr()</tt> output =
script
> descriptors.
> <tt>raw()</tt> encapsulates a raw script as a descriptor.
> <tt>addr()</tt> encapsulates an address as a descriptor.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This BIP is licensed under the BSD 2-clause license.
>=20
> =3D=3DMotivation=3D=3D
>=20
> In order to make descriptors maximally compatible with scripts in use
> today, it is useful to be able to wrap any arbitrary output script or =
an
> address into a descriptor.
>=20
> =3D=3DSpecification=3D=3D
>=20
> Two new script expressions are defined: <tt>raw()</tt> and =
<tt>addr()</tt>.
>=20
> =3D=3D=3D<tt>raw()</tt>=3D=3D=3D
>=20
> The <tt>raw(HEX)</tt> expression can only be used as a top level =
descriptor.
> As the argument, it takes a hex string representing a Bitcoin script.
> The output script produced by this descriptor is the script =
represented
> by <tt>HEX</tt>.
>=20
> =3D=3D=3D<tt>addr()</tt>=3D=3D=3D
>=20
> The <tt>addr(ADDR)</tt> expression can only be used as a top level
> descriptor.
> It takes an address as its single argument.
> The output script produced by this descriptor is the output script
> produced by the address <tt>ADDR</tt>.
>=20
> =3D=3DTest Vectors=3D=3D
>=20
> TBD
>=20
> =3D=3DBackwards Compatibility=3D=3D
>=20
> <tt>raw()</tt> and <tt>addr()</tt> descriptors use the format and
> general operation specified in
> [[bip-descriptor-general.mediawiki|bip-descriptor-general]].
> As this is a wholly new descriptor, it is not compatible with any
> implementation.
> The reuse of existing Bitcoin addresses allows for this to be more
> easily implemented.
>=20
> =3D=3DReference Implemntation=3D=3D
>=20
> <tt>raw()</tt> and <tt>addr</tt> descriptors have been implemented in
> Bitcoin Core since version 0.17.
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_A38682E3-D2A1-42A2-82F5-096C24AF5825
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAmEL9UAACgkQV/+b28ww
EAkTmRAApLV8uwXo8KPsa/xc7Wf9wokXSkznolSuFhxEj4I/lrzHq3tYUu/moOhY
t0ITj4V8AXJP5BVkLGMcQ4UpSuM0s7KeVy5EX46ZIVBnnkqPOxsCcHSSOzD7TJFC
2QM8iqN5ehKR+h7bklHcaUfPucACyZ7k6ICJ6X3G2hmQOqvJoWSJz/H3Z4UZ9T2N
5kr0eEusN2slqgH5/JuQ63GdIHnPozxKWEBJ1Y/XW8bDdKLc1kDF2aXDci8CVAQZ
1HgRyHsg1Ia7jyPmt3lSPOGvBIcQPWTrdxxXfKizmto7hx3SOHfs3O1qz9eSpIwe
iZjSk2YB9UkbaoVXNqAdWYVQhX19ys6I8mepHPSfyJYNOq2O/ldHajK3aZGwohjD
ynSb1TA1MeRmMHa5SpGOSUeOyGOP+jGJ8kqKbXBX+TrNKGpHn3G6n5E1lykFO2Ji
ZLCDsx/gC+trmOOwDMf9i6KOxi20E6GwE9ev5Z0KoipQpAJesHpFKm4i9kv5gZK4
OL9V/XlubmxsegwcPn+GQXrDZ3UmVe5htiORFEMHih4CAuhCKJkXU/EOqDVmEJf3
URUeaIhx1L+SrIhnsO+q54Q/rrCX6YeOKLpzckGnP/6x/H/CHxRFPIMRODBQr3oI
1xmQUluza/QBfuAlZQzPCs1ql8sgFijWZJfmNfp/cYFnCw9QptE=
=zXkj
-----END PGP SIGNATURE-----
--Apple-Mail=_A38682E3-D2A1-42A2-82F5-096C24AF5825--
|