From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
Date: Tue, 16 Mar 2021 02:38:55 +0000 [thread overview]
Message-ID: <JqUah_Mx6T415tjNgDCLVcDdkzQNXZatuMfzshQzZTlUpwbymbEHx7O3iciC-C2aYVl7BnkU0Tk_CvGTBrMpUJ6YQlcJZaHdaMPRs89iSPc=@protonmail.com> (raw)
In-Reply-To: <20210316005001.GA4304@erisian.com.au>
Good morning aj,
> On Tue, Mar 16, 2021 at 08:01:47AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
>
> > It may initially take months to break a single key.
>
> From what I understand, the constraint on using quantum techniques to
> break an ECC key is on the number of bits you can entangle and how long
> you can keep them coherent -- but those are both essentially thresholds:
> you can't use two quantum computers that support a lower number of bits
> when you need a higher number, and you can't reuse the state you reached
> after you collapsed halfway through to make the next run shorter.
>
> I think that means having a break take a longer time means maintaining
> the quantum state for longer, which is harder than having it happen
> quicker...
>
> So I think the only way you get it taking substantial amounts of time to
> break a key is if your quantum attack works quickly but very unreliably:
> maybe it takes a minute to reset, and every attempt only has probability
> p of succeeding (ie, random probability of managing to maintain the
> quantum state until completion of the dlog algorithm), so over t minutes
> you end up with probability 1-(1-p)^t of success.
>
> For 50% odds after 1 month with 1 minute per attempt, you'd need a 0.0016%
> chance per attempt, for 50% odds after 1 day, you'd need 0.048% chance per
> attempt. But those odds assume you've only got one QC making the attempts
> -- if you've got 30, you can make a month's worth of attempts in a day;
> if you scale up to 720, you can make a month's worth of attempts in an
> hour, ie once you've got one, it's a fairly straightforward engineering
> challenge at that point.
>
> So a "slow" attack simply doesn't seem likely to me. YMMV, obviously.
What you describe seems to match mining in its behavior: probabilistic, and scalable by pushing more electricity into more devices.
From this point-of-view, it seems to me that the amount of energy to mount a "fast" attack may eventually approach the energy required by mining, in which case someone who possesses the ability to mount such an attack may very well find it easier to just 51% the network (since that can be done today without having to pour R&D satoshis into developing practical quantum computers).
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-03-16 2:39 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 [this message]
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 ` [bitcoin-dev] PSA: Taproot loss of quantum protections David A. Harding
2021-04-05 0:27 ` 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='JqUah_Mx6T415tjNgDCLVcDdkzQNXZatuMfzshQzZTlUpwbymbEHx7O3iciC-C2aYVl7BnkU0Tk_CvGTBrMpUJ6YQlcJZaHdaMPRs89iSPc=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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