From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5FECAC0001 for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: Robert Spigler Reply-To: Robert Spigler Message-ID: <0RxHhUWPeVWzk1dqjcfHngM3GBsZveFYR1bMHxOBVhA_xCR964mxEuHjNPk3DQbvA_kKfArFJYTrb_Hg-NhjqFkE5e-wjxBHGi_HvA_jgNk=@protonmail.ch> In-Reply-To: References: <202103152148.15477.luke@dashjr.org> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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