From: Marin Ivezic <marin@appliedquantum•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: A Post Quantum Migration Proposal
Date: Sun, 20 Jul 2025 10:39:47 -0700 (PDT) [thread overview]
Message-ID: <1e39e6bd-8da4-45b1-9dc9-feacd923417dn@googlegroups.com> (raw)
In-Reply-To: <CAgIQP8YXvI8FjDiv0v29pw0VHdrlY6go6QoGMj1qqMsLKfGxeMBWVdxxQ5ZWhzl3T1wxjqj7XsPiRpTlBevo9hiNL92OtIQmMdGBsZaDqg=@proton.me>
[-- Attachment #1.1: Type: text/plain, Size: 4825 bytes --]
Even a year ago it was totally fair to question the feasibility of CRQCs.
After all the recent scientific and engineering wins, that is not in
question anymore. Eventual arrival of CRQC is pretty much a consensus now
in quantum and cyber communities.
But that question is almost irrelevant now. The world is acting like CRQCs
are coming, so we should act like it too. Regulators and governments are
issuing quantum readiness roadmaps, banks have started their programs,
insurers are carving out quantum risks, shareholders and analysts are
questioning quantum readiness on earnings calls… and the media is eating it
all up. The general public awareness is rapidly growing.
Rightly or wrongly, users will soon expect to see some assurances or plans
on how bitcoin will resist the quantum threat. And if our response is that
a few on the list think CRQC are laughable, the confidence will take a big
hit.
The proposed BIP makes lots of sense. With that and BIP-360, a plan is
shaping. And then we need three almost independent discussions:
1. We could technically solve Phase C (Post-Quantum Legacy Recovery) for
any impacted BIP-39 wallets. This is the (relatively) easy one.
2. How do we make it all a bit more “crypto-agile”?
3. And finally the philosophical discussion on how to treat legacy non-HD
wallets - burn them or allow them to be “stolen” / “liberated”.
Best,
Marin
On Sunday, July 20, 2025 at 6:07:01 PM UTC+2 conduition wrote:
> Hi Peter,
>
> I think everyone here is well-aware of the possibility
> that CRQCs may not ever appear, but that doesn't change
> the fact we must have a plan ready to handle them. Lopp's
> proposal does exactly that, and in a way that can be
> rolled out incrementally as the risk increases. And even
> if CRQCs never break discrete log, we would do well to
> invest the time in designing this migration path anyway.
> We'd then have a playbook to handle other sources of
> cryptanalytic breakthroughs in the future.
>
> I think you're worried the community may jump the gun and
> deploy a freezing upgrade like phases A or B too early. I
> share your concern but if anything I suspect the opposite
> will happen. Nobody is going to be willing to freeze
> anything unless imminent danger is readily apparent, and
> fear-based reactions kick in.
>
> Once it does, things will happen fast, and we need a plan
> ready for that day (if it comes).
>
> regards,
> conduition
>
>
>
> On Saturday, July 19th, 2025 at 8:13 AM, Peter Todd <pe...@petertodd•org>
> wrote:
>
> > On Mon, Jul 14, 2025 at 02:52:17PM -0400, Jameson Lopp wrote:
> >
> > > Correct, this time is different in that we're not talking about vague
> > > unknown weaknesses. Rather, we're talking about a known algorithm that
> > > makes breaking cryptographic primitives orders of magnitude cheaper.
> >
> >
> > We already have known algorithms that would break cryptographic
> primitives if
> > sufficiently good analog computers actually existed. Or for that matter,
> "split
> > the universe" brute forcing. No-one is worried about them because
> "sufficiently
> > good" analog computers and multiverses are widely belived to not be
> physically
> > realizable.
> >
> > For all the claims of progress on quantum computing hardware, the fact
> still
> > remains that no-one is even close to demonstrating cryptographic-relevant
> > quantum computing capabilities and the actual cryptographic-relevant
> > capabilities of real hardware are laughable. It's still an unknown
> whether or
> > not they are physically possible, and outside of the part of the physics
> > community that would like to sell you a quantum computer - or research
> > developing one - they're widely belived to be not physical.
> >
> > Hence, these are still vague unknown weaknesses. Until progress is less
> vague,
> > actively freezing peoples' coins is not going to happen.
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoindev+...@googlegroups•com.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/aHuKIKqvCZl5rcEX%40petertodd.org
> .
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1e39e6bd-8da4-45b1-9dc9-feacd923417dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6460 bytes --]
next prev parent reply other threads:[~2025-07-20 17:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-12 21:36 [bitcoindev] " Jameson Lopp
2025-07-13 23:19 ` [bitcoindev] " Tadge Dryja
2025-07-14 2:07 ` Antoine Riard
2025-07-14 16:08 ` Ethan Heilman
2025-07-15 2:50 ` Boris Nagaev
2025-07-14 18:52 ` Jameson Lopp
2025-07-19 12:05 ` Peter Todd
2025-07-20 15:56 ` 'conduition' via Bitcoin Development Mailing List
2025-07-20 17:39 ` Marin Ivezic [this message]
2025-07-14 13:50 ` Jameson Lopp
2025-07-15 2:32 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2025-07-15 14:13 ` Boris Nagaev
2025-07-16 16:43 ` 'conduition' via Bitcoin Development Mailing List
2025-07-16 17:34 ` Boris Nagaev
2025-07-20 15:37 ` 'conduition' via Bitcoin Development Mailing List
2025-07-15 17:57 ` Ethan Heilman
2025-07-20 22:54 ` [bitcoindev] " Boris Nagaev
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=1e39e6bd-8da4-45b1-9dc9-feacd923417dn@googlegroups.com \
--to=marin@appliedquantum$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/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