formatted bip-0360 as mediawiki #31

notmike-5 · 2025-10-20T19:57:35Z

formats bip-0360 as mediawiki and adds updated image of merkle tree/root construction

EthanHeilman · 2025-10-26T16:56:32Z

Minor issue: In the merkletree image there is gap between "How the TapTree root..." and the diagram. Probably move it up a bit for so the text and diagrams have consistent gaps.

I'm recommend merging these changes as a series of commits to the PR so that we can tell when a change breaks the mediawiki formating

EthanHeilman

I didn't get a chance to review everything. There is so much to fix that was correct in the original.

EthanHeilman · 2025-10-26T16:35:23Z

bip-0360.mediawiki

+'''Abstract'''

-=== Abstract ===
+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) addresses – but with the key-path spend removed.


Suggested change

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) addresses – but with the key-path spend removed.

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.

EthanHeilman · 2025-10-26T16:36:18Z

bip-0360.mediawiki

-but requires PQ signatures to provide full security against Cryptographically Relevant Quantum Computers (CRQCs).
-P2QRH is designed to provide the foundation necessary for a future soft fork activating PQ signature verification 
-in tapscript.
+Through this modification, P2TSH addresses create the option of using Taproot in a manner that is:


Suggested change

Through this modification, P2TSH addresses create the option of using Taproot in a manner that is:

Through this modification, P2TSH outputs create the option of using Taproot in a manner that is:

We talk discuss output types here, not address types.

EthanHeilman · 2025-10-26T16:40:48Z

bip-0360.mediawiki

+# resistant to any future cryptanalytic approaches that could compromise elliptic curve cryptography (ECC) used by Bitcoin.

-This document is licensed under the 3-clause BSD license.
+It is worth noting that the proposed P2TSH outputs are only resistant to (so-called) “long-exposure attacks” on elliptic curve cryptography (ECC); that is, attacks on public keys exposed for time periods longer than the average time needed to confirm a bitcoin transaction.


Suggested change

It is worth noting that the proposed P2TSH outputs are only resistant to (so-called) “long-exposure attacks” on elliptic curve cryptography (ECC); that is, attacks on public keys exposed for time periods longer than the average time needed to confirm a bitcoin transaction.

It is worth noting that the proposed P2TSH outputs are only resistant to “long-exposure attacks” on elliptic curve cryptography (ECC); that is, attacks on public keys exposed for time periods longer than the average time needed to confirm a bitcoin transaction.

Given that we are introducing the terminology "long-exposure" I'd drop (so-called), but if you really want it, keep it.

EthanHeilman · 2025-10-26T16:45:03Z

bip-0360.mediawiki

-This document is licensed under the 3-clause BSD license.
+It is worth noting that the proposed P2TSH outputs are only resistant to (so-called) “long-exposure attacks” on elliptic curve cryptography (ECC); that is, attacks on public keys exposed for time periods longer than the average time needed to confirm a bitcoin transaction.
+
+Protection against more sophisticated quantum attacks - including protection against retrieval of keys exposed in the mempool while a transaction is waiting to be confirmed (a.k.a. “short-exposure attacks”) - may require the introduction of post-quantum signature schemes in Bitcoin addresses. We believe it’s worth considering this path in the future and intend to offer a separate proposal for this purpose upon further research.


Suggested change

Protection against more sophisticated quantum attacks - including protection against retrieval of keys exposed in the mempool while a transaction is waiting to be confirmed (a.k.a. “short-exposure attacks”) - may require the introduction of post-quantum signature schemes in Bitcoin addresses. We believe it’s worth considering this path in the future and intend to offer a separate proposal for this purpose upon further research.

Protection against more sophisticated quantum attacks - including protection against recovering secret keys from public keys exposed in the mempool while a transaction is waiting to be confirmed (a.k.a. “short-exposure attacks”) - may require the introduction of post-quantum signature opcodes. We believe it’s worth considering this path in the future and intend to offer a separate proposal for this purpose upon further research.

"retrieval of keys exposed in the mempool while a transaction is waiting to be confirmed" is a confusing way to put it. It sounds like we are retrieving public keys from the mempool.

post-quantum signature opcodes Bitcoin addresses --> post-quantum signature opcodes.

It isn't the address that has the signature schemes.

EthanHeilman · 2025-10-26T16:47:08Z

bip-0360.mediawiki

+
+Protection against more sophisticated quantum attacks - including protection against retrieval of keys exposed in the mempool while a transaction is waiting to be confirmed (a.k.a. “short-exposure attacks”) - may require the introduction of post-quantum signature schemes in Bitcoin addresses. We believe it’s worth considering this path in the future and intend to offer a separate proposal for this purpose upon further research.
+
+This document additionally defines specific quantum attack-vectors and new terms that we are concerned with in this proposal.


Suggested change

This document additionally defines specific quantum attack-vectors and new terms that we are concerned with in this proposal.

This document additionally defines "short exposure" and "long exposure" attacks, and other new terminology.

What are these other new terms?

EthanHeilman · 2025-10-26T17:34:32Z

bip-0360.mediawiki

-P2QRH quantum resistance comes from removing the P2TR key path spend. Consequently, it cannot make use of Taproot's optimization
-where P2TR key path spends do not require including a Merkle path in the P2TR input. If the Merkle tree only has a single leaf script,
-no Merkle path is needed in the control block, giving us a 1-byte control block.
+[size] signature (1 + 64 bytes = 65 bytes),


We should get rid of double returns in pre blocks. It takes up space, makes it harder to read and is inconsistent with what we do elsewhere

EthanHeilman · 2025-10-26T17:36:35Z

bip-0360.mediawiki

+
 [size] signature (1 + 64 bytes = 65 bytes)
-</source>
+</pre>


Why did we move from source to pre here? What does the pre tag have that source doesn't?

EthanHeilman · 2025-10-26T17:39:12Z

bip-0360.mediawiki


-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 PQ signatures. That said, we are not strongly opposed to putting this increase in P2QRH.
+1) Minimize changes to the network – we should reuse existing Bitcoin code and preserve existing software behavior, workflows, user expectations and compatibility whenever possible.


We use mediawiki enumeration else where, why are use using "1)" here rather than "-"? Why make this change, it seems to only add inconsistency?

EthanHeilman · 2025-10-26T17:41:33Z

bip-0360.mediawiki

-**** If ''k<sub>j</sub> &ge; e<sub>j</sub>'': ''k<sub>j+1</sub> = hash<sub>TapBranch</sub>(e<sub>j</sub> || k<sub>j</sub>)''.
-** Let ''r = hash<sub>QuantumRoot</sub>(k<sub>m</sub>)''.
-** If ''q &ne; r'', fail.
+** Let ''v = c[0] & 0xfe'' be the ''leaf version'' (as defined in [https://github.com/cryptoquick/bips/blob/p2qrh/bip-0341.mediawiki BIP 341]). To maintain ''leaf version'' encoding compatibility the last bit of c[0] is unused and must be 1 [<nowiki/>[https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki#cite_note-12 6]].


If we are going to link to a BIP we shouldn't be linking to the BIP on the fork. Mediawiki has a nice way of handling this, see original.

Why
(as defined in [https://github.com/cryptoquick/bips/blob/p2qrh/bip-0341.mediawiki BIP 341])
vs.
(as defined in [[bip-0341.mediawiki|BIP 341]])

EthanHeilman · 2025-10-26T17:42:51Z

bip-0360.mediawiki

-** Let ''r = hash<sub>QuantumRoot</sub>(k<sub>m</sub>)''.
-** If ''q &ne; r'', fail.
+** Let ''v = c[0] & 0xfe'' be the ''leaf version'' (as defined in [https://github.com/cryptoquick/bips/blob/p2qrh/bip-0341.mediawiki BIP 341]). To maintain ''leaf version'' encoding compatibility the last bit of c[0] is unused and must be 1 [<nowiki/>[https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki#cite_note-12 6]].
+** Let ''k0 = hashTapLeaf(v || compact_size(size of s) || s)''; also call it the ''tapleaf hash''.


It looks like someone went in an removed the subscript formatting. Why? How is this better?

EthanHeilman · 2025-10-26T19:26:55Z

bip-0360.mediawiki

 * 2025-01-20 - Remove SQIsign from consideration due to significant performance concerns. Refactor language from long-range attack to long-exposure so as to not be confused with the language around block re-org attacks.
 * 2024-12-18 - Assigned BIP number.
-* 2024-12-13 - Update to use Merkle tree for attestation commitment. Update LR & SR quantum attack scenarios.
+* 2024-12-13 - Update to use Merkle tree for attestation commitment. Update LR &amp; SR quantum attack scenarios.


Suggested change

* 2024-12-13 - Update to use Merkle tree for attestation commitment. Update LR & SR quantum attack scenarios.

* 2024-12-13 - Update to use Merkle tree for attestation commitment. Update LR & SR quantum attack scenarios.

EthanHeilman · 2025-10-26T19:27:09Z

bip-0360.mediawiki

+* 2025-07-07 - P2QRH is now a P2TR with the vulnerable key-path spend removed. 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.
+* 2025-03-12 - Add verification times for each algorithm. 256 -&gt; 128 (NIST V -&gt; NIST I). Add key type bitmask. Clarify multisig semantics.


Suggested change

* 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics.

* 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics.

EthanHeilman · 2025-10-26T19:29:09Z

bip-0360.mediawiki

-* [https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956?u=cryptoquick Delving Bitcoin discussion]
-* [https://bitcoinops.org/en/newsletters/2024/06/14/ Bitcoin Optech newsletter]
-* [https://bitcoinops.org/en/podcast/2024/06/18/#draft-bip-for-quantum-safe-address-format Bitcoin Optech discussion transcript]
+'''Long-Exposure Attacks'''


I'd suggest moving Long-Exposure and Short-Exposure when we first use them outside the abstract

EthanHeilman · 2025-10-26T19:30:51Z

bip-0360.mediawiki

+
+We understand that this subject is controversial and veiled in uncertainty; and hope to offer users flexible options - tailored to their level of concern - that are relatively unobtrusive to existing network architecture.
+
+This is an issue that has been discussed with some regularity in [https://bitcointalk.org/index.php?topic=133425.0 Bitcoin forums] since at least 2013 – and there is clearly user demand for increased quantum protection.


This should be moved to related work

EthanHeilman · 2025-10-26T19:34:34Z

bip-0360.mediawiki

+In this proposal, we adopt a “prepared not scared” approach to the possible advancement of quantum computing – and offer Bitcoin users an option for increased protection if they so choose.
+
+We understand that this subject is controversial and veiled in uncertainty; and hope to offer users flexible options - tailored to their level of concern - that are relatively unobtrusive to existing network architecture.


This should be moved to rationale. Standards typically don't have conclusions as they are mostly concerned with how, not why, with why living in rationale. Only one other BIP has a conclusion.

EthanHeilman · 2025-10-26T19:35:47Z

bip-0360.mediawiki

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

-In comparison, the size of currently used signature algorithms are:
+Combined with P2TSH, the introduction of post-quantum signature schemes would provide more comprehensive quantum resistance to P2TSH outputs – including protection from short-exposure attacks.


Suggested change

Combined with P2TSH, the introduction of post-quantum signature schemes would provide more comprehensive quantum resistance to P2TSH outputs – including protection from short-exposure attacks.

Combined with P2TSH, post-quantum signature schemes would provide comprehensive quantum resistance to P2TSH outputs – including protection from short-exposure attacks.

notmike-5 added 2 commits October 20, 2025 13:52

formatted bip-0360 to mediawiki format

8be9f8a

bip-0360/merkletree.png: updated image

7b87284

EthanHeilman requested changes Oct 26, 2025

View reviewed changes

EthanHeilman reviewed Oct 26, 2025

View reviewed changes

	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) addresses – but with the key-path spend removed.
	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 addresses create the option of using Taproot in a manner that is:
	Through this modification, P2TSH outputs create the option of using Taproot in a manner that is:

	It is worth noting that the proposed P2TSH outputs are only resistant to (so-called) “long-exposure attacks” on elliptic curve cryptography (ECC); that is, attacks on public keys exposed for time periods longer than the average time needed to confirm a bitcoin transaction.
	It is worth noting that the proposed P2TSH outputs are only resistant to “long-exposure attacks” on elliptic curve cryptography (ECC); that is, attacks on public keys exposed for time periods longer than the average time needed to confirm a bitcoin transaction.


		Protection against more sophisticated quantum attacks - including protection against retrieval of keys exposed in the mempool while a transaction is waiting to be confirmed (a.k.a. “short-exposure attacks”) - may require the introduction of post-quantum signature schemes in Bitcoin addresses. We believe it’s worth considering this path in the future and intend to offer a separate proposal for this purpose upon further research.

		This document additionally defines specific quantum attack-vectors and new terms that we are concerned with in this proposal.

	This document additionally defines specific quantum attack-vectors and new terms that we are concerned with in this proposal.
	This document additionally defines "short exposure" and "long exposure" attacks, and other new terminology.

	* 2024-12-13 - Update to use Merkle tree for attestation commitment. Update LR & SR quantum attack scenarios.
	* 2024-12-13 - Update to use Merkle tree for attestation commitment. Update LR & SR quantum attack scenarios.

	* 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics.
	* 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics.


		We understand that this subject is controversial and veiled in uncertainty; and hope to offer users flexible options - tailored to their level of concern - that are relatively unobtrusive to existing network architecture.

		This is an issue that has been discussed with some regularity in [https://bitcointalk.org/index.php?topic=133425.0 Bitcoin forums] since at least 2013 – and there is clearly user demand for increased quantum protection.

		In this proposal, we adopt a “prepared not scared” approach to the possible advancement of quantum computing – and offer Bitcoin users an option for increased protection if they so choose.

		We understand that this subject is controversial and veiled in uncertainty; and hope to offer users flexible options - tailored to their level of concern - that are relatively unobtrusive to existing network architecture.

	Combined with P2TSH, the introduction of post-quantum signature schemes would provide more comprehensive quantum resistance to P2TSH outputs – including protection from short-exposure attacks.
	Combined with P2TSH, post-quantum signature schemes would provide comprehensive quantum resistance to P2TSH outputs – including protection from short-exposure attacks.

Uh oh!

formatted bip-0360 as mediawiki #31

Are you sure you want to change the base?

formatted bip-0360 as mediawiki #31

Conversation

notmike-5 commented Oct 20, 2025

Uh oh!

EthanHeilman commented Oct 26, 2025

Uh oh!

EthanHeilman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EthanHeilman Oct 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

EthanHeilman Oct 26, 2025 •

edited

Loading