From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6E84DC002D for ; Tue, 10 May 2022 09:37:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 4E27381767 for ; Tue, 10 May 2022 09:37:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DaMTousGtkwP for ; Tue, 10 May 2022 09:37:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0E01681469 for ; Tue, 10 May 2022 09:37:37 +0000 (UTC) Received: by mail-pf1-x433.google.com with SMTP id x23so14462644pff.9 for ; Tue, 10 May 2022 02:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HrDnnVqQH5NrWIdd6fniaDxmkjeztukaAo3Qaw9GwCs=; b=jT5oELCgjmompnac+HRIqmk5IhRd4d7+Uv7NEca6/76tqswJKq0+hoCd+CAb5XOgP9 tYh1SI/Tl2S3PzRFxbiHmYXz2kA1rN0kqPkeslihMlIWUOL5WwBMV3Vcd/XL3rBjxXKI TZ73UmplaEweG0jOXYBq5AAcm5A+IYt5LwyhHJm8kVJaodEfd36pDZVSlvkj+HBVCjw4 TpWVTu4+waDJaEgmmoXjqBFSszxaIESDLgXs6gBv4cYKkuIiPELOXZxdo01+77Xx11Sa P40f4Ct3MFjnwdTk1u3RsMjtOnn9MAr9I1VBdRylAlzKbDrVXqOKr8eT7Le1BTrK/HQz AQOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HrDnnVqQH5NrWIdd6fniaDxmkjeztukaAo3Qaw9GwCs=; b=Mtrhegidz2eKEwl94l70VZ4nxfCoHBr6XnDNZkq38jHydtJdGcaDAtQDePhSLoWh6j PfLUVeEX1cJgRUp1OmLDMlFX3Un6ImkkvUBEy9H4shm9KQWUmmTKolS0NF4sMRoDt4Er u2jMwTe0AG5Nluc5vIb7Dsx1pu2GMbxC+lna5vazjwjAlL2wqX/SN6FCt8Wmu50nLWKB 6jLU9ECSSu+zJPwLzcWYxEzmXzsEG9InMWqdhmIcNfIwtO/0abKFNHLRq9wYroarWOcr BJzk2FOs11+aV+at5zo+JMSKyX3uUthYTlbRElkffmfhLeXXGgqtF2HQfJ+xUvW76CC5 IjXw== X-Gm-Message-State: AOAM533uHTYIA4Au0Mj5POIXoPbEsJmlbrS87XBDC6iaJpwMDpl3e6PR 55Ap/D/7piqDYKL4eb4Du4ACBVP9+HgFAo65pxg= X-Google-Smtp-Source: ABdhPJwprQVnMGVEXRzXdp9YP8FIsPYF+ISiYGPQ6+tJROEinY9mdOutuOuVREoPl6jERA/s6HMeuO+718dUxkA4ODs= X-Received: by 2002:a05:6a00:14d4:b0:50e:12c8:4868 with SMTP id w20-20020a056a0014d400b0050e12c84868mr19606004pfu.72.1652175457290; Tue, 10 May 2022 02:37:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Salvatore Ingala Date: Tue, 10 May 2022 11:37:26 +0200 Message-ID: To: darosior Content-Type: multipart/alternative; boundary="0000000000003d0ea205dea51337" X-Mailman-Approved-At: Tue, 10 May 2022 09:43:49 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2022 09:37:39 -0000 --0000000000003d0ea205dea51337 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine and Billy, Thank you for your comments and for looking into the proposal. On Mon, 9 May 2022 at 12:36, darosior wrote: > 1. The `` optimization for the common usecase of using 2 > descriptors at different derivation indices > for receive and change. [1] > 2. The `/**` optimization for the common usecase of `/<0;1>` for point 1)= . > > [...] > > I'm not so sure about the second point. Is another deviation from the > standard worth it just for saving 3 > characters? > I agree with the concerns of both you and Billy on the `\**` syntax, and it is certainly not a crucial part of the proposal, as it is arguably redundant once `\<0;1>` is available. I have been using it since before the `\<0;1>` syntax was proposed (afaik), and I thought I would leave it mostly for the sake of optimizing the UX in the most common use cases. I think that sh(sortedmulti(2,@0/**,@1/**,@2/**)) is quite a lot more readable (especially on a small screen) than sh(sortedmulti(2,@0/<0;1>/*,@1/<0;1>/*,@2/<0;1>/*)) Apart from the additional 5 characters *per placeholder*, there are a lot more numbers to parse for the user. Yet, I'm not too attached to the feature as it is probably not very useful in taptrees. For the future, I expect further improvements will come from the hardware wallets analyzing the wallet policy and recognizing the commonly used patterns. No reason to show the full taptree of a complex 3-of-5 multisig setup =E2=88=92 you can just say "Taproot 3-of-5 multisig".= Show the full taptree policy should be reserved for the 1% of advanced use-cases that are not in the catalogue. Slightly off-topic, but my impression is that descriptors are outgrowing their original scope (probably the reason for sipa's comments[1] on the early proposals for multiple derivation paths in one descriptor). I think there is a case to be made for keeping the language of descriptors limited to represent either (1) a single output, or (2) a list of outputs with the `/*` syntax; in this interpretation, the `/` syntax would entirely be on a separate layer (the `combo` descriptor[2] would also be extraneous in this interpretation). I tried to design the policy wallet language in a way that is agnostic to these details of descriptor specs (since I target a _subset_ of descriptors, it will work either way). However, why does it need to be a change to the descriptor language? It > looks a lot like something that needs > to be handled at the application level with key aliasing. Key aliasing is not part of descriptors; therefore, "descriptors with key aliasing" are still a language on top of descriptors. Adding key aliases will indeed be a great UX improvement, but in my opinion it is better built on top of wallet policies, rather than within the language itself. Note that by separating the *wallet descriptor template* from the keys themselves, such a feature is already facilitated. Moreover, wallet policies separate the KEY expressions of descriptors into two semantically relevant parts: only the xpub and its origin info goes into the "vector of key information", while the receive/change part of the derivation is kept in the placeholder (therefore in the descriptor template). Adding restrictions is also useful: `xpub/1/2/3/4/<0;1>/5/6/*` might be valid miniscript, but supporting this kind of thing would be (arguably) unreasonable and a lot more complicated for hardware wallets; therefore, placeholders and key informations are a lot more limited in the wallet policy language than their miniscript counterpart. While I understand that descriptors are designed with a maximum flexibility mindset, a minimized feature set is very valuable for hardware wallets, and I believe it can be done with little to no practical loss of use cases. Restrictions can be lifted in future versions when the need arises. I think to better suit the needs of both hardware and software wallets, you need both the *extensions* and the *restrictions*. That's why I propose to keep them separated, rather than suggesting changes to descriptors. Unrelated question, since you mentioned `musig2` descriptors in this > context. I thought Musig2 wasn't really > feasible for hardware signing devices, especially stateless ones. Do you > think/know whether it is actually > possible for a HW to take part in a Musig2? > I certainly have some more homework to do on musig2, and for this proposal I was only concerned with making sure the wallet policy language won't break with future upgrades to descriptors. Yet, as far as I understand , the complications for hardware wallets are (1) possible lack of good quality randomness, and (2) need to keep state during a signing session. Ledger signers have a hardware TRNG, and while the design is generally stateless, there is flash memory that can be used to store the secret nonce during a signing session (or, more likely, a few parallel signing sessions). Therefore, I don't think there are technical blockers for musig2. Salvatore [1] https://github.com/bitcoin/bitcoin/issues/17190#issuecomment-543845642 [2] https://github.com/bitcoin/bips/blob/master/bip-0384.mediawiki --0000000000003d0ea205dea51337 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine and Billy,

= Thank you for your comments and for looking into the proposal.
On Mon, 9 May 2022 at 12:36, darosior <darosior@protonmail.com> wr= ote:
1. The `<NUM;NUM>` optimization for the common = usecase of using 2 descriptors at different derivation indices
=C2=A0 =C2=A0for receive and change. [1]
2. The `/**` optimization for the common usecase of `/<0;1>` for poin= t 1).

