diff --git a/README.mediawiki b/README.mediawiki index 42c54577f6..8e7cb986d8 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1172,7 +1172,7 @@ Those proposing changes should consider that ultimately consent may rest with th |- | [[bip-0360.mediawiki|360]] | Consensus (soft fork) -| Pay to Quantum Resistant Hash +| Pay to Tap Script Hash | Hunter Beast, Ethan Heilman | Standard | Draft diff --git a/bip-0360.mediawiki b/bip-0360.mediawiki index 58a3bb971e..c0bfe016b4 100644 --- a/bip-0360.mediawiki +++ b/bip-0360.mediawiki @@ -1,6 +1,6 @@ 
   BIP: 360
-  Title: Pay to Quantum Resistant Hash
+  Title: Pay to Tap Script Hash
   Layer: Consensus (soft fork)
   Author: Hunter Beast 
           Ethan Heilman 
@@ -16,11 +16,11 @@
 
 === Abstract ===
 
-This document proposes the introduction of a new output type, Pay to Quantum Resistant Hash (P2QRH), via a soft fork.
-P2QRH provides the same tapscript functionality as Pay to TapRoot (P2TR) but removes the quantum-vulnerable
-key-spend path in P2TR. By itself, P2QRH provides protection against long-exposure quantum attacks, 
+This document proposes the introduction of a new output type, Pay to Tap Script Hash (P2TSH), via a soft fork.
+P2TSH provides the same tapscript functionality as Pay to TapRoot (P2TR) but removes the quantum-vulnerable
+key-spend path in P2TR. By itself, P2TSH provides protection against long-exposure quantum attacks,
 but requires PQ signatures to provide full security against Cryptanalytically-Relevant Quantum Computing (CRQCs).
-P2QRH is designed to provide the foundation necessary for a future soft fork activating PQ signature verification 
+P2TSH is designed to provide the foundation necessary for a future soft fork activating PQ signature verification
 in tapscript.
 
 === Copyright ===
@@ -42,7 +42,7 @@ key length (e.g., using a hypothetical secp512k1 curve) would only make deriving
 offering insufficient protection. The computational complexity of this attack is further explored in
 [https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching ''The impact of hardware specifications on reaching quantum advantage in the fault-tolerant regime''].
 
-This proposal aims to mitigate these risks by introducing a Pay to Quantum Resistant Hash (P2QRH) output type that
+This proposal aims to mitigate these risks by introducing a Pay to Tap Script Hash (P2TSH) output type that
 makes tapscript quantum resistant and enables the use of PQ signature algorithms. By adopting PQC, Bitcoin can enhance its quantum
 resistance without requiring a hard fork or block size increase.
 
@@ -61,7 +61,7 @@ public key is exposed on the blockchain when the transaction is spent, making it
 it's mined. One way to mitigate this is to submit the transaction directly to a mining pool, bypassing the mempool.
 This process is known as an out-of-band transaction or a private mempool. In this case, the mining pool must be trusted
 not to reveal the transaction public key to attackers. The problem with this approach is that it requires a trusted
-third party, which the P2QRH proposal aims to avoid. It also doesn't account for block reorg attacks, which would
+third party, which the P2TSH proposal aims to avoid. It also doesn't account for block reorg attacks, which would
 reveal public keys in blocks that were once mined but are now orphaned and must be mined again. Additionally,
 it depends on the mining pool whether they reveal their block template to either the public or to miners.
 
@@ -83,7 +83,7 @@ As the value being sent increases, so too should the fee in order to commit the
 possible. Once the transaction is mined, it makes useless the public key revealed by spending a UTXO, so long as it is
 never reused.
 
-As the first step to address these issues we propose Pay to Quantum Resistant Hash (P2QRH), an output type that allows 
+As the first step to address these issues we propose Pay to Tap Script Hash (P2TSH), an output type that allows
 tapscript to be used in a quantum resistant manner.
 This new output type protects transactions submitted to the mempool and helps preserve the fee market by
 preventing the need for private, out-of-band mempool transactions.
@@ -110,7 +110,7 @@ quantum attack:
 |-
 | P2TR || Yes || bc1p || bc1p92aslsnseq786wxfk3ekra90ds9ku47qttupfjsqmmj4z82xdq4q3rr58u
 |-
-| P2QRH || No || bc1r || bc1r8rt68aze8tek87cnz4ndnvfzk6tk93jv39n4lmpu5a4yw453rcpszsft3z
+| P2TSH || No || bc1r || bc1r8rt68aze8tek87cnz4ndnvfzk6tk93jv39n4lmpu5a4yw453rcpszsft3z
 |}
 
 ¹ Funds in P2PKH, P2SH, P2WPKH, and P2WSH outputs become vulnerable to long-exposure quantum attacks when their input script is revealed. An address is no longer safe against long-exposure quantum attacks after funds from it have been spent.
@@ -132,7 +132,7 @@ A Long Exposure Quantum Attack is an attack in which the public key has been exp
 period of time, giving an attacker ample opportunity to break the cryptography. This affects:
 
 * P2PK outputs (Satoshi's coins, CPU miners, starts with 04)
-* Reused addresses (any type, except P2QRH)
+* Reused addresses (any type, except P2TSH)
 * Taproot addresses (starts with bc1p)
 * Extended public keys, commonly known as "xpubs"
 * Wallet descriptors
@@ -140,7 +140,7 @@ period of time, giving an attacker ample opportunity to break the cryptography.
 A Short Exposure Quantum Attack is an attack that must be executed quickly while a transaction is still in the mempool,
 before it is mined into a block. This affects:
 
-* Any transaction in the mempool (except for P2QRH)
+* Any transaction in the mempool (except for P2TSH)
 
 Short-exposure attacks require much larger, more expensive CRQCs since they must be executed within the short window
 before a transaction is mined. Long-exposure attacks can be executed over a longer timeframe since the public key remains
@@ -176,23 +176,23 @@ using Grover's algorithm would require at least 10^24 quantum operations. As for
 
 This is the first in a series of BIPs under a QuBit soft fork. A qubit is a fundamental unit of quantum computing, and
 the capital B refers to Bitcoin. The name QuBit also rhymes to some extent with SegWit. This BIP proposes a new output type
-called P2QRH (Pay to Quantum Resistant Hash). This output type is designed to support post-quantum signature algorithms
+called P2TSH (Pay to Tap Script Hash). This output type is designed to support post-quantum signature algorithms
 but those algorithms will be specified in future BIPs.
 
 It is proposed to use SegWit version 3. This results in addresses that start with bc1r, which could be a useful way to
 remember that these are quantum (r)esistant addresses. This is referencing the lookup table under
 [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173].
 
-P2QRH (Pay to Quantum Resistant Hash) is a new output type that commits to the root of a tapleaf merkle tree. It is functionally
-the same as a P2TR (Pay to Taproot) output with the quantum vulnerable key-spend path removed. Since P2QRH has no key-spend path, P2QRH omits the
-taproot internal key as it is not needed. Instead a P2QRH output is just the 32 byte root of the tapleaf merkle tree as defined
+P2TSH (Pay to Tap Script Hash) is a new output type that commits to the root of a tapleaf merkle tree. It is functionally
+the same as a P2TR (Pay to Taproot) output with the quantum vulnerable key-spend path removed. Since P2TSH has no key-spend path, P2TSH omits the
+taproot internal key as it is not needed. Instead a P2TSH output is just the 32 byte root of the tapleaf merkle tree as defined
 in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341] and hashed with the tag "QuantumRoot" as shown below.
 
 [[File:bip-0360/merkletree.png|center|550px|thumb|]]
 
-To construct a P2QRH output we follow the same process as [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341]
+To construct a P2TSH output we follow the same process as [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341]
 to compute the tapscript merkle root. However, instead of the root of the Merkle tree being hashed together with the internal
-key in P2QRH the root is hashed by itself using the tag "QuantumRoot".
+key in P2TSH the root is hashed by itself using the tag "QuantumRoot".
 
 
 D = tagged_hash("TapLeaf", bytes([leaf_version]) + ser_script(script))
@@ -202,7 +202,7 @@ ABCDE = tagged_hash("TapBranch", AB + CDE)
 Root = tagged_hash("QuantumRoot", ABCDE)
 
 
-A P2QRH input witness provides the following:
+A P2TSH input witness provides the following:
 
 
 initial stack element 0,
@@ -216,89 +216,89 @@ The initial stack elements provide the same functionality as they do in P2TR. Th
 be evaluated by the tapleaf script, a.k.a. the redeem script.
 
 The control block is a 1 + 32 * m byte array, where the first byte is the control byte and the next 32*m bytes are the
-Merkle path to the tapleaf script. The control byte is the same as the control byte in a P2TR control block, 
+Merkle path to the tapleaf script. The control byte is the same as the control byte in a P2TR control block,
 including the 7 bits are used to specify the tapleaf version. The parity bit of the control byte is always 1
-since P2QRH does not have a key-spend path. We omit the public key from the control block as it is not needed in P2QRH.
+since P2TSH does not have a key-spend path. We omit the public key from the control block as it is not needed in P2TSH.
 We maintain support for the optional annex in the witness (see specification for more details).
 
 === Rationale ===
 
 Our design to augment Bitcoin with quantum resistance is guided by the following principles:
 
-'''Minimize changes.''' We should reuse existing Bitcoin code and preserve 
+'''Minimize changes.''' We should reuse existing Bitcoin code and preserve
 existing software behavior, workflows, user expectations and compatibility whenever possible.
 
-'''Gradual upgrade path.''' We should provide an upgrade path for wallets and exchanges which can be 
+'''Gradual upgrade path.''' We should provide an upgrade path for wallets and exchanges which can be
 carried out gradually and iteratively rather than all at once. This is critical as the earlier the ecosystem
 begins upgrading to quantum resistance, the lower the number of coins at risk when quantum attacks become practical.
 
-'''Use standardized post-quantum signature algorithms.'''  Standardized algorithms have undergone the most scrutiny and 
+'''Use standardized post-quantum signature algorithms.'''  Standardized algorithms have undergone the most scrutiny and
 are likely to be most well supported and well studied going forward. The entire Bitcoin ecosystem will benefit
-from using the most popular post-quantum signature algorithms, including leveraging hardware acceleration 
+from using the most popular post-quantum signature algorithms, including leveraging hardware acceleration
 instructions, commodity trusted hardware, software libraries and cryptography research.
 
 '''Provide security against unexpected cryptanalytic breakthroughs.''' Consider the risk
 if Bitcoin only supported one PQ signature algorithm, and then following the widespread rollout of CRQCs, a critical
-weakness is unexpectedly discovered in this signature algorithm. There would be no safe algorithm available. We believe that 
-prudence dictates we take such risks seriously and ensure that Bitcoin always has at least two secure signature algorithms built 
-on orthogonal cryptographic assumptions. In the event one algorithm is broken, an alternative will be available. An added benefit 
-is that parties seeking to securely store bitcoins over decades can secure their coins under multiple algorithms, 
+weakness is unexpectedly discovered in this signature algorithm. There would be no safe algorithm available. We believe that
+prudence dictates we take such risks seriously and ensure that Bitcoin always has at least two secure signature algorithms built
+on orthogonal cryptographic assumptions. In the event one algorithm is broken, an alternative will be available. An added benefit
+is that parties seeking to securely store bitcoins over decades can secure their coins under multiple algorithms,
 ensuring their coins will not be stolen even in the face of a catastrophic break in one of those signature algorithms.
 
 Based on these principles, we propose two independent changes that together provide Bitcoin with
-full quantum resistance. In this BIP, we introduce a new output type called P2QRH (Pay to Quantum Resistant Hash) so that tapscript
+full quantum resistance. In this BIP, we introduce a new output type called P2TSH (Pay to Tap Script Hash) so that tapscript
 can be used in a quantum resistant manner. In a future BIP, we enable tapscript programs to verify two Post-Quantum (PQ) signature
-algorithms, ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+). It is important to consider these two changes together because P2QRH must
+algorithms, ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+). It is important to consider these two changes together because P2TSH must
 be designed to support the addition of these PQ signature algorithms. The full description of these signatures will be provided in a future BIP.
 
