Rename tapscript-native output type to leaf script output type

Author: EthanHeilman

bip-0360.mediawiki

@@ -19,7 +19,7 @@
 
 This document proposes a new output type: Pay-to-Tapscript-Hash (P2TSH), via a soft fork. P2TSH outputs operate with nearly the same functionality as P2TR (Pay-to-Taproot) outputs, but with the key path spend removed.
 
-Through this modification, P2TSH outputs allow developers to use tapscript and script trees in a manner that is:
+Through this modification, P2TSH outputs allow developers to use script trees and leaf scripts, such as tapscript, in a manner that is:
 
 # resistant to long exposure attacks by Cryptographically Relevant Quantum Computers (CRQCs), and
 # resistant to future cryptanalytic approaches that may compromise the elliptic curve cryptography (ECC) used by Bitcoin.
@@ -36,25 +36,25 @@ This document is licensed under the 3-clause BSD license.
 
 ===Motivation===
 
-The primary threat to Bitcoin from Cryptographically Relevant Quantum Computers (CRQCs) is their potential to break the key cryptographic assumption which secures the digital signatures used in Bitcoin.<ref>A Cryptographically Relevant Quantum Computer is an ''object'' which is only loosely defined by ''characteristics'' in quantum physics as of today. It could be understood in the context of this BIP and in Bitcoin that it's a ''hardware-agnostic'' computer supposed to have the architecture to keep ''coherent'' a sufficient number of logical qubits to be able to run Shor's algorithm in an efficient fashion.</ref> More specifically, [https://arxiv.org/pdf/quant-ph/0301141 Shor's algorithm] enables a CRQC to solve the Discrete Logarithm Problem (DLP) exponentially faster than classical methods.<ref>Shor's algorithm is believed to need 10^8 operations to break a 256-bit elliptic curve public key.</ref> This allows the derivation of private keys from public keys — a process referred to here as quantum key recovery.<ref>Meaning, deriving private keys from public keys via Shor's algorithm</ref> While it is unclear when or if CRQCs will become viable in the future, we propose the addition of a quantum-resistant, [[#tapscript-native-output-type|Tapscript-Native output type]] for those interested in this level of protection.
+The primary threat to Bitcoin from Cryptographically Relevant Quantum Computers (CRQCs) is their potential to break the key cryptographic assumption which secures the digital signatures used in Bitcoin.<ref>A Cryptographically Relevant Quantum Computer is an ''object'' which is only loosely defined by ''characteristics'' in quantum physics as of today. It could be understood in the context of this BIP and in Bitcoin that it's a ''hardware-agnostic'' computer supposed to have the architecture to keep ''coherent'' a sufficient number of logical qubits to be able to run Shor's algorithm in an efficient fashion.</ref> More specifically, [https://arxiv.org/pdf/quant-ph/0301141 Shor's algorithm] enables a CRQC to solve the Discrete Logarithm Problem (DLP) exponentially faster than classical methods.<ref>Shor's algorithm is believed to need 10^8 operations to break a 256-bit elliptic curve public key.</ref> This allows the derivation of private keys from public keys — a process referred to here as quantum key recovery.<ref>Meaning, deriving private keys from public keys via Shor's algorithm</ref> While it is unclear when or if CRQCs will become viable in the future, we propose the addition of a quantum-resistant, [[#leaf-script-output-type|Leaf script output type]] for those interested in this level of protection.
 
 While some may balk at the potential threat of quantum computers to Bitcoin given their limited functionality to date, some others — including governments, corporations and some existing and potential Bitcoin users — are concerned about their potential for advancement. The Commercial National Security Algorithm Suite (CNSA) 2.0, for instance, has mandated software and networking equipment to be upgraded to post-quantum schemes by 2030, with browsers and operating systems fully upgraded by 2033. Additionally, according to NIST IR 8547, Elliptic Curve Cryptography (ECC) is planned to be disallowed within the US federal government after 2035 (with an exception made for hybrid cryptography, or the use of ECC and post-quantum algorithms together). These kinds of mandates have triggered concern by some ECC users, including some Bitcoin users who prefer to be prepared out of an abundance of caution.
 
 In the most optimistic case, wherein quantum computers never pose a significant risk to ECC, we understand that the possibility of quantum advancement alone may be influencing adoption and broad confidence in the Bitcoin network. In other words, we believe users' fear of quantum computers may be worth addressing regardless of CRQC viability. Given these concerns, we think it's worth considering simple low risk changes that create options for using Bitcoin in a quantum-resistant way.
 
-As a conservative first step in this effort, we propose Pay-to-Tapscript-Hash (P2TSH), a tapscript-native output type that can be used in a quantum resistant manner.
+As a conservative first step in this effort, we propose Pay-to-Tapscript-Hash (P2TSH), a leaf script output type that can be used in a quantum resistant manner.
 
 ===Long Exposure vs Short Exposure Attacks===
 
-For clarity, this proposal specifically mitigates the risk of long exposure attacks on outputs that support tapscript and script trees. While some other Bitcoin output types, such as P2SH, are safe against long exposure attacks, taproot is not and taproot is the only currently activated output type that supports tapscript and script trees.
+For clarity, this proposal specifically mitigates the risk of long exposure attacks on outputs that support tapscript, leaf scripts and script trees. While some other Bitcoin output types, such as P2SH, are safe against long exposure attacks, taproot is not and taproot is the only currently activated output type that supports tapscript, leaf scripts and script trees.
 
 A long exposure attack is an attack performed on exposed blockchain data, such as exposed public keys, or the scripts of spent outputs. These are likely to be the earliest quantum attacks made possible on Bitcoin, because attackers will have ample time — as much time as vulnerable keys are exposed — to carry out quantum key recovery.
 
 Short exposure attacks, however, require faster quantum computers, because they must occur within the relatively short time that a transaction is unconfirmed in the mempool.
 
 Bitcoin outputs are generally vulnerable to short exposure attacks, as most Bitcoin transactions require revealing the associated public key when spending. Full protection of outputs from short exposure attacks may require the use of post-quantum signature schemes.
 
-Since long exposure attacks on public keys are likely to be the first quantum-enabled threat to Bitcoin, we propose a tapscript-native output type that is resistant to long exposure attacks as a first step in hardening Bitcoin against the potential threat of quantum computers.
+Since long exposure attacks on public keys are likely to be the first quantum-enabled threat to Bitcoin, we propose a leaf script output type that is resistant to long exposure attacks as a first step in hardening Bitcoin against the potential threat of quantum computers.
 
 The following list of output types describes their long exposure attack vulnerability:
 
@@ -162,9 +162,9 @@ P2TSH leverages the battle tested P2TR, tapleaf and tapscript code already in Bi
 
 2. Create the safest possible path for the addition of post-quantum signature integrations, in the event that they are used in the future.
 
-Importantly, we are proposing a tapscript-native output type that is resistant to long exposure attacks. While some existing output types are already resistant to long exposure attacks (e.g. P2WSH), no such output type supports tapscript — a feature that may be required for practical implementation of post-quantum signature opcodes.
+Importantly, we are proposing a leaf script output type, i.e. an output type that supports tapscript, that is resistant to long exposure attacks. While some existing output types are already resistant to long exposure attacks (e.g. P2WSH), no such output type supports tapscript — a feature that may be required for practical implementation of post-quantum signature opcodes.
 
-P2WSH, for instance, is not tapscript-native and as such does not support the OP_SUCCESSx opcode update path that will be critical for the integration of post-quantum OP_CHECKSIG opcodes into Bitcoin.<ref><code>OP_SUCCESSx</code> is a mechanism to upgrade tapscript</ref>
+P2WSH, for instance, does not support tapscript and as such does not support the OP_SUCCESSx opcode update path that will be critical for the integration of post-quantum OP_CHECKSIG opcodes into Bitcoin.<ref><code>OP_SUCCESSx</code> is a mechanism to upgrade tapscript</ref>
 
 3. Facilitate gradual integration of quantum resistant features that can be carried out iteratively as quantum computers evolve. This approach encourages responsiveness to the current threat-level, while avoiding heavy-handedness in our reactions to a potential threat.
 
@@ -299,7 +299,7 @@ P2TSH is slightly more computationally performant than P2TR script path spends,
 
 ==Backward Compatibility==
 
-Older wallets and nodes that have not been made compatible with SegWit version 2 and P2TSH will not understand these outputs. Per [[bip-0350.mediawiki|BIP 350]] older wallets should be able to spend funds to SegWit version 2 outputs. Users should ensure they are using updated wallets and nodes to receive P2TSH outputs and validate transactions using P2TSH outputs. P2TSH is fully compatible with tapscript and existing tapscript programs can be used in P2TSH outputs without modification.
+Older wallets and nodes that have not been made compatible with SegWit version 2 and P2TSH will not understand these outputs. Per [[bip-0350.mediawiki|BIP 350]] older wallets should be able to spend funds to SegWit version 2 outputs. Users should ensure they are using updated wallets and nodes to receive P2TSH outputs and validate transactions using P2TSH outputs. P2TSH is fully compatible with tapscript and existing tapscript programs can be used in P2TSH outputs without modification. P2TSH can also support future leaf script versions.
 
 ==Security==
 
@@ -383,15 +383,14 @@ Attempts to derive private keys from public keys during the brief period when fu
 
 Protection against short exposure attacks may require post-quantum signature schemes; that said, executing these attacks requires faster CRQCs than those capable of executing long exposure attacks and are therefore viewed as lower-risk than long exposure attacks in the nearer term.
 
-<span id="tapscript-native-output-type"></span>
-'''Tapscript-Native Output Type'''
+<span id="leaf-script-output-type"></span>
+'''Leaf Script Output Type'''
 
-Tapscript-native output types are the category of output types that support tapscript (including Schnorr signatures) and script trees.
+Leaf script output types are the category of output types that support leaf scripts and script trees. Leaf script output types support tapscript, as tapscript is a type of leaf script.
 
 '''Pay-to-Tapscript-Hash (P2TSH)'''
 
-A tapscript-native output type, similar to to Pay-to-Taproot (P2TR), but with the quantum-vulnerable key path spend removed.
-
+A leaf script output type, similar to to Pay-to-Taproot (P2TR), but with the quantum-vulnerable key path spend removed.
 ==Footnotes==
 
 <references/>
@@ -400,6 +399,7 @@ A tapscript-native output type, similar to to Pay-to-Taproot (P2TR), but with th
 
 To help implementers understand updates to this BIP, we keep a list of substantial changes.
 
+* __0.10.3__  (2026-02-02) - Rename tapscript-native output type to leaf script output type.
 * __0.10.2__  (2026-01-23) - Fix bug in verification, minor review comments and adopt [[bip-0003.mediawiki|BIP 003]] conventions.
 * __0.10.1__  (2026-01-21) - Terminology and clarity improvements, addressed feedback from reviews.
 * __0.10.0__  (2025-09-17) - Rewrote BIP for clarity and renamed from P2QRH to P2TSH