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
|
Return-Path: <darosior@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id F18ADC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 May 2022 11:37:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id DE6BF60797
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 May 2022 11:37:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, FREEMAIL_FROM=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=protonmail.com
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 2ozIYrN427Js
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 May 2022 11:37:00 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
by smtp3.osuosl.org (Postfix) with ESMTPS id 9FF8660595
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 May 2022 11:36:59 +0000 (UTC)
Date: Mon, 09 May 2022 11:36:47 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail2; t=1652096215;
bh=RytI5atiIx5vUB2MIp7Zw2WaOo029bXqYf9T+CHMCss=;
h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=TuWW/m7L3HuWk+4bsX214tpZk189Pebl4jbLZDF+VFrZMao/96yMv0SQRogEH/sGH
cZ8SaA/T1nIssAIzkW7p2aFwJlYL7Ujf5cu/Yhrtn4H2muShetTsDUHrQj1zUB2nRV
Hn5mDuBsWojwZ86pYl7fGHvRVW76Z7Ow58+biA/OTAa9bT4/nyJg0fT2EP8YG33kJn
ImEBpmU1kxy7mPGxT9g1GrpYKUVqlthJfbiNm5B0ALNqTzfs+MbW9w2HWQ1VqvBMsr
zJsOsfNBSrUzZIiI9KAtzOWRWDE8HzrKp0ccOQn0k26L2zuiSU/N9ey4PFyNrtpUMr
y4VUrNe9RIt4Q==
To: Salvatore Ingala <salvatore.ingala@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <osdF1jSCUyGyaLZ6YytSB7ub1MwdbaP6PMCYEJZXmMRaSs4vS7bs_SZTErxZh_K7oLYLAtAqqgl0Vcdl1ftAusM_1DHSDHtz1kSUzqnmwsk=@protonmail.com>
In-Reply-To: <CAMhCMoHfdsQMsVigFqPexTE_q-Cyg7pfRvORUoy2sZtvyzd1cg@mail.gmail.com>
References: <CAMhCMoHfdsQMsVigFqPexTE_q-Cyg7pfRvORUoy2sZtvyzd1cg@mail.gmail.com>
Feedback-ID: 7060259:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 09 May 2022 11:44:39 +0000
Subject: Re: [bitcoin-dev] Wallet policies for descriptor wallets
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: Mon, 09 May 2022 11:37:03 -0000
Thanks for taking the time to write up about the implementation of output d=
escriptors on signing devices, and
for proposing a method to overcome encountered difficulties for the followi=
ng implementers.
I have some questions with regard to the modifications to the descriptor la=
nguage required to make the
registration flow reasonable on a signing device.
To sum up, starting from the currently spec'd output descriptors [0] you ne=
ed:
1. The `<NUM;NUM>` optimization for the common usecase of using 2 descripto=
rs at different derivation indices
for receive and change. [1]
2. The `/**` optimization for the common usecase of `/<0;1>` for point 1).
3. A new key expression `@i` referring to an index in a list of keys.
The first point was already discussed at great length [2]. Whether or not w=
e agree using the derivation path
for change detection is a sane thing to do, most signing devices need to su=
pport this to not break
compatibility. I think the advantage boils down to not make the user write =
two almost-similar descriptors on
its backup, since it doesn't necessarily help readibility for human verific=
ation.
I'm not so sure about the second point. Is another deviation from the stand=
ard worth it just for saving 3
characters?
Disgressing, if we are to have a carve-out in the descriptor language for t=
he common usecase of change/receive
keychains maybe your `/**` applies better than the proposed `/<NUM;NUM>` as=
the latter can open the door to
further carve-out requests.
For the third point, it does indeed seem unrealistic to check both the keys=
and the descriptor at the same
time. Even just because of the screen size (if the width an xpub is, what, =
3 times the width of your screen,
by the time you finished verifying it you have forgotten the descriptor con=
text in which this key was!). It
becomes harder as you get larger descriptors with Miniscript or Taproot, as=
you mentioned. Even the Miniscript
compiler at [3] supports key aliasing to workaround the inconvenience of lo=
ng keys.
However, why does it need to be a change to the descriptor language? It loo=
ks a lot like something that needs
to be handled at the application level with key aliasing. The flow would be=
first to register known keys, and
then when registering a descriptor the keys would be replaced by their alia=
ses for smoother verification. For
stateless devices, the registration of keys could use the same flow you des=
cribed for descriptors.
In the end it's just replacing the vector and indices with a mapping and la=
bel, which make it a *much* better
UX (checking aliases vs looking up indices in a vector). For instance:
Key registration:
Alice: xpub6FLhTbeNidZkyC729yW6K6a5zuDxKUL8Q6oZm4XG2ov9PdxAyyDNEUm3=
jet8ENnvYsy6nCgsofN6FeVxakLDTdWGoxtmoYcu2exhqh9HjtV
Bob: xpub6CoUua86qHYdDmnQL7imGN3zUMpVjRT4uDtRxYvfFj2v8JRvsaaGtf9ggv=
9NiL8sx3rFh6po92WBChwb37gDGuuU2Qo7zi3ZKC9cLjAsdQw
Notary: xpub6DjUwtKmK7uqsd5p9w3eoJ4cjuML51nW85BTWuBaHEoxfmDGD3uPf6Z=
ghsVeyuZUSuYEL4ajkVrfXzmotHHPtf6oBNYUQDSSBD4zUEiDoap
Descriptor registration (policy language for simpl.):
tr(NUMS,{
multi(2,Alice,Bob),
and(older(52560),and(Notary,Alice)),
and(older(52560),and(Notary,Bob))
})
In conclusion, if we were to have an optimization in the descriptor languag=
e for the common receive/change
usecase, i don't think you need another "wallet policy language" than the e=
xisting output descriptors language
with key aliasing/registration?
Unrelated question, since you mentioned `musig2` descriptors in this contex=
t. I thought Musig2 wasn't really
feasible for hardware signing devices, especially stateless ones. Do you th=
ink/know whether it is actually
possible for a HW to take part in a Musig2?
Thanks,
Antoine
[0] https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki
[1] https://github.com/bitcoin/bitcoin/pull/22838
[2] https://github.com/bitcoin/bitcoin/issues/17190
[3] https://bitcoin.sipa.be/miniscript/
------- Original Message -------
Le jeudi 5 mai 2022 =C3=A0 4:32 PM, Salvatore Ingala via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org> a =C3=A9crit :
> In the implementation work to implement descriptors and miniscript suppor=
t in hardware wallets [a][b], I encountered a number of challenges. Some of=
them are technical in nature (e.g. due to constraints of embedded developm=
ent). Others are related to the attempts of shaping a good user experience;=
with bitcoin reaching more people who are not tech-savvy, self-custody is =
only as secure as what those newcomers can use easily enough.
>
> The main tool that I am using to address some of these challenges is a la=
yer that sits _on top_ of descriptors/miniscript, while staying very close =
to it. Since there is nothing that is vendor-specific in the vast majority =
of the approach I'm currently using, I tried to distill it here for your co=
mments, and will propose a BIP if this is deemed valuable.
>
> I called the language "wallet policies" (suggestions for a better name ar=
e welcome). I believe an approach based on wallet policies can benefit all =
hardware wallets (stateless or not) that want to securely support complex s=
cripts; moreover, wallet policies are close enough to descriptors that thei=
r integration should be extremely easy for any software wallet that is curr=
ently using descriptors.
>
> [a]: https://blog.ledger.com/bitcoin-2 - early demo[b]: https://blog.ledg=
er.com/miniscript-is-coming - miniscript example
>
> Salvatore Ingala
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>
> This document starts with a discussion on the motivation for wallet polic=
ies, followed by their formal definition, and some recommendations for impl=
ementations.
> =3D=3D Rationale =3D=3D
> Output script descriptors [1] were introduced in bitcoin-core as a way to=
represent collections of output scripts. It is a very general and flexible=
language, designed to catch all the possible use-cases of bitcoin wallets =
(that is, if you know the script and you have the necessary keys, it will b=
e possible to sign transactions with bitcoin-core's descriptor-based wallet=
s).
>
> Unfortunately, descriptors are not a perfect match for the typical usage =
of hardware wallets. Most hardware wallets have the following limitations c=
ompared to a general-purpose machine running bitcoin-core:
>
> - they are embedded devices with limited RAM and computational power;
> - they might not be able to import additional private keys (all the keys =
are generated from a single seed via [BIP-32](https://github.com/bitcoin/bi=
ps/blob/master/bip-0032.mediawiki));
> - they might not have permanent storage (*stateless* hardware wallet desi=
gn).
>
> Moreover, other limitations like the limited size of the screen might aff=
ect what design choices are available in practice. Therefore, minimizing th=
e size of the information shown on-screen is important for a good user expe=
rience.
>
> A more native, compact representation of the wallet receive/change would =
also benefit the UX of software wallets using descriptors to represent soft=
ware wallets using descriptors/miniscript for multisignature or other compl=
ex locking conditions.
>
> =3D=3D=3D Security and UX concerns of scripts in hardware wallets =3D=3D=
=3D
> For a hardware wallet, allowing the usage of complex scripts presents cha=
llenges in terms of both security and user experience.
>
> =3D=3D=3D=3D Security issues =3D=3D=3D=3D
> One of the security properties that hardware wallets strive to guarantee =
is the following: **as long as the user correctly verifies the information =
that is shown on the hardware wallet's screen before approving, no action c=
an be performed without the user's consent**.
> This must hold even in scenarios where the attacker has full control of t=
he machine that is connected to the hardware wallet, and can execute arbitr=
ary requests or tamper with the legitimate user's requests.
>
> Therefore, it is not at all trivial to allow complex scripts, especially =
if they contain keys that belong to third parties.
> The hardware wallet must guarantee that the user knows precisely *what* "=
policy" is being used to spend the funds, and that the "unspent" funds (if =
any) will be protected by the same policy. This makes it impossible for an =
attacker to surreptitiously modify the policy, therefore stealing or burnin=
g user's funds.
>
> =3D=3D=3D=3D UX issues =3D=3D=3D=3D
> With miniscript (and taproot trees) allowing substantially more complex s=
pending policies to be used, it becomes more challenging to make sure that =
the user is able _in practice_ to verify the information on the screen. The=
refore, there are two fundamental design goals to strive for:
> - Minimize the amount of information that is shown on screen - so that th=
e user can actually validate it.
> - Minimize the number of times the user has to validate such information.
>
> Designing a secure protocol for the coordination of a descriptor wallet a=
mong distant parties is also a challenging problem that is out of scope in =
this document. See BIP-129 [2] for an approach designed for multisignature =
wallets.
>
> =3D=3D=3D Policy registration as a solution =3D=3D=3D
> A solution to address the security concerns, and part of the UX concerns,=
is to have a *registration* flow for the wallet policy in the hardware wal=
let. The "wallet policy" must contain enough information to generate all th=
e relevant addresses/scripts, and for the hardware wallet to identify the k=
eys that it controls and that are needed to spend the funds sent to those a=
ddresses.
>
> Before a new policy is used for the first time, the user will register a =
`wallet policy` into the hardware wallet. While the details of the process =
are out of scope in this document, the flow should be something similar to =
the following:
>
> 1) The software wallet initiates a _wallet policy registration_ on the ha=
rdware wallet; the information should include the wallet policy, but also a=
unique *name* that identifies the policy.
> 2) The hardware wallet shows the wallet policy to the user using the secu=
re screen.
> 3) After inspecting the policy and comparing it with a trusted source (fo=
r example a printed backup), the user approves the policy.
> 4) If stateful, the hardware wallet persists the policy in its permanent =
memory; if stateless, it returns a "proof of registration".
>
> The details of how to create a proof of registration are out of scope for=
this document; using a *message authentication codes* on a hash committing=
to the wallet policy, its name and any additional metadata is an effective=
solution if correctly executed.
>
> Once a policy is registered, the hardware wallet can perform the usual op=
erations securely:
> - generating receive and change addresses;
> - showing addresses on the secure screen;
> - sign transactions spending from a wallet, while correctly identifying c=
hange addresses and computing the transaction fees.
>
> Before any of the actions mentioned above, the hardware wallet will retri=
eve the policy from its permanent storage if stateful; if stateless it will=
validate the _proof of registration_ before using the wallet policy provid=
ed by the client.
> Once the previously registered policy is correctly identified and approve=
d by the user (for example by its name), and *as long as the policy registr=
ation was executed securely*, hardware wallets can provide a user experienc=
e similar to the usual one for single-signature transactions.
>
> =3D=3D=3D Avoiding blowup in descriptor size =3D=3D=3D
> While reusing a pubkey in different branches of a miniscript is explicitl=
y forbidden by miniscript (as it has certain negative security implications=
), it is still reasonable to reuse the same *xpub* in multiple places, albe=
it with different final steps of derivation (so that the actual pubkeys tha=
t are used in the script are indeed different).
>
> For example, using Taproot, a *3*-of-*5* multisignature wallet could use:
> - a key path with a 5-of-5 MuSig
> - a script tree with a tree of 10 different 3-of-3 MuSig2 scripts, that a=
re generated, plus a leaf with a fallback *3*-of-*5* multisignature using p=
lain multisignature (with `OP_CHECKSIGADD`).
>
> This could look similar to:
>
> ```
> tr(musig2(xpubA,xpubB,xpubC,xpubD,xpubE)/<0;1>/*), {
> {
> {
> pk(musig2(xpubA,xpubB,xpubC)/<2;3>/*),
> {
> pk(musig2(xpubA,xpubB,xpubD)/<4;5>/*)
> pk(musig2(xpubA,xpubB,xpubE)/<6;7>/*),
> }
> },
> {
> pk(musig2(xpubA,xpubC,xpubD)/<8;9>/*),
> {
> pk(musig2(xpubA,xpubC,xpubE)/<10;11>/*),
> pk(musig2(xpubA,xpubD,xpubE)/<12;13>/*)
> }
> }
> },
> {
> {
> pk(musig2(xpubB,xpubC,xpubD)/<14;15>/*),
> pk(musig2(xpubB,xpubC,xpubE)/<16;17>/*)
> },
> {
> pk(musig2(xpubB,xpubD,xpubE)/<18;19>/*),
> {
> pk(musig2(xpubC,xpubD,xpubE)/<20;21>/*),
> sortedmulti_a(3,
> xpubA/<22;23>/*,
> xpubB/<22;23>/*,
> xpubC/<22;23>/*,
> xpubD/<22;23>/*,
> xpubE/<22;23>/*)
> }
> }
> }
> })
> ```
>
> Note that each root xpub appears 8 times. With xpubs being up to 118 byte=
s long, the length of the full descriptor can get extremely long (the probl=
em gets *exponentially* worse with larger multisignature schemes).
>
> Replacing the common part of the key with a short key placeholder and mov=
ing the key expression separately helps to keep the size of the wallet poli=
cy small, which is crucial to allow human inspection in the registration fl=
ow.
>
> =3D=3D=3D Restrictions on the supported descriptors =3D=3D=3D=3D
>
> The policy language proposed in this document purposely targets only a st=
ricter subset of the output descriptors language, and it attempts to genera=
lize in the most natural way the approach that is already used for single-s=
ignature *accounts* (as described in BIP-44 [3], BIP-49 [4], BIP-84 [5], or=
BIP-86 [6]), or in multisignature setups (see for example BIP-48 [7] and B=
IP-87 [8]).
> Unlike the BIPs mentioned above, it is not tied to any specific script te=
mplate, as it applies to arbitrary scripts that can be represented with des=
criptors and miniscript.
>
> Supporting only a reduced feature set when compared to output descriptors=
helps in implementations (especially on hardware wallets), while attemptin=
g to capture all the common use cases. More features can be added in the fu=
ture if motivated by real world necessity.
>
> By keeping the structure of the wallet policy language very close to that=
of descriptors, it should be straightforward to:
> - write wallet policy parsers;
> - extract the descriptors defined by a wallet policy;
> - convert a pair of descriptors describing a wallet "account" used in cur=
rent implementations into the corresponding wallet policy.
>
>
> =3D=3D Wallet policies =3D=3D
> This section formally defines wallet policies, and how they relate to out=
put script descriptors.
> =3D=3D=3D Formal definition =3D=3D=3D
> A wallet policy is composed by a wallet descriptor template, together wit=
h a vector of key information items.
>
> =3D=3D=3D=3D Wallet descriptor template =3D=3D=3D=3D
>
> A wallet descriptor template is a `SCRIPT` expression.
>
> `SCRIPT` expressions:
> - `sh(SCRIPT)` (top level only): P2SH embed the argument.
> - `wsh(SCRIPT)` (top level or inside `sh` only): P2WSH embed the argument=
.
> - `pkh(KP)` (not inside `tr`): P2PKH output for the given public key (use=
`addr` if you only know the pubkey hash).
> - `wpkh(KP)` (top level or inside `sh` only): P2WPKH output for the given=
compressed pubkey.
> - `multi(k,KP_1,KP_2,...,KP_n)`: k-of-n multisig script.
> - `sortedmulti(k,KP_1,KP_2,...,KP_n)`: k-of-n multisig script with keys s=
orted lexicographically in the resulting script.
> - `tr(KP)` or `tr(KP,TREE)` (top level only): P2TR output with the specif=
ied key as internal key, and optionally a tree of script paths.- any valid =
miniscript template (inside `wsh` or `tr` only).
> `TREE` expressions:
> - any `SCRIPT` expression
> - An open brace `{`, a `TREE` expression, a comma `,`, a `TREE` expressio=
n, and a closing brace `}`
>
> Note: "miniscript templates" are not formally defined in this version of =
the document, but it is straightforward to adapt this approach.
>
> `KP` expressions (key placeholders) consist of
> - a single character `@`
> - followed by a non-negative decimal number, with no leading zeros (excep=
t for `@0`).
> - possibly followed by either:
> - the string `/**`, or
> - a string of the form `/<NUM;NUM>/*`, for two distinct decimal numbers `=
NUM` representing unhardened derivations
>
> The `/**` in the placeholder template represents commonly used paths for =
receive/change addresses, and is equivalent to `<0;1>`.
>
> The placeholder `@i` for some number *i* represents the *i*-th key in the=
vector of key origin information (which must be of size at least *i* + 1, =
or the wallet policy is invalid).
>
> =3D=3D=3D=3D Key informations vector =3D=3D=3D=3D
>
> Each element of the key origin information vector is a `KEY` expression.
>
> - Optionally, key origin information, consisting of:
> - An open bracket `[`
> - Exactly 8 hex characters for the fingerprint of the master key from whi=
ch this key is derived from (see [BIP32](https://github.com/bitcoin/bips/bl=
ob/master/bip-0032.mediawiki) for details)
> - Followed by zero or more `/NUM'` path elements to indicate hardened der=
ivation steps between the fingerprint and the xpub that follows
> - A closing bracket `]`
> - Followed by the actual key, which is either
> - a hex-encoded pubkey, which is either
> - inside `wpkh` and `wsh`, only compressed public keys are permitted (exa=
ctly 66 hex characters starting with `02` or `03`.
> - inside `tr`, x-only pubkeys are also permitted (exactly 64 hex characte=
rs).
> - a serialized extended public key (`xpub`) (as defined in [BIP 32](https=
://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki))
>
> The placeholder `@i` for some number *i* represents the *i*-th key in the=
vector of key orIgin information (which must be of size at least *i* + 1, =
or the wallet policy is invalid).
>
> The policy template is invalid if any placeholder `@i` has derivation ste=
ps while the corresponding `(i+1)`-th element of the keys vector is not an =
xpub.
>
> =3D=3D=3D=3D Additional rules =3D=3D=3D=3D
> The wallet policy is invalid if any placeholder expression with additiona=
l derivation steps is used when the corresponding key information is not an=
xpub.
>
> The key information vector *should* be ordered so that placeholder `@i` n=
ever appear for the first time before an occurrence of `@j` for some `j < i=
`; for example, the first placeholder is always `@0`, the next one is `@1`,=
etc.
>
> =3D=3D=3D Descriptor derivation =3D=3D=3D
> From a wallet descriptor template (and the associated vector of key infor=
mations), one can therefore obtain the 1-dimensional descriptor for receive=
and change addresses by:
>
> - replacing each key placeholder with the corresponding key origin inform=
ation;
> - replacing every `/**` with `/0/*` for the receive descriptor, and `/1/*=
` for the change descriptor;
> - replacing every `/<M,N>` with `/M` for the receive descriptor, and `/N`=
for the change descriptor.
>
> For example, the wallet descriptor `pkh(@0/**)` with key information `["[=
d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhg=
bmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL"]` produces the fol=
lowing two descriptors:
>
> - Receive descriptor: `pkh([d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcx=
d75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJv=
LJuZZvRcEL/0/*)`
>
> - Change descriptor: `pkh([d34db33f/44'/0'/0']xpub6ERApfZwUNrhLCkDtcHTcxd=
75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvL=
JuZZvRcEL/1/*)`
>
> =3D=3D=3D Implementation guidelines =3D=3D=3D
> Implementations must not necessarily implement all of the possible wallet=
policies defined by this standard, but it is recommended to clearly docume=
nt any limitation.
>
> Implementations can add additional metadata that is stored together with =
the wallet policy for the purpose of wallet policy registration and later u=
sage. Metadata can be vendor-specific and is out of the scope of this docum=
ent.
>
> Any implementation in a general-purpose software wallet allowing arbitrar=
y scripts (or any scripts that involve external cosigners) should put great=
care into a process for backing up a wallet policy. In fact, unlike typica=
l single-signature scenarios, the seed alone is no longer enough to discove=
r wallet policies with existing funds, and the loss of the backup is likely=
to lead to permanent loss of funds.
>
> Avoiding key reuse among different wallet accounts is also extremely impo=
rtant, but out of scope for this document.
>
> =3D=3D Examples =3D=3D
>
> Some examples of wallet descriptor templates (vectors of keys omitted for=
simplicity):- Template for a native segwit account:wpkh(@0/**)
> - Template for a taproot BIP86 account:tr(@0/**)
> - Template for a native segwit 2-of-3:wsh(sortedmulti(2,@0/**,@1/**,@2/**=
))- Template with miniscript for "1 of 2 equally likely keys":wsh(or_b(pk(@=
0/**),s:pk(@1/**)))
> More examples (esp. targeting miniscript on taproot) will be added in the=
future.
> =3D=3D References =3D=3D
>
> * [1] - Output Script Descriptors: https://github.com/bitcoin/bitcoin/blo=
b/master/doc/descriptors.md* [2] - BIP-129 (Bitcoin Secure Multisig Setup):=
https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki
> * [3] - BIP-44: https://github.com/bitcoin/bips/blob/master/bip-0044.medi=
awiki* [4] - BIP-49: https://github.com/bitcoin/bips/blob/master/bip-0049.m=
ediawiki* [5] - BIP-84: https://github.com/bitcoin/bips/blob/master/bip-008=
4.mediawiki* [6] - BIP-86: https://github.com/bitcoin/bips/blob/master/bip-=
0086.mediawiki* [7] - BIP-48: https://github.com/bitcoin/bips/blob/master/b=
ip-0048.mediawiki* [8] - BIP-87: https://github.com/bitcoin/bips/blob/maste=
r/bip-0087.mediawiki
|