-==== P2QRH ====
+==== P2TSH ====
 
-P2QRH is simply P2TR with the quantum vulnerable key-spend path removed so that it commits to the root of 
-the tapleaf merkle tree in the output. This allows P2QRH to reuse the mature and battle tested P2TR, tapleaf 
-and tapscript code already in Bitcoin. This reduces the implementation burden on wallets, exchanges, and 
+P2TSH is simply P2TR with the quantum vulnerable key-spend path removed so that it commits to the root of
+the tapleaf merkle tree in the output. This allows P2TSH to reuse the mature and battle tested P2TR, tapleaf
+and tapscript code already in Bitcoin. This reduces the implementation burden on wallets, exchanges, and
 libraries since they can reuse code they already have.
 
-Both P2WSH (Pay 2 Witness Script Hash) and P2QRH protect against long-exposure quantum attacks and both provide 
+Both P2WSH (Pay 2 Witness Script Hash) and P2TSH protect against long-exposure quantum attacks and both provide
 the same 256-bit security level. One may ask why not use the existing output type P2WSH instead of add a new one?
 The problem with P2WSH is that it only works with pre-tapscript Script and cannot work with tapscript Script.
 New protocols and programs in the Bitcoin ecosystem have largely moved to tapscript. Using P2WSH would require turning
 back the clock and forcing projects to move from tapscript to pre-tapscript. More importantly, tapscript provides a far
 easier and safer upgrade path for adding PQ signatures. Changes to pre-tapscript to enable it to support PQ signatures would likely
-require adding tapscript features into pre-tapscript. Even if this was possible, it would represent far more work and 
-risk than adding a new output type like P2QRH. Tapscript, and thereby a tapscript compatible output such as P2QRH, 
+require adding tapscript features into pre-tapscript. Even if this was possible, it would represent far more work and
+risk than adding a new output type like P2TSH. Tapscript, and thereby a tapscript compatible output such as P2TSH,
 is the most plausible and convenient upgrade path to full quantum resistance.
 
 ==== PQ signatures ====
 
-By separating P2QRH from the introduction of PQ signatures, relying parties can move from P2TR to P2QRH 
-without simultaneously having to change from Schnorr signatures to PQ signatures. Simply moving coins from 
-P2TR to P2QRH protects those coins from long-exposure quantum attacks. Then to gain full quantum resistance, 
-verification of PQ signatures can be added as an additional tapleaf alongside Schnorr signaturesMatt Corallo, [https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/rTrpeFjWDAAJ Trivial QC signatures with clean upgrade path], (2024). 
-When quantum attacks become practical, users would then be fully protected as the P2QRH output would allow
-them to switch to sending their coins using the PQ signature algorithms. This allows the upgrade to quantum 
+By separating P2TSH from the introduction of PQ signatures, relying parties can move from P2TR to P2TSH
+without simultaneously having to change from Schnorr signatures to PQ signatures. Simply moving coins from
+P2TR to P2TSH protects those coins from long-exposure quantum attacks. Then to gain full quantum resistance,
+verification of PQ signatures can be added as an additional tapleaf alongside Schnorr signaturesMatt Corallo, [https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/rTrpeFjWDAAJ Trivial QC signatures with clean upgrade path], (2024).
+When quantum attacks become practical, users would then be fully protected as the P2TSH output would allow
+them to switch to sending their coins using the PQ signature algorithms. This allows the upgrade to quantum
 resistance to be largely invisible to users.
 
-Consider the P2QRH output with three tapscripts:
+Consider the P2TSH output with three tapscripts:
 
 * Spend requires a Schnorr signature
 * Spend requires a ML-DSA signature
 * Spend requires a SLH-DSA signature
 
-In the event that Schnorr signatures are broken, users can spend their coins using ML-DSA. 
+In the event that Schnorr signatures are broken, users can spend their coins using ML-DSA.
 If both Schnorr and ML-DSA are broken, the user can still rely on SLH-DSA.
 While this pattern allows users to spend their coins securely without revealing the public
 keys associated with vulnerable algorithms, the user can compromise their own security if
 they leak these public keys in other contexts, e.g. key reuse.
 
-One intent in supporting Schnorr, ML-DSA, and SLH-DSA in tapscript, is to allow parties to construct outputs such that funds 
+One intent in supporting Schnorr, ML-DSA, and SLH-DSA in tapscript, is to allow parties to construct outputs such that funds
 are still secure even if two of the three the signature algorithms are completely broken. This is motivated by the use case
 of securely storing Bitcoins in a cold wallet for very long periods of time (50 to 100 years).
 
-For PQ signatures we considered the NIST approved SLH-DSA (SPHINCS+), ML-DSA (CRYSTALS-Dilithium), 
-FN-DSA (FALCON). Of these three algorithms, SLH-DSA has the largest signature size, but is the most conservative 
-choice from a security perspective because SLH-DSA is based on well studied and time-tested hash-based cryptography. 
-Both FN-DSA and ML-DSA signatures are significantly smaller than SLH-DSA signatures but are based on newer lattice-based 
-cryptography. Since ML-DSA and FN-DSA are both similar lattice-based designs, we choose to only support one of them as the 
+For PQ signatures we considered the NIST approved SLH-DSA (SPHINCS+), ML-DSA (CRYSTALS-Dilithium),
+FN-DSA (FALCON). Of these three algorithms, SLH-DSA has the largest signature size, but is the most conservative
+choice from a security perspective because SLH-DSA is based on well studied and time-tested hash-based cryptography.
+Both FN-DSA and ML-DSA signatures are significantly smaller than SLH-DSA signatures but are based on newer lattice-based
+cryptography. Since ML-DSA and FN-DSA are both similar lattice-based designs, we choose to only support one of them as the
 additional value in diversity of cryptographic assumptions would be marginal. It should be noted that ML-DSA and FN-DSA do
 rely on different lattice assumptions and it may be that case that a break in one algorithm's assumptions would not necessarily
 break the assumptions used by the other other algorithm.
