path: root/6e/0119f06381c6b0d34e9f16a5d8fc70715ac595

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