From: Salvatore Ingala <salvatore.ingala@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Wallet policies for descriptor wallets
Date: Tue, 24 Jan 2023 09:38:29 +0100 [thread overview]
Message-ID: <CAMhCMoGWNzXsiVCEhxZQ+WDzUp92m74F1-xLC4wdUjHsj+EDnQ@mail.gmail.com> (raw)
In-Reply-To: <4UmvJ86zmTfQzopOERA87HTBVOWo169DjJRc9Q778Hi60ZCuXjaiGyUqu7ZNGROxXqo_Ah_LtSg58wqfNba5avO6vStn_N4eL1J7YfvI7F0=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]
Hi Antoine,
Thanks for your very interesting suggestions!
On Mon, 23 Jan 2023 at 20:53, darosior <darosior@protonmail•com> wrote:
> Actually you can save a few more characters, and gain some clarity, by showing the "semantic policy" instead of the actual Miniscript. If the intent is for the user to verify the semantic of the Bitcoin Script they are importing, you can just drop all the type information.
> For instance, for a Miniscript representing the Miniscript policy "a 3-of-3 that becomes a 2-of-3 after 90 days" instead of showing:
>
> thresh(3,pk(Alice),s:pk(Bob),s:pk(Carol),sln:older(12960))
> You could show:
>
> thresh(3,pk(Alice),pk(Bob),pk(Carol),older(12960))
> For this specific example you'd save 8 (confusing) characters to be verified on the signing device.
>
>
I thought about that, and I still consider it a possible future improvement
in UX. However, I wasn't comfortable deploying it in this way for the
following reason: if there is malware in your software wallet at policy
registration time, the malware could find a different miniscript with the
same semantic policy.
The result is now a mismatch between the wallet policy in the user's backup
and the one where funds are actually received. The user might see funds
mysteriously disappear, while the attacker would know the actual miniscript
policy, enabling ransom attacks.
The attack seems very unlikely today, and for many interesting semantic
policies, there are probably not many miniscript policies to sift through
in case of recovery.
However, I suspect it will become more realistic in a taproot world, where
the semantic policy of each tapleaf could have multiple options, resulting
in combinatorial explosion.
For example, if there are 2 options for the miniscript of each leaf, and n
leaves, you would have 2^n possible descriptors with the same semantic
policy.
One solution might be to explicitly enumerate (or at least upper-bound) the
number of possible descriptors that are lifted to the same policy, and use
the simplified UX if this number is not too large.
Having a set of standard recovery tools for those situations might make
this approach more viable in my opinion.
I wonder if signing devices could even go further and display a plain
english verification to the user, like "This policy contains 4
spending paths. Be ready to verify the 4 spending paths. The first
spending path is Alice, Bob and Carol signing together. The second
spending path is Bob and Carol signing together after 90 days. The
third spending path is Alice and Carol signing together after 90 days.
The third spending path is Alice and Bob signing together after 90
days."
> It seems feasible to be doable in a general manner from a Miniscript "semantic policy".
>
> A lower-hanging fruit might be to find ways of registering
xpubs/identities on the device, so that one could replace xpubs with
"Alice" and "Bob".
Once that's done, that might be one of the possible approaches to simplify
the UX flow.
I suspect the design space to be quite large and I have not yet put enough
thought into it.
I guess it clashes with the user willing to check their backup against
the policy registered on the device. You could always have the
user-friendly policy check at first and have an option to show the raw
descriptor for them to be able to cross-check it with their backup.
>
> I'm assuming the user will do the minimum amount of work they are forced
to do, therefore I only consider this safe iff we address the
miniscript-combinatorial-explosion issues above.
PS: the numerous usage of the word "policy" is getting complex lol, is
it a Miniscript concrete policy, a Miniscript semantic policy, a
BIP-wallet-policies policy? :)
>
> ...yeah, we should have a policy against that!
Salvatore Ingala
[-- Attachment #2: Type: text/html, Size: 5166 bytes --]
prev parent reply other threads:[~2023-01-24 8:38 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
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 [this message]
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=CAMhCMoGWNzXsiVCEhxZQ+WDzUp92m74F1-xLC4wdUjHsj+EDnQ@mail.gmail.com \
--to=salvatore.ingala@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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