path: root/55/377c0191bce90d7c449d419b6d0bc296cb82cb

Return-Path: <salvatore.ingala@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4E68AC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Jan 2023 08:38:42 +0000 (UTC)
Received: by mail-oi1-x22a.google.com with SMTP id n8so12720110oih.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAMhCMoHfdsQMsVigFqPexTE_q-Cyg7pfRvORUoy2sZtvyzd1cg@mail.gmail.com>
 <CAMhCMoFWHUKVg0n2jVwxfAsuFqsCXPWHg4Bw_sk0xfTs4FPnkw@mail.gmail.com>
 <4UmvJ86zmTfQzopOERA87HTBVOWo169DjJRc9Q778Hi60ZCuXjaiGyUqu7ZNGROxXqo_Ah_LtSg58wqfNba5avO6vStn_N4eL1J7YfvI7F0=@protonmail.com>
In-Reply-To: <4UmvJ86zmTfQzopOERA87HTBVOWo169DjJRc9Q778Hi60ZCuXjaiGyUqu7ZNGROxXqo_Ah_LtSg58wqfNba5avO6vStn_N4eL1J7YfvI7F0=@protonmail.com>
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Tue, 24 Jan 2023 09:38:29 +0100
Message-ID: <CAMhCMoGWNzXsiVCEhxZQ+WDzUp92m74F1-xLC4wdUjHsj+EDnQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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, 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 <darosior@protonmail.com> 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

<div dir=3D"ltr"><div>Hi Antoine,</div><div><br></div><div>Thanks for your =
very interesting suggestions!</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Mon, 23 Jan 2023 at 20:53, darosior &lt;<a=
 href=3D"mailto:darosior@protonmail.com">darosior@protonmail.com</a>&gt; wr=
ote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre><span styl=
e=3D"font-family:arial;font-size:14px;line-height:normal;color:rgb(0,0,0)">=
Actually you can save a few more characters, and gain some clarity, by show=
ing the &quot;semantic policy&quot; instead of the actual Miniscript. <span=
>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.</span><br>=
For instance, for a Miniscript representing the Miniscript policy &quot;a 3=
-of-3 that becomes a 2-of-3 after 90 days&quot; instead of showing: <br><p>=
<code>thresh(3,pk(Alice),s:pk(Bob),s:pk(Carol),sln:older(12960))</code></p>=
You could show:<br><p><code>thresh(3,pk(Alice),pk(Bob),pk(Carol),older(1296=
0))</code></p>For this specific example you&#39;d save 8 (confusing) charac=
ters to be verified on the signing device.<br></span></pre></blockquote><di=
v><br></div><div>I thought about that, and I still consider it a possible f=
uture improvement in UX. However, I wasn&#39;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.<br>The result is now a mismatch between =
the wallet policy in the user&#39;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.<br><br>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.<br>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.</div><div>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.</div><div><br>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.<br>Hav=
ing a set of standard recovery tools for those situations might make this a=
pproach more viable in my opinion.<br><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"><pre><span style=3D"font-family:arial;font-size:14px=
;line-height:normal;color:rgb(0,0,0)">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. <s=
pan>The third spending path is Alice and Bob signing together after 90 days=
</span>.&quot;<br>It seems feasible to be doable in a general manner from a=
 Miniscript &quot;semantic policy&quot;.<br></span></pre></blockquote><div>=
A lower-hanging fruit might be to find ways of registering xpubs/identities=
 on the device, so that one could replace xpubs with &quot;Alice&quot; and =
&quot;Bob&quot;.<br>Once that&#39;s done, that might be one of the possible=
 approaches to simplify the UX flow.<br>I suspect the design space to be qu=
ite large and I have not yet put enough thought into it.<br><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><pre><span style=3D"font-famil=
y:arial;font-size:14px;line-height:normal;color:rgb(0,0,0)">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.<br></span></pre></blockquote><div>I&#39;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.<br><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"><pre><span style=3D"font-family:arial;font-size:14px;line=
-height:normal;color:rgb(0,0,0)">PS: the numerous usage of the word &quot;p=
olicy&quot; is getting complex lol, is it a Miniscript concrete policy, a M=
iniscript semantic policy, a BIP-wallet-policies policy? :)<br></span></pre=
></blockquote><div>...yeah, we should have a policy against that!<br><br>Sa=
lvatore Ingala</div></div></div>

--0000000000005f7e1605f2fe719c--