@@ -307,22 +307,22 @@ We also considered SQIsign. While it outperforms the three other PQ signature al
 it has the worst verification performance and requires a much more complex implementation. We may revisit SQIsign separately in the
 future as recent research shows massive performance improvements to SQIsign in version 2.0. "[SQIsign] signing is now nearly 20× faster, at 103.0 Mcycles, and verification is more than 6× faster, at 5.1 Mcycles" [https://csrc.nist.gov/csrc/media/Projects/pqc-dig-sig/documents/round-2/spec-files/sqisign-spec-round2-web.pdf SQIsign: Algorithm specifications and supporting documentation Version 2.0 (February 5 2025)].
 
-ML-DSA is intended as the main PQ signature algorithm in Bitcoin. It provides a good balance of security, performance 
-and signature size and is likely to be the most widely supported PQ signature algorithm on the internet. SLH-DSA has a radically 
+ML-DSA is intended as the main PQ signature algorithm in Bitcoin. It provides a good balance of security, performance
+and signature size and is likely to be the most widely supported PQ signature algorithm on the internet. SLH-DSA has a radically
 different design and set of cryptographic assumptions than ML-DSA. As such SLH-DSA provides an effective
 hedge against an unexpected cryptanalytic breakthrough.
 
-P2QRH, ML-DSA, and SLH-DSA could be activated simultaneously in a single soft fork or P2QRH could be activated first and then
+P2TSH, ML-DSA, and SLH-DSA could be activated simultaneously in a single soft fork or P2TSH could be activated first and then
 ML-DSA and SLH-DSA could be independently activated. If at some future point another signature
 algorithm was desired it could follow this pattern.
 
 We consider two different paths for activating PQ signatures in Bitcoin. The first approach is to redefine OP_SUCCESSx opcodes for each
-signature algorithm. For ML-DSA this would give us OP_CHECKMLSIG, OP_CHECKMLSIGVERIFY and OP_CHECKMLSIGADD. The second approach is to use a new tapleaf version that changes the OP_CHECKSIG opcodes to support the 
+signature algorithm. For ML-DSA this would give us OP_CHECKMLSIG, OP_CHECKMLSIGVERIFY and OP_CHECKMLSIGADD. The second approach is to use a new tapleaf version that changes the OP_CHECKSIG opcodes to support the
 new PQ signature algorithms. In both cases, we would need to include as part of the soft fork an increase in the tapscript stack element
 size to accommodate the larger signatures and public keys sizes of the PQ signature algorithms.
 
 The OP_SUCCESSx approach has the advantage of providing a straightforward path to add new signature algorithms in the future. Simply redefine
-a set of five OP_SUCCESSx opcodes for the new signature algorithm. This would allow us to activate a single PQ signature at a time, adding 
+a set of five OP_SUCCESSx opcodes for the new signature algorithm. This would allow us to activate a single PQ signature at a time, adding
 new ones as needed. Additionally this approach allows developers to be very explicit in the signature algorithm type that they wish to verify.
 The main disadvantage is that it uses five OP_SUCCESSx opcodes per signature algorithm. Supporting ML-DSA and SLH-DSA would require ten new opcodes.
 
@@ -331,12 +331,12 @@ by simply using the new tapleaf version. Instead of developers explicitly specif
 to use must be indicated within the public key or public key hash'''Why not have CHECKSIG infer the algorithm based on signature size?''' Each of the three signature algorithms, Schnorr, ML-DSA, and SLH-DSA, have unique signature sizes. The problem with using signature size to infer algorithm is that spender specifies the signature. This would allow a public key which was intended to be verified by Schnorr to be verified using ML-DSA as the spender specified a ML-DSA signature. Signature algorithms are not often not secure if you can mix and match public key and signature across algorithms..
 The disadvantage of this approach is that it requires a new tapleaf version each time we want to add a new signature algorithm.
 
-Both approaches must raise the stack element size limit. In the OP_SUCCESSx case, the increased size limit would only be effect for transaction outputs 
-that use of the new opcodes. Otherwise this stack element size limit increase would be a soft fork. If the tapleaf version is used, then the stack 
+Both approaches must raise the stack element size limit. In the OP_SUCCESSx case, the increased size limit would only be effect for transaction outputs
+that use of the new opcodes. Otherwise this stack element size limit increase would be a soft fork. If the tapleaf version is used, then the stack
 element size limit increase would apply to any tapscript program with the new tapleaf version.
 
-To improve the viability of the activation client and adoption by wallets and libraries, a library akin to 
-libsecp256k1 will be developed. This library, [https://github.com/cryptoquick/libbitcoinpqc libbitcoinpqc], will support the new PQ signature algorithms 
+To improve the viability of the activation client and adoption by wallets and libraries, a library akin to
+libsecp256k1 will be developed. This library, [https://github.com/cryptoquick/libbitcoinpqc libbitcoinpqc], will support the new PQ signature algorithms
 and can be used as a reference for other language-native implementations.
 
 ==== PQ signature size ====
@@ -345,24 +345,24 @@ Post-quantum public keys are generally larger than those used by ECC, depending
 proposed NIST Level V, 256-bit security, but this was changed to NIST Level I, 128-bit security due to concerns over the
 size of the public keys, the time it would take to verify signatures, and being generally deemed "overkill".
 
-We recognize that the size of ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+) signatures + public key pairs is a significant concern. 
-By way of comparison with Schnorr public key + signature pairs, SLH-DSA is roughly 80x larger and ML-DSA is roughly 40x larger. This means to 
+We recognize that the size of ML-DSA (CRYSTALS-Dilithium) and SLH-DSA (SPHINCS+) signatures + public key pairs is a significant concern.
+By way of comparison with Schnorr public key + signature pairs, SLH-DSA is roughly 80x larger and ML-DSA is roughly 40x larger. This means to
 maintain present transaction throughput, an increase in the witness discount may be desired.
 
-An increase in the witness discount must not be taken lightly. Parties may take advantage of this discount for purposes other than 
+An increase in the witness discount must not be taken lightly. Parties may take advantage of this discount for purposes other than
 authorizing transactions (e.g., storage of arbitrary data as seen with "inscriptions"). An increase in the witness discount would
 not only impact node runners but those with inscriptions would have the scarcity of their non-monetary assets affected.
 
-There was some hope of designing P2QRH such that discounted public keys and signatures could not be repurposed for the storage of 
+There was some hope of designing P2TSH such that discounted public keys and signatures could not be repurposed for the storage of
 arbitrary data by requiring that they successfully be verified before being written to Bitcoin's blockchain, a.k.a. "JPEG resistance".
-Later research Bas Westerbaan (2025), [https://groups.google.com/g/bitcoindev/c/5Ff0jdQPofo jpeg resistance of various post-quantum signature schemes] 
+Later research Bas Westerbaan (2025), [https://groups.google.com/g/bitcoindev/c/5Ff0jdQPofo jpeg resistance of various post-quantum signature schemes]
 provided strong evidence that this was not a feasible approach for the NIST approved Post-Quantum signature algorithms.
 It is an open question if Post-Quantum signature algorithms can be designed to provide JPEG resistance.
 
 ==== Raising tapscript's stack element size ====
 
 A problem faced by any attempt to add PQ signatures to tapscript is that the stack elements in tapscript cannot be larger than 520 bytes
-because the MAX_SCRIPT_ELEMENT_SIZE=520. This is problematic because PQ signature algorithms often have signatures and 
+because the MAX_SCRIPT_ELEMENT_SIZE=520. This is problematic because PQ signature algorithms often have signatures and
 public keys in excess of 520 bytes. For instance:
 
 * ML-DSA public keys are 1,312 bytes and signatures are 2,420 bytes
@@ -370,30 +370,30 @@ public keys in excess of 520 bytes. For instance:
 
 We will first look at our approach to the problem of PQ signatures and then give our solution for public keys larger than 520 bytes.
 
-To keep P2QRH small and simple, we have opted not to raise the stack element size limit as part of P2QRH, but instead make this change when 
-adding of PQ signatures. That said, we are not strongly opposed to putting this increase in P2QRH.
+To keep P2TSH small and simple, we have opted not to raise the stack element size limit as part of P2TSH, but instead make this change when
+adding of PQ signatures. That said, we are not strongly opposed to putting this increase in P2TSH.
 
-We propose a stack element size limit of 8,000 bytes. We arrive at 8,000 by rounding up from the needed 7,856 bytes. 
+We propose a stack element size limit of 8,000 bytes. We arrive at 8,000 by rounding up from the needed 7,856 bytes.
 
-OP_DUP will duplicate any stack element. Thus, if we allowed OP_DUP to duplicate stack elements of size 8,000 bytes, it would be possible 
-to write a tapscript which will duplicate stack elements until it reaches the maximum number of elements on stack, i.e. 1000 elements. 
+OP_DUP will duplicate any stack element. Thus, if we allowed OP_DUP to duplicate stack elements of size 8,000 bytes, it would be possible
+to write a tapscript which will duplicate stack elements until it reaches the maximum number of elements on stack, i.e. 1000 elements.
 An increase from 520 bytes to 8,000 bytes would increase the memory footprint from 520 KB to 8 MB.
 
-To prevent OP_DUP from creating an 8 MB stack by duplicating stack elements larger than 520 bytes we define OP_DUP to fail on stack 
+To prevent OP_DUP from creating an 8 MB stack by duplicating stack elements larger than 520 bytes we define OP_DUP to fail on stack
 elements larger than 520 bytes. Note this change to OP_DUP is not consensus critical and does not require any sort of fork. This is
 because currently there is no way to get a stack element larger than 520 bytes onto the stack so triggering this rule is currently
 impossible and would only matter if the stack element size limit was raised.
 
 ==== Public keys larger than 520 bytes ====
 
-Turning our attention to public keys larger than 520 bytes. This is not needed for SLH-DSA as its public key is only 32 bytes. 
+Turning our attention to public keys larger than 520 bytes. This is not needed for SLH-DSA as its public key is only 32 bytes.
 This is a different problem than signatures as public keys are typically pushed onto
 the stack by the tapleaf script (redeem script) to commit to public keys in output. The OP_PUSHDATA opcode in tapscript fails if asked to push
-more than 520 bytes onto the stack. 
+more than 520 bytes onto the stack.
 
 To solve this issue, for signature schemes with public keys greater than 520 bytes, we use the hash of the public key in the tapleaf script.
-We then package the public key and signature together as the same stack element on the input stack. Since the hash of the public key is 
-only 32 bytes, the tapleaf script can push it on the stack as it does today. Consider the following example with a 
+We then package the public key and signature together as the same stack element on the input stack. Since the hash of the public key is
+only 32 bytes, the tapleaf script can push it on the stack as it does today. Consider the following example with a
 OP_CHECKMLSIG opcode for ML-DSA:
 
 
@@ -409,35 +409,35 @@ tapscript = [OP_PUSHDATA HASH256(expected_pubkey), OP_CHECKMLSIG]
 Additional follow-on BIPs will be needed to implement PQ signature algorithms, signature aggregation, and full BIP-32 compatibility
 (if possible) BIP-32 relies on elliptic curve operations to derive keys from xpubs to support
 watch-only wallets, which PQC schemes may not support.. However, until specialized quantum cryptography hardware
-is widespread and signature aggregation schemes are thoroughly vetted, P2QRH addresses are an intermediate solution 
+is widespread and signature aggregation schemes are thoroughly vetted, P2TSH addresses are an intermediate solution
 to quantum threats.
 
 == Specification ==
 
-We define the Pay to Quantum Resistant Hash (P2QRH) output structure as follows.
+We define the Pay to Tap Script Hash (P2TSH) output structure as follows.
 
-=== Pay to Quantum Resistant Hash (P2QRH) ===
+=== Pay to Tap Script Hash (P2TSH) ===
 
-A P2QRH output is simply the root of the tapleaf Merkle tree defined in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341] 
+A P2TSH output is simply the root of the tapleaf Merkle tree defined in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341]
 and used as an internal value in P2TR.
 
-To construct a P2QRH output we follow the same process as [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341]
+To construct a P2TSH output we follow the same process as [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341]
 to compute the tapscript merkle root. However, instead of the root of the Merkle tree being hashed together with the internal
-key in P2QRH the root is hashed by itself using the tag "QuantumRoot" and then set as the witness program.
+key in P2TSH the root is hashed by itself using the tag "QuantumRoot" and then set as the witness program.
 
 === Address Format ===
 
-P2QRH uses SegWit version 3 outputs, resulting in addresses that start with bc1r, following
+P2TSH uses SegWit version 3 outputs, resulting in addresses that start with bc1r, following
 [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 BIP-173]. Bech32 encoding maps version 3 to the
 prefix r.
 
-Example P2QRH address:
+Example P2TSH address:
 
 bc1r... (32-byte Bech32m-encoded tapleaf merkle root)
 
 === ScriptPubKey ===
 
-The scriptPubKey for a P2QRH output is:
+The scriptPubKey for a P2TSH output is:
 
   OP_PUSHNUM_3 OP_PUSHBYTES_32 
 
@@ -448,8 +448,8 @@ Where:
 
 ==== Script Validation ====
 
-A P2QRH output is a native SegWit output (see [[bip-0141.mediawiki|BIP141]]) with version number 3, and a 32-byte witness program.
-Unlike taproot this witness program is the tapleaf merkle root. For the sake of comparison we have, as much as possible, copied the 
+A P2TSH output is a native SegWit output (see [[bip-0141.mediawiki|BIP141]]) with version number 3, and a 32-byte witness program.
+Unlike taproot this witness program is the tapleaf merkle root. For the sake of comparison we have, as much as possible, copied the
 language verbatim from the [[bip-0341.mediawiki|BIP341]] script validation section.
 
 * Let ''q'' be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents root of tapleaf merkle tree.
@@ -458,7 +458,7 @@ language verbatim from the [[bip-0341.mediawiki|BIP341]] script validation secti
 * There must be at least two witness elements left.
 ** Call the second-to-last stack element ''s'', the script (as defined in [[bip-0341.mediawiki|BIP341]])
 ** The last stack element is called the control block ''c'', and must have length ''1 + 32 * m'', for a value of ''m'' that is an integer between 0 and 128, inclusive. Fail if it does not have such a length.
-** Let ''v = c[0] & 0xfe'' be the ''leaf version'' (as defined in [[bip-0341.mediawiki|BIP-341]]). To maintain ''leaf version'' encoding compatibility the last bit of c[0] is unused and must be 1 '''Why set the last bit of c[0] to one?''' Consider a faulty implementation that deserializes the ''leaf version'' as c[0] rather than c[0] & 0xfe for both P2TR and P2QRH. If they test against P2QRH outputs and require that last bit is 1, this deserialization bug will cause an immediate error..
+** Let ''v = c[0] & 0xfe'' be the ''leaf version'' (as defined in [[bip-0341.mediawiki|BIP-341]]). To maintain ''leaf version'' encoding compatibility the last bit of c[0] is unused and must be 1 '''Why set the last bit of c[0] to one?''' Consider a faulty implementation that deserializes the ''leaf version'' as c[0] rather than c[0] & 0xfe for both P2TR and P2TSH. If they test against P2TSH outputs and require that last bit is 1, this deserialization bug will cause an immediate error..
 ** Let ''k0 = hashTapLeaf(v || compact_size(size of s) || s)''; also call it the ''tapleaf hash''.
 ** For ''j'' in ''[0,1,...,m-1]'':
 *** Let ''ej = c[33+32j:65+32j]''.
@@ -476,7 +476,7 @@ The steps above follow the script path spending logic from [[bip-0341.mediawiki|
 
 ==== Sighash Calculation ====
 
-The sighash for P2QRH outputs follows the same procedure as defined in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341] for Taproot transactions:
+The sighash for P2TSH outputs follows the same procedure as defined in [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341] for Taproot transactions:
 
 * '''Signature Message:''' A single-SHA256 of a tagged hash with the tag "TapSighash", containing transaction data.
 * '''Tagged Hash:''' Computed as H(tag || tag || data) where H is SHA256 and tag is the SHA256 of the tag name.
@@ -492,22 +492,22 @@ the only field in the witness.
 
 === Compatibility with BIP-141 ===
 
-By adhering to the SegWit transaction structure and versioning, P2QRH outputs are compatible with existing transaction
+By adhering to the SegWit transaction structure and versioning, P2TSH outputs are compatible with existing transaction
 processing rules. Nodes that do not recognize SegWit version 3 will treat these outputs as anyone-can-spend but, per
 [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP-141], will not relay or mine such transactions.
 
 
 === Transaction Size and Fees ===
 
-Equivalent P2QRH and P2TR outputs are always the same size. P2QRH inputs can be slightly larger or smaller than
+Equivalent P2TSH and P2TR outputs are always the same size. P2TSH inputs can be slightly larger or smaller than
 their equivalent P2TR inputs. Let's consider the cases:
 
-'''P2TR key-spend''' P2QRH inputs will be larger than P2TR inputs when the P2TR output would have been spent via the key-spend path.
-P2QRH quantum resistance comes from removing the P2TR key-spend path. Consequently it cannot make use of taproot's optimization
-where P2TR key-spends do not require including a merkle path in the P2TR input. If the Merkle tree only has a single tapleaf, 
+'''P2TR key-spend''' P2TSH inputs will be larger than P2TR inputs when the P2TR output would have been spent via the key-spend path.
+P2TSH quantum resistance comes from removing the P2TR key-spend path. Consequently it cannot make use of taproot's optimization
+where P2TR key-spends do not require including a merkle path in the P2TR input. If the Merkle tree only has a single tapleaf,
 no Merkle path is needed in the control block giving us a 1 byte control block.
 
-P2QRH witness (103 bytes):
+P2TSH witness (103 bytes):
 
 [count] (1 byte), # Number of elements in the witness
 [size] signature  (1 + 64 bytes = 65 bytes),
@@ -521,11 +521,11 @@ P2TR key-spend witness (66 bytes):
 [size] signature (1 + 64 bytes = 65 bytes)
 
 
-Thus, the P2QRH input would be 103 - 66 = 37 bytes larger than a P2TR key-spend input.
+Thus, the P2TSH input would be 103 - 66 = 37 bytes larger than a P2TR key-spend input.
 
 If the Merkle tree has more than a single tapleaf, then the Merkle path must be included in
 the control block.
-P2QRH witness (103+32*m bytes)
+P2TSH witness (103+32*m bytes)
 
 [count] (1 byte), # Number of elements in the witness
 [size] signature  (64 + 1 bytes = 65 bytes),
@@ -533,45 +533,45 @@ tapleaf script = [size] [OP_PUSHBYTES_32, 32 byte public key, OP_CHECKSIG] (34 +
 control block = [size] [control byte, 32 * m byte Merkle path]  (1 + 1 + 32 * m = 2 + 32 * m bytes)
 
 
-For a Merkle path of length m, it would add an additional ~32 * m bytes to the P2QRH input. This would
+For a Merkle path of length m, it would add an additional ~32 * m bytes to the P2TSH input. This would
 make it 37 + 32 * m bytes larger than a P2TR key-spend inputIf m >= 8, then the compact size will use 3 bytes rather than 1 byte.
 
-Considering a P2QRH output that has a PQ signature tapleaf and a Schnorr tapleaf. The P2QRH witness to spend the Schnorr path
-would be 103 + 32 * 1 = 135 bytes. It is unfortunate that we can not use the key-spend optimization for P2QRH inputs, but the key-spend optimization is
-exactly what makes P2TR vulnerable to quantum attacks. If spend-key was quantum resistant we wouldn't need P2QRH at all.
+Considering a P2TSH output that has a PQ signature tapleaf and a Schnorr tapleaf. The P2TSH witness to spend the Schnorr path
+would be 103 + 32 * 1 = 135 bytes. It is unfortunate that we can not use the key-spend optimization for P2TSH inputs, but the key-spend optimization is
+exactly what makes P2TR vulnerable to quantum attacks. If spend-key was quantum resistant we wouldn't need P2TSH at all.
 
-'''P2TR script-spend''' P2QRH inputs will be smaller than equivalent script-spend path P2TR inputs. This is because P2QRH inputs
+'''P2TR script-spend''' P2TSH inputs will be smaller than equivalent script-spend path P2TR inputs. This is because P2TSH inputs
 do not require that the input includes a public key in the witness control block to open the commitment to the tapleaf merkle root.
-An equivalent P2QRH input will be 32 bytes smaller than a P2TR script-spend input.
+An equivalent P2TSH input will be 32 bytes smaller than a P2TR script-spend input.
 
 === Performance Impact ===
 
-P2QRH is slightly more computationally performant than P2TR, as the operations to spending a P2QRH output is a strict 
+P2TSH is slightly more computationally performant than P2TR, as the operations to spending a P2TSH output is a strict
 subset of the operations needed to spend a P2TR output.
 
 === Backward Compatibility ===
 
-Older wallets and nodes that have not been made compatible with SegWit version 3 and P2QRH will not recognize these
-outputs. Users should ensure they are using updated wallets and nodes to use P2QRH addresses and validate transactions
-using P2QRH outputs.
+Older wallets and nodes that have not been made compatible with SegWit version 3 and P2TSH will not recognize these
+outputs. Users should ensure they are using updated wallets and nodes to use P2TSH addresses and validate transactions
+using P2TSH outputs.
 
-P2QRH is fully compatible with tapscript and existing tapscript programs can be used in P2QRH outputs without modification.
+P2TSH is fully compatible with tapscript and existing tapscript programs can be used in P2TSH outputs without modification.
 
 == Security ==
 
-P2QRH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key-spend
-path. This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2QRH outputs
+P2TSH outputs provide the same tapscript functionality as P2TR outputs, but without the quantum-vulnerable key-spend
+path. This enables users, exchanges and other hodlers to easily move their coins from taproot outputs to P2TSH outputs
 and thereby protect their coins from long-exposure quantum attacks. The protection from long-exposure quantum attacks
 does not depend on the activation of post-quantum signatures in Bitcoin but does require that users do not expose their
 quantum vulnerable public keys to attackers via address reuse or other unsafe practices.
 
-P2QRH uses a 256-bit hash output, providing 128 bits of collision resistance and 256 bits of preimage resistance. 
+P2TSH uses a 256-bit hash output, providing 128 bits of collision resistance and 256 bits of preimage resistance.
 This is the same level of security as P2WSH, which also uses a 256-bit hash output.
 
-P2QRH does not, by itself, protect against short-exposure quantum attacks, but such attacks can be mitigated by the future
-activation of post-quantum signatures in Bitcoin. With P2QRH hash, these would provide full quantum resistance to P2QRH outputs in Bitcoin.
+P2TSH does not, by itself, protect against short-exposure quantum attacks, but such attacks can be mitigated by the future
+activation of post-quantum signatures in Bitcoin. With P2TSH hash, these would provide full quantum resistance to P2TSH outputs in Bitcoin.
 That said, the protection offered by resistance to long-exposure quantum attacks should not be underestimated. It is likely
-that the first CRQCs (Cryptographically Relevant Quantum Computers) will not be able to perform short-exposure quantum 
+that the first CRQCs (Cryptographically Relevant Quantum Computers) will not be able to perform short-exposure quantum
 attacks.
 
 
@@ -634,7 +634,7 @@ One consideration for choosing an algorithm is its maturity. secp256k1 was alrea
 chosen as Bitcoin's curve. Isogeny cryptography when it was first introduced was broken over a weekend.
 
 Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size
-due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added
+due to block space being the primary fee constraint. As a P2TSH implementation materializes, a benchmark will be added
 for performance comparison.
 
 An additional consideration is security level. Longer signature sizes provide more security. NIST has standardized five
@@ -653,15 +653,15 @@ proposed solution] in an Ethereum quantum emergency is quite different from the
 a hard fork of the chain, reverting all blocks after a sufficient amount of theft, and using STARKs based on BIP-32
 seeds to act as the authoritative secret when signing. These measures are deemed far too heavy-handed for Bitcoin.
 
-P2QRH and MAST (Merkelized Abstract Syntax Tree) [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP-114],
+P2TSH and MAST (Merkelized Abstract Syntax Tree) [https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki BIP-114],
 and related BIPs [https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki BIP-116], [https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki BIP-117],
 share the idea of committing to a Merkle tree of scripts. While MAST was never activated, taproot
 [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP-341] incorporated this idea of a Merkle tree of
-scripts into its design. P2QRH inherits this capability from taproot because P2QRH is simply taproot with the key-spend
-path removed. As a result, P2QRH does have the taproot internal key or tweak key, instead P2QRH commits directly to the
+scripts into its design. P2TSH inherits this capability from taproot because P2TSH is simply taproot with the key-spend
+path removed. As a result, P2TSH does have the taproot internal key or tweak key, instead P2TSH commits directly to the
 Merkle tree of scripts.
 
-Below we attempt to summarize some of the ideas discussed on the Bitcoin Bitcoin-Dev that relate to P2QRH.
+Below we attempt to summarize some of the ideas discussed on the Bitcoin Bitcoin-Dev that relate to P2TSH.
 
 The idea of a taproot but with the key-spend path removed has been discussed a number of times in the Bitcoin community.
 [https://gnusha.org/pi/bitcoindev/CAD5xwhgzR8e5r1e4H-5EH2mSsE1V39dd06+TgYniFnXFSBqLxw@mail.gmail.com/ OP_CAT Makes Bitcoin Quantum Secure]
@@ -669,13 +669,13 @@ notes that if we disable the key-spend in taproot and activated CAT [https://git
 we could achieve quantum resistance by using Lamport signatures with CAT. Lamport and WOTS (Winternitz One-Time Signatures) built from CAT
 are quantum resistant but are one-time signatures. This means that if you sign twice for the same public key, you leak your secret key.
 This would require major changes to wallet behavior and would represent a significant security downgrade.
-[https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/rTrpeFjWDAAJ Trivial QC signatures with clean upgrade path] and 
-[https://groups.google.com/g/bitcoindev/c/oQKezDOc4us/m/T1vSMkZNAAAJ Re: P2QRH / BIP-360 Update] discusses the idea of 
+[https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/rTrpeFjWDAAJ Trivial QC signatures with clean upgrade path] and
+[https://groups.google.com/g/bitcoindev/c/oQKezDOc4us/m/T1vSMkZNAAAJ Re: P2TSH / BIP-360 Update] discusses the idea of
 taproot but with the future ability to disable the key-spend path.
-The design of P2QRH is partly inspired by these discussions as P2QRH can be understood as P2TR without the key-spend path.
+The design of P2TSH is partly inspired by these discussions as P2TSH can be understood as P2TR without the key-spend path.
 
 Commit-reveal schemes such as
-[https://gnusha.org/pi/bitcoindev/1518710367.3550.111.camel@mmci.uni-saarland.de/  Re: Transition to post-quantum (2018)] 
+[https://gnusha.org/pi/bitcoindev/1518710367.3550.111.camel@mmci.uni-saarland.de/  Re: Transition to post-quantum (2018)]
 and [https://groups.google.com/g/bitcoindev/c/LpWOcXMcvk8/m/YEiH-kTHAwAJ Post-Quantum commit / reveal Fawkescoin variant as a soft fork (2025)]
 have been proposed as a way to safely spend bitcoins if CRQCs become practical prior to Bitcoin adopting achieving quantum resistance.
 The essential idea is to leverage the fact that a CRQC can only learn your private key after a user has revealed their public key.
@@ -684,9 +684,9 @@ Spending via commit-reveal would require two steps, first the user's commits on-
 to spend to. Then, in reveal, the user sign and reveals their public key. While CRQC might be able to generate competing signatures it can not produce
 a commitment to the user's public key earlier than the user's commitment as it does not learn it until the reveal step.
 
-Commit-reveal schemes can only be spent from and to outputs that are not vulnerable to long-exposure quantum attacks, such as 
+Commit-reveal schemes can only be spent from and to outputs that are not vulnerable to long-exposure quantum attacks, such as
 P2PKH, P2SK, P2WPKH, etc... To use tapscript outputs with this system either a soft fork could disable the key-spend path of P2TR outputs
-or P2QRH could be used here as it does not have a key-spend path and thus is not vulnerable to long-exposure quantum attacks.
+or P2TSH could be used here as it does not have a key-spend path and thus is not vulnerable to long-exposure quantum attacks.
 
 == References ==
 
@@ -703,6 +703,7 @@ or P2QRH could be used here as it does not have a key-spend path and thus is not
 
 To help implementors understand updates to this BIP, we keep a list of substantial changes.
 
+* 2025-07-14 - BIP renamed to P2TSH based on [https://delvingbitcoin.org/t/changes-to-bip-360-pay-to-quantum-resistant-hash-p2qrh/1811/5 developer feedback]
 * 2025-07-07 - P2QRH is now a P2TR with the vulnerable key-spend path disabled. Number of PQ signature algorithms supported reduced from three to two. PQ signature algorithm support is now added via opcodes or tapleaf version.
 * 2025-03-18 - Correct inconsistencies in commitment and attestation structure. Switch from merkle tree commitment to sorted vector hash commitment. Update descriptor format.
 * 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics.
@@ -725,6 +726,8 @@ the design of the P2TR (Taproot) output type using Schnorr signatures.
 Much gratitude to my co-founder, Kyle Crews for proofreading and editing, to David Croisant, who suggested the name
 "QuBit", and Guy Swann for pointing out the earlier name for the attestation, "quitness", was imperfect. The
 attestation was later discarded when Ethan Heilman joined as co-author, whom I'm incredibly grateful to for
-transforming this BIP into something far more congruent with existing Bitcoin design. Thank you as
+transforming this BIP into something far more congruent with existing Bitcoin design.
+The BIP was formerly known as P2QRH, or Pay to Quantum Resistant Hash, but Stephen Roose suggested it be renamed to
+better reflect the new direction introduced by Ethan, among other good arguments. Thank you as
 well to those who took the time to review and contribute, including Jeff Bride, Adam Borcany, Antoine Riard, Pierre-Luc
 Dallaire-Demers, Mark Erhardt, Joey Yandle, Jon Atack, Armin Sabouri, Jameson Lopp, Murchandamus, and Vojtěch Strnad.