Two points. First of all, I’m somewhat confident we’ll learn that a CRQC is imminent with some time left prior to theft being actually possible, see nostr:nevent1qqs8cxj6ukqvh65l3ypqervzdly3fqpru34jv0avlve30u6lttpxe4cpzamhxue69uhkummnw3ezuendwsh8w6t69e3xj7spzamhxue69uhhyetvv9ujucm4wfex2mn59en8j6gpr3mhxue69uhkummnw3ezumt4w35ku7thv9kxcet59e3k7mgprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvg034fh

Secondly, I would be surprised, though it’s certainly possible, if a QC is only able to steal coins after a year of constant compute. While they won’t be instant, maintaining coherence for long is one of the key challenges, so compute being longer than minutes to break a key (with some probability, maybe it takes some number of tries, though) seems somewhat unlikely.

Finally, its worth pointing out that one of the best ways we have to ensure people retain access to their bitcoin (allowing proof-of-seedphrase to allow for spends) *requires* that we freeze vulnerable spend paths before they can be otherwise stolen. So I think that should weigh pretty heavily in favor of freezing.

Of course, however, we cannot decide this for any future community and I think we agree it’s *highly* dependent on the particulars of what public information is available and what the timelines look like. The best we can do is speculate on likely scenarios and then decide what we think should happen in them.

Sadly, the freeze-vs-not decision is important today, because it impacts what choices we have available to begin preparing - if freezing is highly likely, we can “hide” QC safety in taproot leaves today without impacting wallets. If it’s not, it has to be a separate address type which has *huge* deployment timeline challenges (there’s *still* exchanges that can’t send to taproot addresses, for example…)