diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2021-03-15 18:48:21 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-03-15 22:48:26 +0000 |
| commit | 13fe8ff59a2ea28a742cc3eca6fe9c4407982331 (patch) | |
| tree | e11df51ff6833bf1533bf72b8194879f5c6a1be4 | |
| parent | a05243cbf80fe1123eacd61164a163d45d71c754 (diff) | |
| download | pi-bitcoindev-13fe8ff59a2ea28a742cc3eca6fe9c4407982331.tar.gz pi-bitcoindev-13fe8ff59a2ea28a742cc3eca6fe9c4407982331.zip | |
Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
| -rw-r--r-- | 37/628186b6efb67ba24be7ed99caa169a646e986 | 169 |
1 files changed, 169 insertions, 0 deletions
diff --git a/37/628186b6efb67ba24be7ed99caa169a646e986 b/37/628186b6efb67ba24be7ed99caa169a646e986 new file mode 100644 index 000000000..1d273501e --- /dev/null +++ b/37/628186b6efb67ba24be7ed99caa169a646e986 @@ -0,0 +1,169 @@ +Return-Path: <lf-lists@mattcorallo.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 2962BC0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 15 Mar 2021 22:48:26 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with UTF8SMTP id 0B8F26F5ED + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 15 Mar 2021 22:48:26 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.8 +X-Spam-Level: +X-Spam-Status: No, score=-2.8 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, RCVD_IN_DNSWL_LOW=-0.7, + SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp3.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=mattcorallo.com +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with UTF8SMTP id ePCotA3xVEeK + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 15 Mar 2021 22:48:25 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) + by smtp3.osuosl.org (Postfix) with UTF8SMTPS id 9ECB56F5E4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 15 Mar 2021 22:48:24 +0000 (UTC) +Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id 284694E28C7; + Mon, 15 Mar 2021 22:48:22 +0000 (UTC) +X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; + s=1615846864; t=1615848502; + bh=L4dnSgY5Ljm0r/+Bm/nMppOcumpAzeZBaY4ISYyfti0=; + h=Date:Subject:To:Cc:References:From:In-Reply-To:From; + b=Oc85X9cWrVbBBvlujGYwKZO6yhz2V0VDcxJ8In/bmck0dg6gIpeFmMh2kS7VGk4df + BL3rFqbZQb+W8s6TVdFsniRsyOuO5mbnbIN/e/qxu4LGdKqrsYHLB80wSj6kNAACOA + kmkyBLiwGpTrTNzQJR4C/wLtEWzzzLJWajiFcWh6yCiNY4etNzn0IBgsW02bXY2ttz + /nEPbPytN9O3gEKcW6CI8WGcvMR7/TN1pNGLurON/qaTJqHJc27kMR9RO0MhSetmb+ + wzNlIazSQoPBLbYDmSlJ6GRM2BPMCQVuY6WeCz0tLX+ouWMIuzwXR1NYmWL7td1alQ + JqYU/YGAbVT8Q== +Message-ID: <a4b9df55-b95b-9c95-62ea-7bf6eeec113d@mattcorallo.com> +Date: Mon, 15 Mar 2021 18:48:21 -0400 +MIME-Version: 1.0 +Content-Language: en-US +To: Jeremy <jlrubin@mit.edu>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +References: <202103152148.15477.luke@dashjr.org> + <a88cd471-fdc9-de35-86cd-595b387249c8@mattcorallo.com> + <CAD5xwhi82fjRB4Ceb6Gnp+LvTweWjwFRmWU5zD-3o6s_GoEvPw@mail.gmail.com> +From: Matt Corallo <lf-lists@mattcorallo.com> +In-Reply-To: <CAD5xwhi82fjRB4Ceb6Gnp+LvTweWjwFRmWU5zD-3o6s_GoEvPw@mail.gmail.com> +Content-Type: text/plain; charset=UTF-8; format=flowed +Content-Transfer-Encoding: 7bit +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:48:26 -0000 + +Right, you can avoid the storage cost at the cost of significantly higher CPU usage, plus lack of ability to +batch-validate. As Robert pointed out in a neighboring mail, it also reduces ability to do other, fancier, protocols +using the fact that public keys are now a public part of a script_pubkey. + +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. + +Matt + +On 3/15/21 18:40, Jeremy wrote: +> I think Luke is pointing out that with the Signature and the Message you should be able to recover the key. +> +> if your address is H(P) and the message is H(H(P) || txn), then the you can use the public H(P) and the signature to +> recover the PK and verify that H(P) == P (I think you then don't even have to check the signature after doing that). +> +> Therefore there is no storage benefit. +> +> For the script path case, you might have to pay a little bit extra though as you'd have to reveal P I think? But perhaps +> that can be avoided another way... +> -- +> @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin> +> +> +> On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org +> <mailto: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. +> +> > +> > 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" while a +> > full quantum-safe fix is developed, and then resume transacting. With Taproot +> > as-is, it could very well become an unrecoverable situation if QC go online +> > prior to having a full quantum-safe solution. +> +> This has been discussed ad nauseam, and it all seems to fall apart once its 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 anything 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 being +> > 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 anyone +> > running a full node (indeed, CPU time is freed up by Taproot!); at worst, it +> > would create an incentive for more people to use their own full node, which +> > is a good thing! +> +> This is untrue. The storage space required for Taproot transactions is materially reduced by avoiding the hash +> indirection. +> +> > Despite this, I still don't think it's a reason to NACK Taproot: it should be +> > fairly trivial to add a hash on top in an additional softfork and fix this. +> +> 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 supply 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 can +> > continue to shrink the percentage of bitcoins affected through social efforts +> > 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 are +> > neglected or abandoned/lost coins (inherent in the current model), it can be +> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of supply +> > 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 supply rather quickly (presumably over the +> course +> of a few days, at maximum), instead of a slow process with significant upfront real-world cost in the form of +> electricity. +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org> +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> +> + |