BIP 360 - Pay to Tapscript Hash (P2TSH)

[cryptoquick]

This spent several months gathering feedback from the mailing list and from other advisors. This is hopefully polished enough to submit upstream.

Let me know if you have any questions or feedback, and of course feel free to submit suggestions.

Thank you for your time.

[jonatack]

Interesting (the question of resistance to quantum computing may have resurged lately with the publication of https://scottaaronson.blog/?p=8329, see also https://x.com/n1ckler/status/1839215426091249778).

[jonatack]

@cryptoquick Can you begin to write up the sections currently marked as TBD, along with a backwards compatibility section (to describe incompatibilities, severity, and suggest mitigations, where applicable/relevant)? We've begun to reserve a range of BIP numbers for this topic, pending continued progress here.

[jonatack]

@cryptoquick ping for an update here. Have you seen https://groups.google.com/g/bitcoindev/c/p8xz08YTvkw / https://github.com/chucrut/bips/blob/master/bip-xxxx.md? It may be interesting to review each other and possibly collaborate.

[murchandamus]

Given that you say that the content of this BIP is still in flux and will be completely overhauled soon, I’ll convert this PR to Draft for the time being. Please set it back to Ready for Review after pushing the changes.

[cryptoquick]

The BIP 360 team is excited to share the following revisions aimed at enhancing clarity, readability and defining new terminology related to Bitcoin Quantum Resistance.

Key changes include:

• Renaming for better alignment: Pay-to-Quantum-Resistant-Hash (P2QRH) has been renamed to Pay-to-Tapscript-Hash (P2TSH). This reflects the evolved design, which builds directly on Taproot mechanics by removing the quantum-vulnerable key-spend path while enabling flexible script commitments.
• Substantial re-writes and edits: We've made extensive revisions throughout the document to improve readability, improve precision, and more clearly convey the authors' intent. These language revisions have largely been crafted by our new co-author, @Isabelfoxenduke.
• Updated visuals: Added a new, improved diagram illustrating the Tapscript tree/Merkle root and scriptPubKey construction for better understanding of the output structure.
• New glossary section: Introduced a brief glossary of key terms to make the BIP more accessible to reviewers and implementers.
• Test vectors in Python and Rust
• These refinements bring us closer to a robust, community-aligned proposal for addressing Bitcoin's long-term quantum resilience.

We'd love your feedback! Please review the latest version of the BIP:
https://github.com/cryptoquick/bips/blob/56be885cc9ba67b047e257df6692ab0c4290b294/bip-0360.mediawiki

Rendered view and details: https://bip360.org/ (will be updated soon!)

Please share your thoughts, suggestions, or concerns. Your input is invaluable in shaping this proposal.
Thank you to the community for your time and attention!
- The BIP 360 Team

[cryptoquick]

Just noticed that the test vectors have not yet been updated with the new P2TSH nomenclature. Most of us are taking time off this week but @jbride can get to it next week. Contributions welcome, as always.

The BIP itself however should be final and is ready for review.

[billymcbip]

ACK, this is great work! I would highlight it earlier in the BIP that P2TSH is useful outside of the quantum-security context for script-only outputs.

[cryptoquick]

Test vectors have been updated. Let us know if you try them out!

[murchandamus]

This is a good read, it’s been a while since I read the prior version, but this feels like a big clean-up. I appreciate the brevity and clear focus.

I notice that the proposal introduces several idiosyncratic terms for established concepts. E.g., it uses “tapleaf”, “tapscript tree”, and “tapscript output” for the concepts introduced as “script leaf”, “script tree”, and “taproot output” in BIP 341. It would be preferable if the proposal were to use the established terms for established concepts instead of introducing new terminology.

[murchandamus]

If you’re gonna make sub sentence constructions with em dashes, maybe use them em dashes. ;)

Suggested change

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.

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.

[EthanHeilman]

Was avoiding them to keep everything ascii. Added the em dashes.

[murchandamus]

That’s actually a good reason, I would have also accepted a rejection of my suggestion with that rationale. ;) But thanks for taking my suggestion regardless.

[murchandamus]

