path: root/1c/061e5c527c69e1ffabca1903ad76a629f72e3f

Return-Path: <RobertSpigler@protonmail.ch>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5FECAC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:30:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 420374EBDD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:30:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 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,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=protonmail.ch
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 N2sM49Lxw6qc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:30:48 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18])
 by smtp4.osuosl.org (Postfix) with ESMTPS id B19F74EBD1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 15 Mar 2021 22:30:47 +0000 (UTC)
Date: Mon, 15 Mar 2021 22:30:35 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch;
 s=protonmail; t=1615847443;
 bh=ZAxYIM+3FcWew5wmqQJpsZcJhXqaRfu87Y++GAlyTKM=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=nctNpt67/q/GIz7MFferMUkgxc27g1Ob1jsNQk9zzWQsPxO85p+erFgQgi15OPEIU
 nssMGEj64hkJXu4Oh65whU+UOu43H1/sQm72vDBRfzbA+1YiJoMH3Lp9Hv5JyFXkEy
 ne3i+LuHBl+uSdh+nvljaCNJd2WTS0BL+e6LvNNg=
To: Matt Corallo <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Robert Spigler <RobertSpigler@protonmail.ch>
Reply-To: Robert Spigler <RobertSpigler@protonmail.ch>
Message-ID: <0RxHhUWPeVWzk1dqjcfHngM3GBsZveFYR1bMHxOBVhA_xCR964mxEuHjNPk3DQbvA_kKfArFJYTrb_Hg-NhjqFkE5e-wjxBHGi_HvA_jgNk=@protonmail.ch>
In-Reply-To: <a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com>
References: <202103152148.15477.luke@dashjr.org>
 <a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 16 Mar 2021 12:18:27 +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 22:30:50 -0000

I agree with Matt.

The naked pubkey is required for some of the benefits being implemented (sn=
icker coinjoins).

Even with pubkey hashes, bitcoin could still be stolen because the pubkey i=
s published on spend.  Regardless, QC needs to be fixed later on (decades),=
 and shouldn't be a reason to NACK taproot.


Personal Fingerprint:=C2=A0 BF0D 3C08 A439 5AC6 11C1 5395 B70B 4A77 F850 54=
8F


=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Monday, March 15, 2021 6:05 PM, Matt Corallo via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:

> There have been many threads on this before, I'm not sure anything new ha=
s 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 be=
come
> > clear to me over the past week or so that many others are unaware of th=
is
> > tradeoff, so I am sharing it here to ensure the wider community is awar=
e of
> > it and can make their own judgements.
>
> Note that this is most definitelynot news to this list, eg, Anthony broug=
ht it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy preservi=
ng switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse =
corpse.
>
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause" whi=
le a
> > full quantum-safe fix is developed, and then resume transacting. With T=
aproot
> > as-is, it could very well become an unrecoverable situation if QC go on=
line
> > prior to having a full quantum-safe solution.
>
> This has been discussed ad nauseam, and it all seems to fall apart once i=
ts noted just how much Bitcoin could be stolen
> by any QC-wielding attacker due to address reuse. Ultimately, no "pause" =
can solve this issue, and, if we learned about
> a QC attacker overnight (instead of slowly over time), there isn't anythi=
ng that a non-Taproot Bitcoin could do that a
> Taproot Bitcoin couldn't.
>
> > Also, what I didn't know myself until today, is that we do not actually=
 gain
> > anything from this: the features proposed to make use of the raw keys b=
eing
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for any=
one
> > running a full node (indeed, CPU time is freed up by Taproot!); at wors=
t, it
> > would create an incentive for more people to use their own full node, w=
hich
> > is a good thing!
>
> This is untrue. The storage space required for Taproot transactions is ma=
terially reduced by avoiding the hash indirection.
>
> > Despite this, I still don't think it's a reason to NACK Taproot: it sho=
uld be
> > fairly trivial to add a hash on top in an additional softfork and fix t=
his.
>
> For the reason stated above, i think such a fork is unlikely.
>
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the suppl=
y is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> > First, so long as we have hash-based addresses as a best practice, we c=
an
> > continue to shrink the percentage of bitcoins affected through social e=
fforts
> > discouraging address use. If the standard loses the hash, the situation
> > cannot be improved, and will indeed only get worse.
>
> I truly wish this were the case, but we've been beating that drum for at =
least nine years and still haven't solved it.
> Worse, there's a lot of old coins that are unlikely to move any time soon=
 that are exposed whether we like it or not.
>
> > Second, when/if quantum does compromise these coins, so long as they ar=
e
> > neglected or abandoned/lost coins (inherent in the current model), it c=
an be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of sup=
ply
> > minable by QCs is really no different than 37% minable by ASICs. (We've=
 seen
> > far higher %s available for mining obviously.)
>
> Except its not? One entity would be able to steal that entire block of su=
pply rather quickly (presumably over the course
> of a few days, at maximum), instead of a slow process with significant up=
front real-world cost in the form of electricity.
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev