Changes to BIP-360 - Pay to Quantum Resistant Hash (P2QRH)

The discussion revolves around the intricacies of Bitcoin Improvement Proposals (BIPs) and their role in preparing Bitcoin for a post-quantum world. The core of the debate is on the proposal's aim to introduce measures that ensure Bitcoin transactions remain secure in the face of quantum computing advancements, without necessarily having an opinion on how to address quantum-vulnerable outputs directly. This approach allows for progress in specific areas while sidestepping the contentious issue of whether to freeze or not freeze certain types of transactions.

One suggested advantage of introducing a separate output type is its potential to disable existing checksig opcodes within scripts, paving the way for future protocol rules that mandate sending to quantum-safe output types only, thereby encouraging migration. However, due to the anticipated high fee costs associated with quantum-resistant signatures, widespread adoption is unlikely until quantum computing poses a direct threat. The proposal aims to mitigate this through the P2QRH (Pay to Quantum Resistant Hash), which offers a method to transact in a quantum-secure manner without incurring high fees by also allowing spending via Schnorr signatures. This dual capability could facilitate a smoother transition to quantum-resistant practices without imposing significant costs on users, exchanges, and other stakeholders.

Furthermore, if a decision were made to freeze quantum-vulnerable spends in the future, funds held in P2QRH outputs equipped with post-quantum signature mechanisms would already be safeguarded without necessitating emergency migrations. A major concern raised against disabling Schnorr in P2QRH is the potential delay in adoption due to the significantly higher transaction fees, which would likely result in a lack of support from wallets, exchanges, and lightning networks until absolutely necessary, increasing the risk of disaster when a rapid migration is eventually required.

The proposal also touches on the benefits of having two different spend types within the P2QRH Merkle tree structure: a cooperative (key spend) path that is more cost-effective and simpler, and an uncooperative (script spend) path that is more complex and slightly more expensive. This design incentivizes the use of the cooperative path while acknowledging the potential need for script-only tapscript outputs without a cooperative path.

Finally, the discussion considers an alternative strategy involving P2TR (Pay to Taproot), suggesting that it could be deemed safe under the assurance that key path spends would be disabled in the event of a credible quantum threat. This could be enforced through a quantum bounty mechanism. However, implementing such a softfork to disable key spends via a quantum bounty is viewed as more complex and risky compared to adopting P2QRH directly. Without an automatic disable switch, the reliance on a promise to disable key spends appears insufficient, underscoring the preference for a solution like P2QRH that inherently addresses both current usability and future quantum security concerns.