[...]

I'm not so sure about the second point. Is another deviation from the s= tandard worth it just for saving 3
characters?

I agree with the concerns of both you = and Billy on the `\**` syntax, and it is certainly not a crucial=C2=A0part = of the proposal, as it is arguably redundant once `\<0;1>` is availab= le.
I have been using it since before the `\<0;1>` syntax w= as proposed (afaik), and I thought I would leave it mostly for the sake of = optimizing the UX in the most common use cases. I think that

<= div>=C2=A0 =C2=A0 sh(sortedmulti(2,@0/**,@1/**,@2/**))

=
is quite a lot more readable (especially on a small screen) than
=C2=A0 =C2=A0 sh(sortedmulti(2,@0/<0;1>/*,@1/<0;1>= /*,@2/<0;1>/*))

Apart from the additional 5 characters per = placeholder, there are a lot more numbers to parse for the user.
<= div>
Yet, I'm not too attached to the feature as it is pr= obably not very useful in taptrees. For the future, I expect further improv= ements will come from the hardware wallets analyzing the wallet policy and = recognizing the commonly used patterns. No reason to show the full taptree = of a complex 3-of-5 multisig setup =E2=88=92 you can just say "Taproot= 3-of-5 multisig". Show the full taptree policy should be reserved for= the 1% of advanced use-cases that are not in the catalogue.

=
Slightly off-topic, but my impression is that descriptors a= re outgrowing their original scope (probably the reason for sipa's comm= ents[1] on the early proposals for multiple derivation paths in one descrip= tor).
I think there is a case to be made for keeping the lang= uage of descriptors limited to represent either (1) a single output, or (2)= a list of outputs with the `/*` syntax; in this interpretation, the `/<= m;n>` syntax would entirely be on a separate layer (the `combo` descript= or[2] would also be extraneous in this interpretation).=C2=A0
I t= ried to design the policy wallet language in a way that is agnostic to thes= e details of descriptor specs (since I target a _subset_ of descriptors, it= will work either way).

However, why does it need to be a change to the de= scriptor language? It looks a lot like something that needs
to be handled at the application level with key aliasing.
=
Key aliasing is not part of descriptors; therefore, "descriptors w= ith key aliasing" are still a language on top of descriptors.

Adding key aliases will indeed be a great UX improvement, = but in my opinion it is better built on top of wallet policies, rather than= within the language=C2=A0itself.
Note that by separating the wallet = descriptor template=C2=A0from the keys themselves, such a feature is al= ready facilitated. Moreover, wallet policies separate the KEY expressions o= f descriptors into two semantically relevant parts: only the xpub and its o= rigin info goes into the "vector of key information", while the= =C2=A0receive/change part of the derivation is kept in the placeholder (the= refore in the descriptor template). Adding restrictions is also useful: `xp= ub/1/2/3/4/<0;1>/5/6/*` might be valid miniscript, but supporting thi= s kind of thing would be (arguably) unreasonable and a lot more complicated= for hardware wallets; therefore, placeholders and key informations are a l= ot more limited in the wallet policy language than their miniscript counter= part.

While I understand that descriptors are desi= gned with a maximum flexibility mindset, a minimized feature set is very va= luable for hardware wallets, and I believe it can be done with little to no= practical loss of use cases. Restrictions can be lifted in future versions= when the need arises.

I think to better suit=C2= =A0the needs of both hardware and software wallets, you need both the ex= tensions=C2=A0and the restrictions. That's why I propose to = keep them separated, rather than suggesting changes to descriptors.

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?

I cert= ainly have some more homework to do on musig2, and for this proposal I was = only concerned with making sure the wallet policy language won't break = with future upgrades to descriptors.
Yet, as far as I understand = ,=C2=A0the complications for hardware wallets are (1) possible lack of good= quality randomness, and (2) need to keep state during a signing session. L= edger signers have a hardware TRNG, and while the design is generally state= less, there is flash memory that can be used to store the secret nonce duri= ng a signing session (or, more likely, a few parallel signing sessions). Th= erefore, I don't think there are technical blockers for musig2.

= Salvatore


--0000000000003d0ea205dea51337--