Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6535AC0032 for ; 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 ; 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 ; 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 ; 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 From: Antoine Poinsot 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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