From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4E68AC002D for ; Tue, 24 Jan 2023 08:38:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 21EB1409B2 for ; Tue, 24 Jan 2023 08:38:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 21EB1409B2 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=hLUBH5bQ 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 Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyAM1_v9GcpW for ; Tue, 24 Jan 2023 08:38:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9FD0140920 Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9FD0140920 for ; Tue, 24 Jan 2023 08:38:42 +0000 (UTC) Received: by mail-oi1-x22a.google.com with SMTP id n8so12720110oih.0 for ; Tue, 24 Jan 2023 00:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9FlYtKDCTCccJu/Pz+awq+JUMv9Flzonb/lUuOOlK+4=; b=hLUBH5bQph/s9IETK4cGa01tmRxmxOFkcgdN+8OTnU+hcY+THF8pKASLFmqm21GYxG 48d1ysaXvv9ws2tM27wUc/eVDPIH0gDU9VBYYb676CpLf79clw7fNUCLIyh63VBLySnZ LeOMbpndwxL3gcUiw/dTWV0/oMCxt/ahiMDNwk1vhEzDiKR9hBLKEGmaXZmJvorRUJZR PWtgKpE2NikiEQ2ILTY97ngWRv9EN3HNgg96PDM95o1zMMcSEO4fVwfSi6Zrrsx0LHSR vEsbptp1o9OAe+7cYg4lhMOWsri2qiGUdYdvZSHtHB4eypZMGsAU8tC6pLrJVyocV3CB q0oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9FlYtKDCTCccJu/Pz+awq+JUMv9Flzonb/lUuOOlK+4=; b=4YiFrKutWSkdxY3mXA/T2CcgbYYQtj4TaVOrA4Wd+U7JrfFHO77/TocMLgu8WoQNIs 8xBy5pZ0IlKpJLc5BO36P2Ep7citSVmOWOFpYD0p6sVsiBM80Gz9w1OyCDKIuYoPAgkh 8FhI9CdYC+QfMmI8WTVsDAIIfivlZfbh8UXas1RRZltJln0oxUV42L47A2c7zOumKjDs dNJqhSAGz/VRCOnHcnuHfm5f73paMndhOAcU0CheKh+SCd+k4F+H5x8y+i5NzCP9lKHd Q1sMXr9MdKBWzgWDUaDDzk+unqPbQbcGvLIpHUDtylOt4ivomtNZSa9bqr9eCC29BOga HAnA== X-Gm-Message-State: AFqh2kpXH/vmkUvwAcBPmGZx+34+BvBwc8iBJOR/0V/S4FoYrlhLJgeQ iLGH99Qogtav0pFFmSd8BKjpD83Cr5GQ3DyeQtFzWBOC X-Google-Smtp-Source: AMrXdXsAz3sHhqUVgzBZbIrSC4+jg90sgC/ehDBoznqluN+YipjCHFnODjK8QH9q1SuwP4n0euxs2SjlFYJIB65BBzk= X-Received: by 2002:a05:6808:2182:b0:367:1b6b:7989 with SMTP id be2-20020a056808218200b003671b6b7989mr2008313oib.186.1674549521250; Tue, 24 Jan 2023 00:38:41 -0800 (PST) MIME-Version: 1.0 References: <4UmvJ86zmTfQzopOERA87HTBVOWo169DjJRc9Q778Hi60ZCuXjaiGyUqu7ZNGROxXqo_Ah_LtSg58wqfNba5avO6vStn_N4eL1J7YfvI7F0=@protonmail.com> In-Reply-To: <4UmvJ86zmTfQzopOERA87HTBVOWo169DjJRc9Q778Hi60ZCuXjaiGyUqu7ZNGROxXqo_Ah_LtSg58wqfNba5avO6vStn_N4eL1J7YfvI7F0=@protonmail.com> From: Salvatore Ingala Date: Tue, 24 Jan 2023 09:38:29 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000005f7e1605f2fe719c" X-Mailman-Approved-At: Tue, 24 Jan 2023 09:19:35 +0000 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, 24 Jan 2023 08:38:44 -0000 --0000000000005f7e1605f2fe719c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, Thanks for your very interesting suggestions! On Mon, 23 Jan 2023 at 20:53, darosior wrote: > Actually you can save a few more characters, and gain some clarity, by sh= owing 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 impo= rting, 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 verif= ied 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 "sem= antic 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 --0000000000005f7e1605f2fe719c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

Thanks for your = very interesting suggestions!

On Mon, 23 Jan 2023 at 20:53, darosior <darosior@protonmail.com> wr= ote:
=
Actually you can save a few more characters, and gain some clarity, by show=
ing 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(1296=
0))
For this specific example you'd save 8 (confusing) charac=
ters to be verified on the signing device.

I thought about that, and I still consider it a possible f= uture improvement in UX. However, I wasn't comfortable deploying it in = this way for the following reason: if there is malware in your software wal= let at policy registration time, the malware could find a different miniscr= ipt 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 actu= ally received. The user might see funds mysteriously disappear, while the a= ttacker would know the actual miniscript policy,=C2=A0enabling ransom attac= ks.

The attack seems very unlikely today, and for many interesting s= emantic policies, there are probably not many miniscript policies to sift t= hrough in case of recovery.
However, I suspect it will become more reali= stic in a taproot world, where the semantic policy of each tapleaf could ha= ve multiple options,=C2=A0resulting in combinatorial explosion.
F= or example, if there are 2 options for the miniscript of each leaf, and n l= eaves, you would have 2^n possible descriptors with the same semantic polic= y.

One solution might be to explicitly enumerate (or at least= upper-bound) the number of possible descriptors that are lifted to the sam= e policy, and use the simplified UX if this number is not too large.
Hav= ing a set of standard recovery tools for those situations might make this a= pproach more viable in my opinion.

I wonder if signing devices could eve=
n go further and display a plain english verification to the user, like &qu=
ot;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. T=
he second spending path is Bob and Carol signing together after 90 days. Th=
e 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 qu= ite large and I have not yet put enough thought into it.

I guess it clas=
hes with the user willing to check their backup against the policy register=
ed on the device. You could always have the user-friendly policy check at f=
irst and have an option to show the raw descriptor for them to be able to c=
ross-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-combinat= orial-explosion issues above.

PS: the numerous usage of the word "p=
olicy" is getting complex lol, is it a Miniscript concrete policy, a M=
iniscript semantic policy, a BIP-wallet-policies policy? :)
...yeah, we should have a policy against that!

Sa= lvatore Ingala
--0000000000005f7e1605f2fe719c--