What is a “tapscript-native” output type? This appears to be a new term that I’m unfamiliar with and that is being used without definition.

Edit: Having reached the Glossary, I would also consider it sufficient to link to the definition there on the first use. That said, the term does strike me as somewhat odd: P2TR leaf scripts could be used with other leaf script versions in the future, e.g., making use of Simplicity, so the use of Tapscript in the script leaves does not necessarily seem to be the defining characteristic.

[EthanHeilman]

Thanks for the review. I'll be addressing comments for the next few days. I added a link to glossary.

P2TR leaf scripts could be used with other leaf script versions in the future, e.g., making use of Simplicity, so the use of Tapscript in the script leaves does not necessarily seem to be the defining characteristic.

We wanted some way of saying that this output supports tapscript but not pre-tapscript. The existing terminology made talking about it awkward but we open to better ways to communicate this. Let's leave this comment unresolved and I'll sleep on it. We should probably add a sentence about future leaf versions.

[murchandamus]

It might be sufficient to define the term before it is used for it to be clear why it’s useful.

[murchandamus]

Please don’t introduce new terms for concepts with established names, and please use only one term for the same concept. Especially it seems odd to emphasize the tapscript-use here, when the issue is the public key visible due to the taproot construction. I would suggest just talking about taproot outputs or P2TR outputs, since that seems to be what you mean.
Still confused by the newly introduced term “tapscript-native output”.

Suggested change

	For clarity, this proposal specifically mitigates against the risk of long exposure attacks on tapscript-native outputs. While other Bitcoin output types already mitigate against this risk, Tapscript outputs (P2TR output types) are vulnerable to long exposure quantum attacks.
	For clarity, this proposal specifically mitigates against the risk of long exposure attacks on taproot outputs. While other Bitcoin output types already mitigate against this risk, taproot outputs are vulnerable to long exposure quantum attacks.

[EthanHeilman]

We are primarily concerned with being able to support tapscript and post-tapscript leaf scripts.

My concern is that someone read "For clarity, this proposal specifically mitigates against the risk of long exposure attacks on taproot outputs" and incorrectly assume that if BIP-360 is activated taproot outputs are quantum safe.

What do you think about this alternative:

"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."

[EthanHeilman]

Added my alternative in this commit: 6743610#diff-e296d32a8f60ef9f846683e801718d16c41fa7d8f1065e0afa6405a0764a91e3R49

Is this better?

[murchandamus]

Suggested change

	A long exposure attack is an attack performed on exposed blockchain data, such as exposed public keys or the spend 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.
	A long exposure attack is an attack performed on exposed blockchain data, such as exposed public keys or the output 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.

[EthanHeilman]

Fixed

[murchandamus]

Suggested change

	* Tapscript outputs (starts with bc1p)
	* Taproot outputs (starts with bc1p)

[EthanHeilman]

Fixed

[murchandamus]

Suggested change

	tapleaf script = [size] [OP_PUSHBYTES_32, 32-byte public key, OP_CHECKSIG] (1 + 1 + 32 + 1 bytes = 35 bytes),
	leaf script = [size] [OP_PUSHBYTES_32, 32-byte public key, OP_CHECKSIG] (1 + 1 + 32 + 1 bytes = 35 bytes),

[EthanHeilman]

Fixed

[murchandamus]

Leaves in script trees can be at different depths, so the length of the Merkle path does not necessarily need to match the depth of the script tree, but depends on the depth of the script leaf that is being used to spend the output.

[EthanHeilman]

Added a comment to explain that we assuming this for the sake of the comparison.

[murchandamus]

Note that both BIP 350 and BIP 173 suggest that any implementers permit sending to future native segwit output types, so all spec-compliant implementations should be able to send to such outputs immediately, even if they cannot receive them and will not enforce the corresponding rules before upgrading.

[EthanHeilman]

Fixed

[murchandamus]

Given that many users of P2TR outputs are using them only with a key path spending condition, this statement feels like a bit of a stretch.

[EthanHeilman]

I don't understand what you mean here. Its been a long day so I might be failing to see something obvious.

A P2TSH output with a single public key based leaf script should provide the same UX as a P2TR key spend no?

