Well, apparently, Nic Carter has saved Bitcoin because in the last few weeks it seems like a new quantum resistance proposal for Bitcoin has been floated every other day.

Today's contender is this precommitment scheme from @csuwildcat:

A useful intermediate property is the ability to create outputs today that already commit to a future post-quantum authorization structure, even if Bitcoin does not yet define that structure's validation rules.

BIP 342 provides one such hook:

• any non-zero-length public key whose length is not 32 bytes is an unknown tapscript public key type, and
• signature validation for unknown public key types is currently treated as successful when the provided signature element is non-empty.

This allows a script to commit today to future validation slots that can later become stricter under soft-forked rules.

The pre-commitment concept seems pretty cool. Takes away the rush to migrate, as people could start using this construction now without any changes to Bitcoin script.

The construction uses:

• one mandatory secp256k1 Schnorr signature slot, and
• one or more additional slots encoded as unknown tapscript public key types that commit to future SLH-DSA (SPHINCS+) verification keys.

So, you could stick a quantum resistant signature in one of your transactions today (or I think this is even just a matter of sticking in a quantum resistant public key) and then later, when the Bitcoin network decides to soft fork in the quantum resistance scheme that matches your signature type, your transactions all become quantum resistant.

As far as I understand it, you would still need to use a quantum-resistant signature scheme when you generate this public key that you embed in your tapscript. And you would need to make sure you hang on to the private key for it. And you'd have to hope that the style of signature you use is what eventually gets soft-forked "on." And also, I don't think this solves the taproot address keypath spending problem (so that would still have to be turned off via a soft fork).

Risks And LimitationsRisks And Limitations

• The construction depends on a future soft fork to assign real semantics to the slot-key encodings.
• It depends on a future design for annex-based or otherwise relocated SLH-DSA (SPHINCS+) signature transport.
• It is limited to SLH-DSA (SPHINCS+) because only those raw public-key sizes fit the current approach.
• It does not, on its own, address long-range Taproot output-key exposure.