Hi Antoine, Thanks for your very interesting suggestions!
On Mon, 23 Jan 2023 at 20:53, darosior <daros...@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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
