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
|
Return-Path: <darosior@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6535AC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Sep 2023 12:04:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 326BD40CC9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Sep 2023 12:04:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 326BD40CC9
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=rJW9Cfkx
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
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ClLPdfiqQX0Q
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Sep 2023 12:04:17 +0000 (UTC)
Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch
[185.70.41.104])
by smtp2.osuosl.org (Postfix) with ESMTPS id CBC1E40CBD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Sep 2023 12:04:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org CBC1E40CBD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1694433843; x=1694693043;
bh=OCeLAL9zsJCntSnRIi/RuAfL44FADqb38JOl8ks1L50=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=rJW9CfkxYxM52jgI78uA27eTltaxNJsVpMkkZO5lS9xYZrDMt5EcBTdBY2arrdGS3
1riKdpQmwqfnxmzFxSjYEraaFxg7oB9y+1x+46t0lYWbmWdtaQIF3jHhkKbY3lCIgL
uAxDmtbYQ5V0bmS1GZx8eAL8vXBoAiHfPVpYABVy+69pSBvVuB1ZsdmqtjPfIXr8uh
+2QCuao7IyLgX7r5bM/QX7iM4UXAgFxn4wk3hRlGXIFUU4xEMrwzi2h7qHQyWbWXfe
2VB9yCymoBIZbLwa0vo50kSW06FVMvjxc89+G+wcSotbRFY0hwFGljruFCdwpqk2Jb
OiYxUwSvC+vAQ==
Date: Mon, 11 Sep 2023 12:03:59 +0000
To: Dr Maxim Orlovsky <orlovsky@lnp-bp.org>
From: Antoine Poinsot <darosior@protonmail.com>
Message-ID: <2rp3BsP6bOyUTJeJhdylDfUGyBV2SCBSsiVsK0nNSH3Nky3yYXGeLN_TbwTeaNTVAv5E_DIgbGI83rVVG7jwSBOMAzM3P226xydeIaSn9i8=@protonmail.com>
In-Reply-To: <4zh22wKfn7dGB-ZolHCLixP4gv_-gsdkfndbDxdoE7K7yyO-LDMvxZk1UVpp0YTGSRCqGtYlMitSQ5aLP9bIa2wj5Ul38Rw-DmagwxRdWhc=@lnp-bp.org>
References: <4zh22wKfn7dGB-ZolHCLixP4gv_-gsdkfndbDxdoE7K7yyO-LDMvxZk1UVpp0YTGSRCqGtYlMitSQ5aLP9bIa2wj5Ul38Rw-DmagwxRdWhc=@lnp-bp.org>
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, 11 Sep 2023 12:58:33 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP to align descriptors,
xpub derivation and miniscript
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, 11 Sep 2023 12:04:18 -0000
Maxim,
That does not sound compelling. Let's go through your points.
First you point how some wallets supporting descriptors keep vague BIP44 co=
mpatibility. There are multiple reasons for this, but first you say that th=
e derivation path "commits to" (i think you mean describe? that's rather wh=
at you want for a backup) output types such as P2WSH or P2TR. It's incorrec=
t. That's the whole point of descriptors. There are standardized paths for =
Taproot *keyspend* and weird multisig P2WSH templates. But you can't keep a=
n infinite list of BIP44 templates for all the scripts it's possible to use=
under those output types.
As for the reasons for keeping BIP44 compatibility in some wallets:
- It makes sense for some output types to keep compatibility with non-descr=
iptor wallets. For instance see how the Bitcoin Core wallet uses BIP86 for =
Taproot keyspend despite it being descriptor-based. [0]
- Some signing devices whitelist the paths you can extract an xpub from wit=
hout user confirmation. (It's the case of Ledger and the reason we have to =
resort to using legacy BIP48-derived paths in Liana.)
You then go to point out how it's useless to use legacy standards within de=
scriptors. Sure, but that doesn't call for one more unscalable legacy stand=
ard. Just don't use it if you can afford to? I'd even go for `m/network'/ac=
count'/<0;1>/*` (rather than your `m/89'/network'/account'/branch/<0;1>/*`)=
if Ledger would let us.
You third point is about how you can't reuse public keys across spending pa=
ths within a Miniscript. But it doesn't prevent you from reusing the same s=
igner, you can simply:
- Derive a different hardened xpub from the signing device for each occurre=
nce (cumbersome); or
- Query a single xpub from the device and then append an unhardened derivat=
ion step. To reduce the number of steps you can even reuse the multipath st=
ep. (`xpub/<0;1>/*` for the first appearance, then `xpub/<2;3>/*`, `xpub/<4=
;5>/*`, ...)
(Small correction passing by: you mention the Miniscript duplicate key chec=
k doesn't apply under Taproot context, but it absolutely does. I think you =
meant across Taproot branches, but keep in mind you can have multiple spend=
ing paths within a single leaf.)
Your final point is about how your client-side validation project introduce=
s some "descriptor-level concepts" which are not handled by current standar=
ds. If your new standard is incompatible with descriptors, fix it instead o=
f trying to convince all existing wallets to become aware of it?
Cheers,
Antoine
[0] The motivation section of BIP86 says it all. https://github.com/bitcoin=
/bips/blob/master/bip-0086.mediawiki#motivation
------- Original Message -------
On Sunday, September 10th, 2023 at 7:13 PM, Dr Maxim Orlovsky via bitcoin-d=
ev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi,
>=20
> Script output descriptors ("output descriptors", "wallet descriptors", or
> simply "descriptors") are getting more and more traction. Descriptors wor=
k
> in combination with miniscript, extended BIP32 keys (xpub/xprivs
> "descriptors" equipped with origin and derivation information) and are us=
ed
> to construct new primitives like "wallet templates" used in Ledger and
> BitBox today.
>=20
> Nevertheless, due to historical reasons, the resulting combination of the
> mentioned technologies is frequently redundant and leaves a lot of
> unspecified caveats, when it is unclear how descriptor with
> internally-conflicting data has to be handled by wallets and/or devices.
> For instance,
> - derivation path standards (following BIP44) commit to the type of the
> script pubkey (P2PKH, P2SH, P2WSH, P2WPKH, P2TR), but the same informatio=
n
> is present in the descriptor itself;
> - each of the public keys within the descriptor replicates the derivation
> information and information about Bitcoin network (testnet or mainnet);
> - if the same signer participates in different miniscript branches, due
> to miniscript anti-malleability rules a new derivation path has to be use=
d
> in pre-Taproot context (but not in Taproot) -=3D and multiple contradicto=
ry
> approaches exist on how to handle that;
> - client-side-validation approach, used by several projects, introduces n=
ew
> descriptor-level concepts, like taproot-ebmedded OP_RETURN commitments
> (so-called "tapret"), which are not handled by existing standards.
>=20
> As a result, descriptors contain a lot of redundant information, which ma=
kes
> them bulk, hard to read or type, and impossible to handle in the narrow U=
I
> of hardware wallets.
>=20
> At LNP/BP Standards Association we'd like to work/coordinate efforts on
> a new BIP proposal removing all the issues above. Before working on the
> BIP proposal text I would like to start by discussing an approach, seekin=
g
> Concept (n)ACKs and Approach (n)ACKs from this mail list.
>=20
>=20
> The approach
> ------------
>=20
> Existing separate BIP44 standards, committing to a specific form of scrip=
t
> pubkey are made redundant with the introduction of output descriptors. Th=
us,
> I think we need a new BIP44 purpose field which will be used with all
> descriptor formats. The standard must lexicographically require all keys
> to follow the same standard and use the same network and terminal derivat=
ion
> format. By "lexicographically require" I mean that there must be no
> syntactic option to do otherwise, i.e. the information must not repeat
> within the descriptor for each of the keys and has to be placed in the
> descriptor itself, using prefix (for the network) and suffix (for the
> terminal derivation format):
>=20
> ```
> wsh/test(or(
> and(1@[fe569a81//1']xpub1..., 2@[8871bad9//1h]xpub2..., 3@[beafcafe//1']x=
pub3...),
> and(older(1000), thresh(2, @1, @2, @3))
> ))/<0;1>/*
>=20
> ```
>=20
> Please note that each of the keys appears in the descriptor only once, an=
d
> is aliased using the `i@` construction preceding the key origin. These
> aliases must be incremental starting from `1` (otherwise the descriptor i=
s
> invalid). Each other time the same account xpub is used in some other
> condition only the alias should be used.
>=20
> For the mainnet the prefix must be omitted: `wsh(or...)/<0;1>/*`
>=20
>=20
> The descriptor is used to construct derivation for each of the keys
> in the same way:
>=20
> `m/89'/network'/account'/branch/<0;1>/*`
>=20
>=20
> where:
> - 89' is the purpose - an assumed number for the newly proposed BIP;
> - `network'` is either `0'` or `1'` and is taken from the descriptor pref=
ix;
> - `account` is taken from the xpub origin in the descriptor (it follows t=
he
> master fingerprint and `//` character) and the last `/<0;1>/*` must match
>=20
> the descriptor suffix.
> - `branch` part, which is a new segment compared to BIP44. This branch in=
dex
> must be always unhardened and is computed from the descriptor, starting
> with 0 for each key and incrementing each time the same key alias is foun=
d
> in the descriptor;
> - `<0;1>` may contain only 0, 1 index, unless a dedicated BIP extending
>=20
> the meaning of this segment is filed. One such case may be the use of
> a change index for storing an associated state in client-side-validation,
> like in RGB protocol, where indexes 9 and 10 are used to represent the
> assignation of an external state or the presence of a tapret commitment.
> It is important to require the standardization of new change indexes sinc=
e
> without that wallets unaware of clinet-side-validation may spend the UTXO
> and burn the external state.
>=20
>=20
> Reference implementation
> ------------------------
>=20
> Once the approach is acknowledged by the mailing list the reference
> implementation will be written on Rust and deployed with MyCitadel wallet
> (https://mycitadel.io), which is the only wallet supporting since spring
> 2022 combination of all three: descriptors, miniscript and taproot (there
> are more descriptor/miniscript wallets which have appeared over the last
> year, but they are still lacking taproot support AFAIK).
>=20
>=20
> Kind regards,
> Maxim Orlovsky
> LNP/BP Standards Association
> https://www.lnp-bp.org/
>=20
> GitHub: @dr-orlovsky
> Nostr: npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|