[murchandamus]

Sorry, that was not very clear. Yes, it should be easy to migrate, once the users’ respective wallet software have upgraded to provide support for the new output type. However, there might be some wallets that only support P2TR keypath spending, so the wallet updates might take a bit longer than one would expect if only considering the similarity of P2TR and P2TSH.

[EthanHeilman]

Tried to capture your thoughts in 6743610

[vostrnad]

This sentence feels out of place and is very much redundant: (the next line says the same thing)

Suggested change

	A P2TSH output is a native SegWit output (see [[bip-0141.mediawiki|BIP 141]]) with version 2 and a 32-byte witness program. The witness program is the root of the tapscript tree. For the sake of comparison, we have - as much as possible - copied the language verbatim from the script validation section of [[bip-0341.mediawiki|BIP 341]].
	A P2TSH output is a native SegWit output (see [[bip-0141.mediawiki|BIP 141]]) with version 2 and a 32-byte witness program. For the sake of comparison, we have - as much as possible - copied the language verbatim from the script validation section of [[bip-0341.mediawiki|BIP 341]].

[EthanHeilman]

I don't see where we say what the witness program is in the next line.

[vostrnad]

The next line reads: "Let q be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents the Merkle root of the script tree." I think you'll agree that it clearly states that the witness program represents the Merkle root of the script tree.

[EthanHeilman]

Ok, I see what you are saying. I removed that line

[vostrnad]

This is a subtle divergence from the way P2TR is validated. When there are exactly two witness stack items and the second one starts with 0x50, P2TR interprets this as (public key, annex) and performs key path validation, while P2TSH as specified here interprets this as (script, control block). It just so happens that this will always fail because the 0x50 byte doesn't meet the leaf version requirement that the lowest bit be set to 1, but it might be preferable to make this explicit. If for some reason the lowest bit requirement were later revised to be 0 then the "annex" could be interpreted as a non-c0 version control block and pass validation.

Suggested wording:

