From: Salvatore Ingala <salvatore.ingala@gmail•com>
To: darosior <darosior@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Wallet policies for descriptor wallets
Date: Tue, 10 May 2022 11:37:26 +0200 [thread overview]
Message-ID: <CAMhCMoGbrgrXbUwUm0EiNWTKKx0oyr4=mqBCLPWMktHpwgnXhg@mail.gmail.com> (raw)
In-Reply-To: <osdF1jSCUyGyaLZ6YytSB7ub1MwdbaP6PMCYEJZXmMRaSs4vS7bs_SZTErxZh_K7oLYLAtAqqgl0Vcdl1ftAusM_1DHSDHtz1kSUzqnmwsk=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 5289 bytes --]
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 − 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
[-- Attachment #2: Type: text/html, Size: 6486 bytes --]
next prev parent reply other threads:[~2022-05-10 9:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-05 14:32 Salvatore Ingala
2022-05-08 17:41 ` Billy Tetrud
2022-05-09 11:36 ` darosior
2022-05-10 9:37 ` Salvatore Ingala [this message]
2022-09-29 23:56 ` Andrew Poelstra
2022-05-17 8:44 ` Salvatore Ingala
2022-11-21 11:27 ` Salvatore Ingala
2023-01-23 19:53 ` darosior
2023-01-24 8:38 ` Salvatore Ingala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMhCMoGbrgrXbUwUm0EiNWTKKx0oyr4=mqBCLPWMktHpwgnXhg@mail.gmail.com' \
--to=salvatore.ingala@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=darosior@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox