One of the things that gets people really worked up about the quantum threat to Bitcoin is that a lot of the mitigations require everyone to move all their coins...and the coins that don't move become vulnerable to theft.

Roasbeef proposed a new method for Bitcoiners to adopt a quantum resistant scheme without requiring everyone to move their coins before the threat arrives, but which doesn't expose people who don't move their coins to loss of coins. It requires a soft fork.

In some ways it reminds me of Casey Rodarmor's proposal (#1445101), although they are pretty different from each other.

Here's a bit of a refresher on Taproot addresses, skip down to the section about Roasbeef's method if you already know this.

Two different ways of spending coins in Taproot addressesTwo different ways of spending coins in Taproot addresses

One of the cool things about Taproot addresses is that you don't have to reveal all the different ways your coins can be spent. You might have coins that can be spent with any 2 of five different signatures, or just 1 signature after 16 months. You can have a lot of possible ways to spend your coins, but none of this is directly stored in the output's locking script on chain.

What does get stored is a single public key. Using cryptographic magic this public key is created by taking a standard public key and "tweaking" it with the Merkle root of all your different locking scripts.

Any of the locking scripts can be satisfied to move your coins...or you can use the private key that corresponds to your address's tweaked public key.

The two ways to spend from a Taproot addressThe two ways to spend from a Taproot address

1. Use the script path by satisfying a script that is a leaf in Merkle tree who's root is hashed and tweaked to become your public key, or
2. Use the key path by providing a signature from the specific private key that matches this public key

Taproot and quantum vulnerabilityTaproot and quantum vulnerability

You've probably heard by now that Taproot addresses are vulnerable to quantum computers (should such computers ever become large enough and stable enough to derive private keys from bitcoin public keys). The reason for this is because of that second way you can spend coins in Taproot addresses: the tweaked hash that merkle root for all your spending paths is also a real public key and it's stored on chain for all to see.

Roasbeef's method for quantum-proofing Taproot addressesRoasbeef's method for quantum-proofing Taproot addresses

Given that the Taproot commitment scheme is post-quantum secure, in the future we can deploy a soft fork to disable the keyspend path, and force all Taproot spends to instead flow through the script path (not my idea, commonly discussed amongst developers, not sure who proposed it first). At that point, Taproot starts to resemble BIP-360.

That works for script path spends, but then leaves all the BIP-86 wallets in a bad position, as they generated outputs that provably don't commit to a script path at all.

 A 2023 paper (Protecting Quantum Procrastinators with Signature Lifting: A Case Study in Cryptocurrencies) proposed a solution to this, namely seed lifting (use BIP-32 as the one-way function to the Picnic PQ Signature scheme) to provide a post-quantum proof of secret information a quantum attacker wouldn't be able to easily obtain.

The downside of that is that it reveals the secret BIP 32 seed, exposing other non migrated UTXOs of a user.

With this project I've cobbled together a series of projects to be able to generate a zk-STARK proof that a Taproot output public key was generated via BIP-32 invocation of a BIP-86 derivation path.

In the future a variant of this scheme can be used to enable wallets that generated the private keys via BIP-86, to have a post quantum safe exit path in case they don't bother moving their coins in time to the yet-to-be-decided post quantum signature scheme.

Read his whole proposal on the mailing list. I do like these proposals that don't involve abandoning people who don't migrate (although, I guess since this only applies to Taproot addresses, it wouldn't help with addresses that have exposed public keys for other reasons and yet are unwilling or unable to migrate).