From: Sjors Provoost <sjors@sprovoost•nl>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Jameson Lopp <jameson.lopp@gmail•com>,
Matt Corallo <lf-lists@mattcorallo•com>
Subject: Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin
Date: Tue, 18 Mar 2025 13:48:12 +0100 [thread overview]
Message-ID: <ED96C777-5BBD-4ACE-8821-A53FDE8FA128@sprovoost.nl> (raw)
In-Reply-To: <43afd5bb-244e-4698-ba3d-139efa2c2058@mattcorallo.com>
> Op 17 mrt 2025, om 13:00 heeft Matt Corallo <lf-lists@mattcorallo•com> het volgende geschreven:
>
> I think this is a strong motivation to do "simple PQC" today - while we don't need to decide on the tough question of seizing non-PQC coins today, we want to have the option to do so in the future.
>
> In order for that option to be practical, wallets need to be embedding PQC public keys in their outputs probably at least a decade before the seizure occurs, with any additional time giving us an important safety margin.
I don't think that in practice we can deploy a PCQ scheme without at the same time making a decision with regards to burn vs free-for-all. The best we can do is to have all that stuff well researched and tested long before on a signet.
Let's say the burn consensus rule is that no pk(), bare multisig, pkh()*, wpkhk() output can be spent, in addition to any tr() key path.
To be triggered at some point far enough in the future that people can migrate, but not too late. Let's ignore for now that this will be very hard to agree on, because people will disagree on the nature and timing of the threat until it's undeniable.
In principe a PQC (Post-quantum cryptography) tap leaf scheme could be proposed in a BIP and activated in a soft-fork, without having to decide on the burn issue. Any time your wallet needs to generate a new address, it could add such a tap leaf just in case.
But this adds a bunch of complexity to wallets, makes descriptor backups longer, etc. So adoption might be minimal. And since no sane person spends from the PQC path, we'd have no idea how much adoption there is.
More importantly, the activation of a PQC tapleaf soft fork would not be sufficient to permanently migrate coins. That's because in a free-for-all quantum scenario it's the wrong approach. The quantum attacker would just spend from your key path.
In that scenario you'd need to use a NUMS point for the key path. Or maybe that's unsafe, in which case we'd need a new Taproot version without key path support (or BIP360). That's also not a difficult soft fork, but now again you have something that only a small set of users will want to use.
This new address type is only suitable for very long term storage since it's more expensive to use in a pre-quantum world (using the a regular Schnorr signature in a script path).
So now we'd have two soft forks that ~nobody uses, because it's a bunch of extra wallet complexity and you don't know if you should use the tapleaf or the taproot-without-keypath address for your cold storage.
I doubt that soft forks which nobody intends to use will be activated anytime soon.
- Sjors
---
*
See appendix B of BIP380 for notation: https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki#appendix-b-index-of-script-expressions
Since we don't know which public keys are reused, the pkh() underlying public key can be brute force guessed by trying all known keys. There is also no alternative spending path. So it should be included in the burn.
sh() and wsh() would not be frozen. Some scripts may be guessable from context, but imo that doesn't outweigh the possibly that someone designed a quantum proof script - even a bad one.
Neither would any scriptPubKey that's different from the above standard templates. This allows implementing the freeze rule in a way that doesn't require deep / complicated inspection of the script
--
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/ED96C777-5BBD-4ACE-8821-A53FDE8FA128%40sprovoost.nl.
prev parent reply other threads:[~2025-03-18 12:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-16 14:15 Jameson Lopp
2025-03-16 19:44 ` Nagaev Boris
2025-03-16 21:25 ` Jameson Lopp
2025-03-16 22:56 ` IdeA
2025-03-17 13:28 ` Jameson Lopp
2025-03-17 12:00 ` Matt Corallo
2025-03-18 12:48 ` Sjors Provoost [this message]
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=ED96C777-5BBD-4ACE-8821-A53FDE8FA128@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoindev@googlegroups.com \
--cc=jameson.lopp@gmail$(echo .)com \
--cc=lf-lists@mattcorallo$(echo .)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