From: "David A. Harding" <dave@dtrt•org>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
Date: Mon, 15 Mar 2021 14:24:01 -1000 [thread overview]
Message-ID: <20210316002401.zlfbc3y2s7vbrh35@ganymede> (raw)
In-Reply-To: <202103152148.15477.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]
On Mon, Mar 15, 2021 at 09:48:15PM +0000, Luke Dashjr via bitcoin-dev wrote:
> Note that in all circumstances, Bitcoin is endangered when QC becomes
> a reality [...] it could very well become an unrecoverable situation
> if QC go online prior to having a full quantum-safe solution.
The main concern seems to be someone developing, in secret, a quantum
computer with enough capacity to compromise millions of keys and then
deciding to use the most powerful and (probably) expensive computer ever
developed to steal coins that will almost immediately lose most or all
of their value.
That's certainly a threat we should consider, but like other "movie
plot" threats, I think we should weigh its unlikeliness in comparison
to the people who are losing smaller amounts of money on a regular basis
right now because we don't already have taproot---people who don't use
multisig, or contracts with threshold reduction timeout clauses, or
certain types of covenants because the contingencies these types of
scripts protect against come at too great a cost in fees for the typical
case where no contingencies are needed.
We have many ideas about how to mitigate the risk of effective quantum
computing attacks, from emergency protection to long-term solutions, so
it seems to me that the real risk in the movie plot scenario comes
entirely from *secret advances* in quantum computing. Other similar
risks for Bitcoin exist, such as secret discoveries about how to
compromise the hash functions Bitcoin depends on. One way to help
control those risks is to pay a public bounty to anyone who provably and
publicly discloses the secret advance (ideally while allowing the leaker
to remain anonymous). Several years ago, Peter Todd created a series of
Bitcoin addresses that does exactly that.[1]
For example, if you pay 35Snmmy3uhaer2gTboc81ayCip4m9DT4ko, then
anyone[2] who can prove a collision attack against Bitcoin's primary
hash function, SHA256, will be able to claim the bitcoins you and other
people sent to that address. Their claim of the funds will publicly
demonstrate that someone can create a SHA256 collision, which is an
attack we currently believe to be impractical. This system was
demonstrated to work about four years ago[3] when the collision bounty
for the much weaker SHA1 function was claimed.[4]
We can already create an output script with a Nothing Up My Sleeve
(NUMS) point that would provide a trustless bounty to anyone proving the
capability to steal any P2PK-style output with secp256k1's 128-bit
security. I curious about whether anyone informed about ECC and QC
knows how to create output scripts with lower difficulty that could be
used to measure the progress of QC-based EC key cracking. E.g.,
NUMS-based ECDSA- or taproot-compatible scripts with a security strength
equivalent to 80, 96, and 112 bit security.
That way the people and businesses concerned about QC advances could
send a few BTC to those addresses to create a QC early warning system
that would allow us to continue confidently working on EC-based
protocols for now but also objectively alert us to when we need to shift
to working on post-QC protocols for the future.
Thank you,
-Dave
[1] https://bitcointalk.org/index.php?topic=293382.0
[2] Anyone claiming the reward may need to mine their own transaction to
protect it against rewriting. In the worst case, they may need to
mine at a depth of several blocks or share their reward with miners
to prevent sniping reorgs.
[3] https://blockstream.info/tx/8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc
[4] To the best of my knowledge, nothing in Bitcoin ever depended
significantly on SHA1, and especially not on SHA1 collision
resistance, which was known to be weak even in 2009 when Nakamoto
first published the Bitcoin software.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-03-16 0:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 21:48 Luke Dashjr
2021-03-15 22:05 ` Matt Corallo
2021-03-15 22:30 ` Robert Spigler
2021-03-15 22:40 ` Jeremy
2021-03-15 22:48 ` Matt Corallo
2021-03-15 23:01 ` Karl-Johan Alm
2021-03-15 23:19 ` Matt Corallo
2021-03-15 23:46 ` Lloyd Fournier
2021-03-16 0:50 ` Anthony Towns
2021-03-16 2:38 ` ZmnSCPxj
2021-03-16 3:44 ` Luke Dashjr
2021-03-16 13:28 ` Andrew Poelstra
2021-03-16 17:25 ` Matt Corallo
2021-03-17 1:23 ` Ryan Grant
2021-03-17 11:56 ` Eoin McQuinn
2021-03-15 23:12 ` Andrew Poelstra
2021-03-16 14:10 ` Andrea
2021-03-16 15:15 ` [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections) Andrew Poelstra
2021-03-17 4:24 ` ZmnSCPxj
2021-03-17 8:29 ` Andrea
2021-03-20 16:31 ` Andrea Barontini
2021-03-16 0:24 ` David A. Harding [this message]
2021-04-05 0:27 ` [bitcoin-dev] PSA: Taproot loss of quantum protections Lloyd Fournier
2021-04-16 3:47 ` ZmnSCPxj
2021-04-16 5:00 ` Lloyd Fournier
2021-03-22 14:24 ` Erik Aronesty
2021-03-23 9:36 ` Martin Schwarz
2021-03-23 10:50 ` Tim Ruffing
2021-08-12 22:08 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210316002401.zlfbc3y2s7vbrh35@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox