The BIP nvk mentioned, [BIP 360](https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki), wants to disable it:

> This document proposes a new output type: Pay-to-Merkle-Root (P2MR), via a soft fork. P2MR outputs operate with nearly the same functionality as P2TR (Pay-to-Taproot) outputs, but with the key path spend removed.

They could be forbidden at the protocol level, but they cannot be prevented at a per-output level by the user.

I see. Does this mean that there is no way to disable a keypath spend for taproot addresses in a way that is relevant to quantum attacks?

Scoresby

If this is correct, as I assume it is (maybe somebody more familiar with tapscript can correct me if not), it's trivial to use taproot too in a "quantum safe" 😂😂 way.

Giacomo is mistaken here. You can use P2TR with the keypath rendered unusable (to the output owner) by using a NUMS point as the basis for the script tree tweak. However, even if you use a NUMS point, it must be a valid point for the script path to work. While the output script owner can prove that no human could have known the private key corresponding to the NUMS point, a CRQC could still calculate and use the private key to spend via the keypath.

bitcoin

Even more people talking about quantum computers and Bitcoin today

> If this is correct, as I assume it is (maybe somebody more familiar with tapscript can correct me if not), it's trivial to use taproot too in a "quantum safe" 😂😂 way.

Giacomo is mistaken here. You can use P2TR with the keypath rendered unusable (to the output owner) by using a NUMS point as the basis for the script tree tweak. However, even if you use a NUMS point, it must be a valid point for the script path to work. While the output script owner can prove that no human could have known the private key corresponding to the NUMS point, a CRQC could still calculate and use the private key to spend via the keypath.