Suggested change

	* Fail if the witness stack does not have two or more elements.
	* If there are at least three witness elements, and the first byte of the last element is 0x50, this last element is called ''annex a'' and is removed from the witness stack. The annex (or the lack thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during P2TSH validation.
	* Fail if the witness stack does not have two or more elements.
	* If the first byte of the last element is 0x50:
	** Fail if the witness stack does not have at least three elements.
	** The last element is called ''annex a'' and is removed from the witness stack. The annex (or the lack thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during P2TSH validation.

[EthanHeilman]

Comments like this that get into this complex details are very much appreciated. This one took some thinking. I was sure you were wrong until I stepped through it ever carefully.

The bug is in the line:

 If there are at least three witness elements, and the first byte of the last element is 0x50,

because we skip removing the annex if there are exactly two witness elements.

Thinking about two ways of fixing this:

Option A:

Maximizes explicitness by adding the line Fail if the witness stack has exactly two elements and the first byte of the last element is 0x50.

* Let ''q'' be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents the Merkle root of the script tree.
* Fail if the witness stack does not have two or more elements.
+ * Fail if the witness stack has exactly two elements and the first byte of the last element is 0x50.
* If there are at least three witness elements, and the first byte of the last element is 0x50, this last element is called ''annex a'' and is removed from the witness stack. The annex (or the lack thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during P2TSH validation.
* There must be at least two witness elements left.

Option B:

Directly solves the bug by minimizes diff with BIP 341 language by changing "three" to "two" in the line If there are at least three witness elements, and the first byte of the last element is 0x50,

* Let ''q'' be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents the Merkle root of the script tree.
* Fail if the witness stack does not have two or more elements.
* If there are at least +two+ witness elements, and the first byte of the last element is 0x50, this last element is called ''annex a'' and is removed from the witness stack. The annex (or the lack thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during P2TSH validation.
* There must be at least two witness elements left.

I wrote a table to compare the desired behavior, look it over and see if you agree

# witness elements	last element is Annex (0x50)	BIP 341	BIP 360 (desired)
0	-	FAIL	FAIL
1	-	Key path spend	FAIL
2	No	Script path spend	Script path spend
2	Yes	Key path spend	FAIL
>2	No	Script path spend	Script path spend
>2	Yes	Script path spend	Script path spend

[EthanHeilman]

Fixed this with Option A, look it over: 6743610#diff-e296d32a8f60ef9f846683e801718d16c41fa7d8f1065e0afa6405a0764a91e3R223

[vostrnad]

I like the table, it clearly shows that in cases that would trigger key path validation in P2TR we want to fail immediately. I also like the wording you've chosen, I think it's even better than my original suggestion.

[vostrnad]

Suggested change

	** Call the second-to-last stack element ''s'', the script (as defined in [[bip-0341.mediawiki|BIP 341]])
	** Call the second-to-last stack element ''s'', the script (as defined in [[bip-0341.mediawiki|BIP 341]]).

[EthanHeilman]

Fixed

[vostrnad]

This may be just subjective preference, but I think requiring the unused bit to be 0 would make a lot more sense, as you'd get rid of the masking and have the first byte be the actual leaf version. Masking doesn't make much sense without the parity bit as used in BIP-341.

Suggested change

** 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.<ref>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.</ref>

** Let ''v = c[0]'' be the ''leaf version'' (as defined in [[bip-0341.mediawiki|BIP 341]]). Fail if the last bit of ''v'' is not 0.<ref>Why is the last bit of the leaf version required to be zero? In BIP 341 the last bit is masked out and used to check the parity of the output public key. Because the bit is now unused, by setting it to zero we maintain the same leaf version set between P2TR and P2TSH.</ref>

[EthanHeilman]

Lets see if I understand what you are proposing here:

IF P2TSH {
    IF c[0] & 0xfe != 0 {
        FAIL()
    }
}

I agree that doing this is conceptionally more simple and more natural. I'm worried people will do it way that seems easiest to them and introduce a bug.

The bug I want to avoid is that someone writes transaction validation code such as:

int leaf version = c[0]

This code would appear to work because who would set the last bit of c[0] to 1. The failure case would likely only be triggered by someone behaving maliciously and setting the last bit to 1. By requiring c[0] & 0xfe==1, we cause that code to fail immediately and the chance this bug gets into production is lower.

I'm always a little uncomfortable reasoning this deep into developer behavior. I don't think what propose would be dangerous, but it might be more dangerous than the alternative. What do you think about this line of reasoning?

[vostrnad]

Yes, someone could incorrectly implement this variant by completely forgetting to include a check that the specification makes very explicit – I don't think that's more likely than someone incorrectly implementing the original variant which is more complicated. In either case, test vectors should prevent these kinds of errors in the first place.

[vostrnad]

I think this is meant to be:

Suggested change

	*** Let ''e<sub>j</sub> = c[33+32j:65+32j]''.
	*** Let ''e<sub>j</sub> = c[1+32j:33+32j]''.

[EthanHeilman]

Good catch!!! Fixed

[vostrnad]

The common signature message is extended in BIP-342 by setting ext_flag = 1 and appending the tapleaf hash, key version and codeseparator position. Something similar ought to be specified here as well.

[EthanHeilman]

What do you think of this change to the language?
6743610#diff-e296d32a8f60ef9f846683e801718d16c41fa7d8f1065e0afa6405a0764a91e3R247

[vostrnad]

BIP-141 actually specifies no such thing. May I suggest:

Suggested change

	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 2 will treat these outputs as anyone-can-spend but, per [[bip-0141.mediawiki|BIP 141]], will not relay or mine such transactions.
	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 2 will treat these outputs as anyone-can-spend but will generally not relay or mine transactions that spend them.

[EthanHeilman]

Fixed!

[murchandamus]

Murch wrote:

That said, the term does strike me as somewhat odd: P2TR leaf scripts could be used with other leaf script versions in the future, e.g., making use of Simplicity, so the use of Tapscript in the script leaves does not necessarily seem to be the defining characteristic.

I realized today that I should have also pointed out that calling the output type “Pay to Tapscript Hash” feels a bit like a misnomer to me. As mentioned in my review, Tapscript refers to the variant of Script that is used by version 0xc0 P2TR script leaves, and Tapscript doesn’t feel like the main defining characteristic to either P2TR outputs or your new proposed output type — while there are hashes of script leaves that contain Tapscript appear as a building block in the tree, it seems fairly removed from the witness program and output script. The most defining characteristic to me seems that spending can only happen per one of the script leaves of the tree, so something mentioning the tree, alternative scripts, or a branch would have seemed more natural to me, maybe Pay to Script Tree or Pay to Tree Hash.

In an adhoc survey of one, the person guessed that an output type called “P2TSH” it would encode a P2WSH-like output using Tapscript instead of Script.

Anyway, naming is hard and YMMV, so beyond that I’ll try to keep my bike shedding to myself.

[EthanHeilman]

Thanks for all the comments so far and time the reviews have spent on this. We are working on addressing them and should have an update this week.

[conduition]

I would go even more broad. Everyone who is using bitcoin today for long-term storage should, eventually, move coins to a BIP360 address of one kind or another. Once wallets have compatibility, there's little reason not to, other than really needing keypath spending for some highly specific and hopefully short-term use-case.

Suggested change

	This output type is designed to offer tapscript users protection against long exposure quantum attacks as well as a practical output type with which post-quantum signatures may be used if such signatures are adopted in the future.
	This output type is designed to offer users protection against long exposure quantum attacks as well as a practical output type with which post-quantum signatures may be used if such signatures are adopted in the future.

[conduition]

users reveal they are spending to a script tree whenever they are using P2TSH outputs, since P2TSH outputs can only be spent via script path spend

This feels like a null statement, akin to: "By paying coins to a script tree, users reveal they are paying coins to a script tree".

Aside from the obvious differentiator of the new address type, I don't see any privacy major difference between P2TSH and P2TR, especially if a P2TSH address only encodes a single spending condition.

Maybe you could say that P2TR can more efficiently hide many spending conditions, but P2TSH can as well (less efficiently), by committing to a lopsided script tree. Example:

      root
    /    \
pubkey   / \
        /   \
       /\   /\
   ... very deep tree ...

[EthanHeilman]

@conduition

Consider the following spent outputs:

• P2TR_A, has a key spend and no leaf scripts

• P2TR_B, has a key spend path and three complex leaf scripts

• P2TSH_A, has a single script path (simple pubkey script)

• P2TSH_B, has a four script paths (simple pubkey leaf script and three complex scripts)

P2TSH_A is the equivalent to P2TR_A and P2TSH_B is the equivalent to P2TR_B.

If both P2TR_A and P2TR_B are spent via the key spend path. no one learns that P2TR_A had no script spend path and no learns that P2TR_B has three script paths. So P2TR_A and P2TR_B look the same.

If both P2TSH_A and P2TSH_B are spent using the the simple pubkey leaf script, everyone looking at the blockchain learns that P2TSH_A only had one leaf script and that P2TSH_B has at least two leaf scripts.

The privacy leak here isn't terrible, but it isn't nothing.

Now P2TSH could be made as private as P2TR by enforcing that everyone have at least two leaf scripts. This privacy would come at the cost of increasing P2TSH outputs that only have one leaf script by 32 bytes as they would need to include a second decoy leaf script. It would also increase the complexity of this change, but adding a mechanism to require at least two leaf scripts.

[conduition]

Thanks for clarifying, I think i was assuming most people will be using P2TSH with at least two script leaves (to include at least one post-quantum spending path), making your P2TSH_A scenario extremely rare.

It would also increase the complexity of this change, but adding a mechanism to require at least two leaf scripts.

I don't think we should go that far - there are likely many some use cases where you want an address with explicitly only one spending path, and want to avoid the need to generate and verify NUMS script leaves.

[EthanHeilman]

That is not an unreasonable assumption to make but I want to steelman the privacy benefit of P2TR here.

[conduition]

Something unique about this new address format which i don't believe has ever been seen before with segwit address formats. For the first time ever, we are adding a new segwit version number without changing the bech32 encoding scheme.

Perhaps it is worth investigating if any wallets will do a stupid, like say perhaps, assuming the segwit version number is 1 if the address' encoding scheme (which must be determined first, to get to the segwit version) was bech32m. If a wallet did this when sending funds to a BIP360 address, they'd create a P2TR output instead of P2TSH, effectively burning the money by paying coins to the wrong segwit version.

This is a bad enough failure state that we should check wallets ahead of time to avoid lost coins, and possibly insert a warning into this section of the spec document. Here's a stab at it:

WARNING TO SENDERS

The only factor that differentiates a P2TSH address from a P2TR address is the segwit version number - 1 for P2TR, 2 for P2TSH. The encoding scheme (bech32m) is the same, as is the witness program length (32 bytes). Accordingly, developers must take care that any wallet sending to bech32m-encoded addresses must properly parse and respect the segwit version number in the address when creating a transaction output script. Failure to do so, e.g. by assuming a certain version number, may result in accidental burning of bitcoins.

[cryptoquick]

That's a very good point. They shouldn't be correlated because they're different things, but that doesn't mean the behavior was assumed to be coupled.

Another option is to punt on this problem, tweak the bech32m BCH coding constant slightly, call it, idk, bech32n or bech32q. It sounds kinda silly, but if it prevents people from losing funds, maybe it's worth it?

[conduition]

I'm not literate enough about the internal mechanics of bech32m to comment on the feasibility of changing the encoding constants. But from an engineering perspective, it'd suck to have to upgrade every bech32 decoding library again with yet another new standard.

I think this is a risk-pill we'll just have to swallow and do our best through outreach when we get closer to deployment phase

[EthanHeilman]

Pushed a commit that addresses most of the comments. Some of the comments are still unaddressed because I want to think a little bit more about them. I appreciate all the comments and time people have spend reviewing BIP 0360, it helps a lot

[murchandamus]

Briefly skimmed the recent changes, looks good so far, thanks for taking my feedback. Please note that the Preamble format changed slightly due to BIP 3 deploying last week. I provided some suggestions how to update the Preamble.

[murchandamus]

IIRC native segwit outputs with unknown versions are considered standard (as long as the witness program is between 2 and 40 bytes), while inputs spending outputs with unknown versions would be considered non-standard.

[vostrnad]

The wording I suggested in #1670 (comment) includes this distinction, I'd suggest revisiting that.

[murchandamus]

Right, @vostrnad’s wording is on-point.

[EthanHeilman]

Fixed

[murchandamus]

Suggested change

	| Standard
	| Specification

[EthanHeilman]

Fixed in 6743610

[murchandamus]

Suggested change

	Author: Hunter Beast <hunter@surmount.systems>
	Ethan Heilman <ethan.r.heilman@gmail.com>
	Isabel Foxen Duke <isabel.duke@gmail.com>
	Comments-Summary: No comments yet.
	Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0360
	Status: Draft
	Type: Standards Track
	Created: 2024-12-18
	Authors: Hunter Beast <hunter@surmount.systems>
	Ethan Heilman <ethan.r.heilman@gmail.com>
	Isabel Foxen Duke <isabel.duke@gmail.com>
	Status: Draft
	Type: Specification
	Assigned: 2024-12-18

[EthanHeilman]

Fixed in 6743610

[murchandamus]

BIP 3 suggests that Changelogs use version numbers inspired by semantic versioning. If you should add versions numbers to your Changelog, please also add a Version header to the preamble.

[EthanHeilman]

Added in 6743610

[murchandamus]

Thanks for your continued work on this. Please let me know when you are done addressing any review comments that you are still considering. ISTM that we can publish this proposal once the review comments are addressed and you deem it ready for publication.

[murchandamus]

Since the BIP 3 deployment updated all existing BIPs and the table in the README, there is now a merge conflict here. It would probably be the easiest to rebase this PR on the latest master branch.

[EthanHeilman]

Ended up doing a merge, rebase kept breaking vscode for some reason.

[murchandamus]

Sorry, that was not very clear. Yes, it should be easy to migrate, once the users’ respective wallet software have upgraded to provide support for the new output type. However, there might be some wallets that only support P2TR keypath spending, so the wallet updates might take a bit longer than one would expect if only considering the similarity of P2TR and P2TSH.