path: root/33/3f674299b9492b42f49aa35f847e14bf77564f

Return-Path: <salvatore.ingala@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6E84DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 09:37:37 +0000 (UTC)
Received: by mail-pf1-x433.google.com with SMTP id x23so14462644pff.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAMhCMoHfdsQMsVigFqPexTE_q-Cyg7pfRvORUoy2sZtvyzd1cg@mail.gmail.com>
 <osdF1jSCUyGyaLZ6YytSB7ub1MwdbaP6PMCYEJZXmMRaSs4vS7bs_SZTErxZh_K7oLYLAtAqqgl0Vcdl1ftAusM_1DHSDHtz1kSUzqnmwsk=@protonmail.com>
In-Reply-To: <osdF1jSCUyGyaLZ6YytSB7ub1MwdbaP6PMCYEJZXmMRaSs4vS7bs_SZTErxZh_K7oLYLAtAqqgl0Vcdl1ftAusM_1DHSDHtz1kSUzqnmwsk=@protonmail.com>
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Tue, 10 May 2022 11:37:26 +0200
Message-ID: <CAMhCMoGbrgrXbUwUm0EiNWTKKx0oyr4=mqBCLPWMktHpwgnXhg@mail.gmail.com>
To: darosior <darosior@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000003d0ea205dea51337"
X-Mailman-Approved-At: Tue, 10 May 2022 09:43:49 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <darosior@protonmail.com> wrote:

> 1. The `<NUM;NUM>` 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 `/<m;n>` 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

<div dir=3D"ltr"><div dir=3D"ltr">Hi Antoine and Billy,<div><br></div><div>=
Thank you for your comments and for looking into the proposal.</div><div><b=
r></div><div>On Mon, 9 May 2022 at 12:36, darosior &lt;<a href=3D"mailto:da=
rosior@protonmail.com" target=3D"_blank">darosior@protonmail.com</a>&gt; wr=
ote:<br></div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">1. The `&lt;NUM;NUM&gt;` optimization for the common =
usecase of using 2 descriptors at different derivation indices<br>
=C2=A0 =C2=A0for receive and change. [1]<br>
2. The `/**` optimization for the common usecase of `/&lt;0;1&gt;` for poin=
t 1).<br><br>[...]<br>
<br>
I&#39;m not so sure about the second point. Is another deviation from the s=
tandard worth it just for saving 3<br>
characters?<br></blockquote><div><br>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 `\&lt;0;1&gt;` is availab=
le.</div><div>I have been using it since before the `\&lt;0;1&gt;` 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<br><br></div><=
div>=C2=A0 =C2=A0 sh(sortedmulti(2,@0/**,@1/**,@2/**))</div><div><br></div>=
<div>is quite a lot more readable (especially on a small screen) than<br><b=
r></div><div>=C2=A0 =C2=A0 sh(sortedmulti(2,@0/&lt;0;1&gt;/*,@1/&lt;0;1&gt;=
/*,@2/&lt;0;1&gt;/*))<br><br>Apart from the additional 5 characters <i>per =
placeholder</i>, there are a lot more numbers to parse for the user.</div><=
div><br></div><div>Yet, I&#39;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 &quot;Taproot=
 3-of-5 multisig&quot;. Show the full taptree policy should be reserved for=
 the 1% of advanced use-cases that are not in the catalogue.</div><div><br>=
</div><div><div>Slightly off-topic, but my impression is that descriptors a=
re outgrowing their original scope (probably the reason for sipa&#39;s comm=
ents[1] on the early proposals for multiple derivation paths in one descrip=
tor).<br></div><div>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 `/&lt;=
m;n&gt;` syntax would entirely be on a separate layer (the `combo` descript=
or[2] would also be extraneous in this interpretation).=C2=A0</div><div>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).</div></div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">However, why does it need to be a change to the de=
scriptor language? It looks a lot like something that needs<br>
to be handled at the application level with key aliasing.</blockquote><div>=
<br>Key aliasing is not part of descriptors; therefore, &quot;descriptors w=
ith key aliasing&quot; are still a language on top of descriptors.</div><di=
v><br></div><div>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.<br>Note that by separating the <i>wallet =
descriptor template</i>=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 &quot;vector of key information&quot;, 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/&lt;0;1&gt;/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.</div><div><br></div><div>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.</div><div><br></div><div>I think to better suit=C2=
=A0the needs of both hardware and software wallets, you need both the <i>ex=
tensions</i>=C2=A0and the <i>restrictions</i>. That&#39;s why I propose to =
keep them separated, rather than suggesting changes to descriptors.<br></di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Unrelated question, since you mentioned `musig2` descriptors in this contex=
t. I thought Musig2 wasn&#39;t really<br>
feasible for hardware signing devices, especially stateless ones. Do you th=
ink/know whether it is actually<br>
possible for a HW to take part in a Musig2?<br></blockquote><div><br>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&#39;t break =
with future upgrades to descriptors.</div><div>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&#39;t think there are technical blockers for musig2.<br><br>=
Salvatore<br><br><br><div>[1]=C2=A0<a href=3D"https://github.com/bitcoin/bi=
tcoin/issues/17190#issuecomment-543845642" target=3D"_blank">https://github=
.com/bitcoin/bitcoin/issues/17190#issuecomment-543845642</a></div><div>[2]=
=C2=A0<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0384.media=
wiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-038=
4.mediawiki</a></div></div></div>
</div>

--0000000000003d0ea205dea51337--