From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8E97EC0032 for ; Sun, 10 Sep 2023 17:13:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id D6C4181604 for ; Sun, 10 Sep 2023 17:13:30 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D6C4181604 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=lnp-bp.org header.i=@lnp-bp.org header.a=rsa-sha256 header.s=protonmail3 header.b=G8N+A7UZ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWSvssQabTqM for ; Sun, 10 Sep 2023 17:13:28 +0000 (UTC) Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21]) by smtp1.osuosl.org (Postfix) with ESMTPS id F33DE81585 for ; Sun, 10 Sep 2023 17:13:27 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F33DE81585 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lnp-bp.org; s=protonmail3; t=1694365996; x=1694625196; bh=HGMDBop02FK5ZHK3W0EgwK4kOVtQuWB+h7hxuL5dbmU=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=G8N+A7UZ/dZk6Zul5MPDymIcFEFuSw3V9Oc2Gt7ai/f7TVY1jiMP7JWwI9px68Lov nCd4IrD8gOFwUfCIEpmd8GrePbcv82TvdldTNp5mlDaedqMsREq0cPBqVlG/p6qRvE juDraxNbhPTXp2qgD5GFaLZSKFiCwJ84eLY926dq+1Q6ngoEs1Q3kv2xdCHPmnN/wt qUR4cPDPEdTNXUCPIlzKOCBKHgReUlTb1R4rFU6MtY1xPU1NHaTrIDiNe+oXQK4ZmY EsyOrzUtlnbGFA5B8k6+JcFKeVUQ2+fD/iwJFYoz/F3K+ZjXvV6xX4ZzASFm1e8h46 ro0qgNInhRhtQ== Date: Sun, 10 Sep 2023 17:13:02 +0000 To: Bitcoin Protocol Discussion From: Dr Maxim Orlovsky Message-ID: <4zh22wKfn7dGB-ZolHCLixP4gv_-gsdkfndbDxdoE7K7yyO-LDMvxZk1UVpp0YTGSRCqGtYlMitSQ5aLP9bIa2wj5Ul38Rw-DmagwxRdWhc=@lnp-bp.org> Feedback-ID: 18134079:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 10 Sep 2023 17:37:36 +0000 Subject: [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: Sun, 10 Sep 2023 17:13:31 -0000 Hi, Script output descriptors ("output descriptors", "wallet descriptors", or= =20 simply "descriptors") are getting more and more traction. Descriptors work= =20 in combination with miniscript, extended BIP32 keys (xpub/xprivs=20 "descriptors" equipped with origin and derivation information) and are used to construct new primitives like "wallet templates" used in Ledger and=20 BitBox today. Nevertheless, due to historical reasons, the resulting combination of the= =20 mentioned technologies is frequently redundant and leaves a lot of=20 unspecified caveats, when it is unclear how descriptor with=20 internally-conflicting data has to be handled by wallets and/or devices.=20 For instance, - derivation path standards (following BIP44) commit to the type of the=20 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= =20 information and information about Bitcoin network (testnet or mainnet); - if the same signer participates in different miniscript branches, due=20 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 new descriptor-level concepts, like taproot-ebmedded OP_RETURN commitments=20 (so-called "tapret"), which are not handled by existing standards. As a result, descriptors contain a lot of redundant information, which make= s them bulk, hard to read or type, and impossible to handle in the narrow UI of hardware wallets. At LNP/BP Standards Association we'd like to work/coordinate efforts on=20 a new BIP proposal removing all the issues above. Before working on the=20 BIP proposal text I would like to start by discussing an approach, seeking Concept (n)ACKs and Approach (n)ACKs from this mail list. The approach ------------ Existing separate BIP44 standards, committing to a specific form of script pubkey are made redundant with the introduction of output descriptors. Thus= , I think we need a new BIP44 purpose field which will be used with all=20 descriptor formats. The standard must _lexicographically require_ all keys= =20 to follow the same standard and use the same network and terminal derivatio= n format. By "lexicographically require" I mean that there must be no=20 syntactic option to do otherwise, i.e. the information must not repeat=20 within the descriptor for each of the keys and has to be placed in the=20 descriptor itself, using prefix (for the network) and suffix (for the=20 terminal derivation format): ``` wsh/test(or( and(1@[fe569a81//1']xpub1..., 2@[8871bad9//1h]xpub2..., 3@[beafcafe//1'= ]xpub3...),=20 and(older(1000), thresh(2, @1, @2, @3)) ))/<0;1>/* ``` Please note that each of the keys appears in the descriptor only once, and is aliased using the `i@` construction preceding the key origin. These aliases must be incremental starting from `1` (otherwise the descriptor is invalid). Each other time the same account xpub is used in some other condition only the alias should be used. For the mainnet the prefix must be omitted: `wsh(or...)/<0;1>/*` The descriptor is used to construct derivation for each of the keys=20 in the same way: `m/89'/network'/account'/branch/<0;1>/*` 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 prefix= ; - `account` is taken from the xpub origin in the descriptor (it follows the master fingerprint and `//` character) and the last `/<0;1>/*` must match the descriptor suffix. - `branch` part, which is a new segment compared to BIP44. This branch inde= x must be always unhardened and is computed from the descriptor, starting= =20 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=20 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. Reference implementation ------------------------ Once the approach is acknowledged by the mailing list the reference=20 implementation will be written on Rust and deployed with MyCitadel wallet= =20 (https://mycitadel.io), which is the only wallet supporting since spring 2022 combination of all three: descriptors, miniscript and taproot (there= =20 are more descriptor/miniscript wallets which have appeared over the last=20 year, but they are still lacking taproot support AFAIK). Kind regards, Maxim Orlovsky LNP/BP Standards Association https://www.lnp-bp.org/ GitHub: @dr-orlovsky Nostr: npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym