path: root/89/c7a49964b4471c6f735a009b47dedd9580e60f

Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7CEFCC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 23:46:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 55C3343007
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 23:46:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id PLxydjUrrXHI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 23:46:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [IPv6:2a00:1450:4864:20::229])
 by smtp2.osuosl.org (Postfix) with ESMTPS id D7E39414D4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 23:46:33 +0000 (UTC)
Received: by mail-lj1-x229.google.com with SMTP id s17so18339514ljc.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 16:46:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=sSZZiN4HgQ/p23iuBCwp8SE8BiI1yuv4tIzKRbzEkh4=;
 b=NNw3VVc/nLBGphRbvAmyskQmVU9RXLCUeJPbVvqpGHp6Nc2GwOUaBs8Kg3vp2bjb94
 we6TYVjdAbGMFYpHBLJHMMgIAFabjMCJbehiPKYRHPwq3+aFZXL/ZJIDJtN2bIH3znH8
 J+NiMzjH4pBiwUbgBtzBb4ZUnL0iMsHkbpd07pPSRjWHdyRTYveYdbK3v8oCJsm0lxyq
 Xr5hgBlBtoi+yKL/8A/Szn49vqfStgI3nh1QYk1gZuzBYoeN+gBd9okkK5zVX1mE7x3s
 jYcI/m+P0Dto4E+4V4Prt9VIbMbiIlv8xolt6tRc6NkdE9i51yAc9Yodo15S2X96nHPL
 b99Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=sSZZiN4HgQ/p23iuBCwp8SE8BiI1yuv4tIzKRbzEkh4=;
 b=tFj2va5+WuVqiYIWmZJ78eYQjiaErzI2DKcCOjsyq1+EFv4VLm516uZwO7GchsrdBf
 m0jBzoOOrKKJaRcSGtkUFpLt/z+/CuAn9zzCzz7U4f5rUYKFFet1Sh9Aj8gW0X5CkbGH
 zCChDmmqV1i7ya5fBKDOKmvPBLhIcZXe74e8ngN1YINFKefi32+YI+dSjAHQ/Ejcf9ep
 J2RNiNkfDB8j7k0MwKPws+ZhRPE2U716WG6nWo/o6LidyainCszN0kWrgc7hs2soH5KT
 oOOly4IZhChhHKOCbzfMW56RoApX6Wt86DAROsPGkaShNO0ETiUBN0KkrROgegajNjm4
 SDhA==
X-Gm-Message-State: AOAM530J5yZNrSlCbvY6a+Yq9u0v8IfidSv27mnBGe2ED3pQZsYaomKo
 T2F1hj2It1aWUr03MZ8sVHFzgonaa12OSUL19HE=
X-Google-Smtp-Source: ABdhPJy5kUqPkzZkahE3QwT5+NyZYkUXOp5SXV2VOEnv6lN3sUDcS+24GKC/nP2lQwo7DrtQJhgO5eeflKSMqGZD3bU=
X-Received: by 2002:a2e:8959:: with SMTP id b25mr866088ljk.245.1615851991618; 
 Mon, 15 Mar 2021 16:46:31 -0700 (PDT)
MIME-Version: 1.0
References: <202103152148.15477.luke@dashjr.org>
 <a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com>
 <CAD5xwhi82fjRB4Ceb6Gnp+LvTweWjwFRmWU5zD-3o6s_GoEvPw@mail.gmail.com>
 <a4b9df55-b95b-9c95-62ea-7bf6eeec113d@mattcorallo.com>
 <CALJw2w4hBk1pZrV7E6FNDPDCWH=T_S6qAHGKvRC6JsT9iZevfg@mail.gmail.com>
In-Reply-To: <CALJw2w4hBk1pZrV7E6FNDPDCWH=T_S6qAHGKvRC6JsT9iZevfg@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Tue, 16 Mar 2021 10:46:05 +1100
Message-ID: <CAH5Bsr2Rs=WGAVVjrDdtsYBGARNeeM210ubWacwJLJogMinm+w@mail.gmail.com>
To: Karl-Johan Alm <karljohan-alm@garage.co.jp>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f8576105bd9bdbd2"
X-Mailman-Approved-At: Tue, 16 Mar 2021 12:16:09 +0000
Subject: Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
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: Mon, 15 Mar 2021 23:46:35 -0000

--000000000000f8576105bd9bdbd2
Content-Type: text/plain; charset="UTF-8"

On Tue, 16 Mar 2021 at 09:05, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There have been many threads on this before, I'm not sure anything new has
> been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> > I do not personally see this as a reason to NACK Taproot, but it has
> become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware
> of
> > it and can make their own judgements.
>
> Note that this is most definitely *not* news to this list, eg, Anthony
> brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy
> preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse
> corpse.
>
>
I read through this thread just now. The QC discussion starts roughly here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015620.html

My own (very possibly wrong) interpretation of the situation is:

1. Current addresses are very vulnerable to QC and would require hardfork
to fix (and not fix particularly well).
2. Once a QC resistant spending procedure has been developed it could be
added as a backup spending policy as a new tapleaf version (wallets would
have to opt into it).
3. If QC does get to the point where it can break ECC then we can disable
key-path spends via softfork
4. If everyone has moved their coins to Taproot addresses with a QC
resistant tapleaf backup then we're ok.
5. Since the above is almost certainly not going to happen we can simply
congratulate the new QC owners on the Bitcoin they take from old addresses
(specter of QC encourages moving to taproot which could be thought of as a
good thing).
6. Otherwise we have to hard fork to stop old addresses being spent without
a quantum resistant ZKP (oof!).
7. Once we know what we're up against a new quantum resistant segwit
version can be introduced (if it hasn't already).
8. If QC develop far enough to degrade SHA256 sufficiently (ECC probably
breaks first) then that's a whole other ball game since it affects PoW and
txids and so on and will likely require a hard fork.

The ordering of the above events is not predictable. IMO Mark's post is on
the wildly optimistic side of projected rate of progress from my limited
understanding. Either way it is strictly better to enter a QC world with
Taproot enabled and most people are using it so we can introduce QC
resistant backup spend paths without hardforks before they become
practical. Depending on what happens they may not be needed but it's good
to have the option.

On Tue, 16 Mar 2021 at 10:11, Karl-Johan Alm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Overall, the tradeoffs here seem ludicrous, given that any QC issues in
> Bitcoin need to be solved in another way, and
> > can't practically be solved by just relying on the existing hash
> indirection.
>
> The important distinction here is that, with hashes, an attacker has
> to race against the spending transaction confirming, whereas with
> naked pubkeys, the attacker doesn't have to wait for a spend to occur,
> drastically increasing the available time to attack.
>
>
First note that I am enthusiastically ignorant of QC technology so please
take the following with a bowl of salt.
The premise of Mark's post is that QC progress is currently exponential
(debatable) and will continue to be (unknowable) so "months" will turn into
days and into minutes in short time period. Since QC progress is
exponential and the speedup that ECC quantum algorithms offer is
exponential you're not dealing with the typical "Moore's law" progress in
terms of time to solve a particular problem; It's like exponential
exponential (math person help me now). You could easily go from ten
thousand years to break ECC to a few seconds within a year with that rate
of progress so I don't think "slow quantum" is an adversary worth
protecting against. I would love to know if I am wrong on this point.

Cheers,

LL

--000000000000f8576105bd9bdbd2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue=
, 16 Mar 2021 at 09:05, Matt Corallo via bitcoin-dev &lt;<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">There have been many threads on this before, I&#39;m not=
 sure anything new has been brought up here.<br>
<br>
Matt<br>
<br>
On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:<br>
&gt; I do not personally see this as a reason to NACK Taproot, but it has b=
ecome<br>
&gt; clear to me over the past week or so that many others are unaware of t=
his<br>
&gt; tradeoff, so I am sharing it here to ensure the wider community is awa=
re of<br>
&gt; it and can make their own judgements.<br>
<br>
Note that this is most definitely *not* news to this list, eg, Anthony brou=
ght it up in &quot;Schnorr and taproot (etc) <br>
upgrade&quot; and there was a whole thread on it in &quot;Taproot: Privacy =
preserving switchable scripting&quot;. This issue has been <br>
beaten to death, I&#39;m not sure why we need to keep hitting the poor hors=
e corpse.<br>
<br></blockquote><div><br></div><div>I read through this thread just now. T=
he QC discussion starts roughly here: <a href=3D"https://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2018-January/015620.html" target=3D"_blank">h=
ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015620.=
html</a></div><div><br></div><div>My own (very possibly wrong) interpretati=
on of the situation is:</div><div><br></div><div>1. Current addresses are v=
ery vulnerable to QC and would require hardfork to fix (and not fix particu=
larly well).<br></div><div>2. Once a QC resistant spending procedure has be=
en developed it could be added as a backup spending policy as a new tapleaf=
 version (wallets would have to opt into it).</div><div>3. If QC does get t=
o the point where it can break ECC then we can disable key-path spends via =
softfork</div><div>4. If everyone has moved their coins to Taproot addresse=
s with a QC resistant tapleaf backup then we&#39;re ok.</div><div>5. Since =
the above is almost certainly not going to happen we can simply congratulat=
e the new QC owners on the Bitcoin they take from old addresses (specter of=
 QC encourages moving to taproot which could be thought of as a good thing)=
.</div><div>6. Otherwise we have to hard fork to stop old addresses being s=
pent without a quantum resistant ZKP (oof!).</div><div>7. Once we know what=
 we&#39;re up against a new quantum resistant segwit version can be introdu=
ced (if it hasn&#39;t already).</div><div>8. If QC develop far enough to de=
grade SHA256 sufficiently (ECC probably breaks first) then that&#39;s a who=
le other ball game since it affects PoW and txids and so on and will likely=
 require a hard fork.<br></div><div><br></div><div>The ordering of the abov=
e events is not predictable. IMO Mark&#39;s post is on the wildly optimisti=
c side of projected rate of progress from my limited understanding. Either =
way it is strictly better to enter a QC world with Taproot enabled and most=
 people are using it so we can introduce QC resistant backup spend paths wi=
thout hardforks before they become practical. Depending on what happens the=
y may not be needed but it&#39;s good to have the option.</div></div>

</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Tue, 16 Mar 2021 at 10:11, Karl-Johan Alm via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt; wrote:<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">On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Overall, the tradeoffs here seem ludicrous, given that any QC issues i=
n Bitcoin need to be solved in another way, and<br>
&gt; can&#39;t practically be solved by just relying on the existing hash i=
ndirection.<br>
<br>
The important distinction here is that, with hashes, an attacker has<br>
to race against the spending transaction confirming, whereas with<br>
naked pubkeys, the attacker doesn&#39;t have to wait for a spend to occur,<=
br>
drastically increasing the available time to attack.<br>
<br></blockquote></div><div class=3D"gmail_quote"><br></div><div class=3D"g=
mail_quote">First note that I am enthusiastically ignorant of QC technology=
 so please take the following with a bowl of salt.<br></div><div class=3D"g=
mail_quote">The premise of Mark&#39;s post is that QC progress is currently=
 exponential (debatable) and will continue to be (unknowable) so &quot;mont=
hs&quot; will turn into days and into minutes in short time period. Since Q=
C progress is exponential and the speedup that ECC quantum algorithms offer=
 is exponential you&#39;re not dealing with the typical &quot;Moore&#39;s l=
aw&quot; progress in terms of time to solve a particular problem; It&#39;s =
like exponential exponential (math person help me now). You could easily go=
 from ten thousand years to break ECC to a few seconds within a year with t=
hat rate of progress so I don&#39;t think &quot;slow quantum&quot; is an ad=
versary worth protecting against. I would love to know if I am wrong on thi=
s point.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quot=
e">Cheers,<br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">LL<br></div></div>

--000000000000f8576105bd9bdbd2--