BIP 360 rewrite and general copyediting

[notmike-5]

• Pay-to-Quantum-Resistant-Hash (P2QRH) has been renamed to Pay-to-Tapscript-Hash (P2TSH)
• Substantial re-writes/edits to correct errors and clarify authors' intent
• Adds updated image of Tapscript tree/Merkle root and scriptPubkey construction
• Added a brief glossary of terms
• Formats revised BIP-0360 as a mediawiki document

[EthanHeilman]

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]

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.

[notmike-5]

We're on the same page here, its a novel definition.

[EthanHeilman]

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.

[notmike-5]

I agree, you could re-work this entire section. Will clarify the language to make clear that it is recovery of private keys from public keys exposed in the mempool.

[EthanHeilman]

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?

[notmike-5]

I don't know. This is a question for the authors. I will remove that piece.

[cryptoquick]

It's a good first effort but please address all feedback so far

[cryptoquick]

Also be sure to address the CI check failures

[EthanHeilman]

Also be sure to address the CI check failures

The CI check failures are unrelated to the bip-0360.mediawiki file, which is the subject of this PR.

I think this failure is a result of the BIP-0360 mediawiki file not matching the table. You probably want to update the table

The other ones can probably be fixed by rebasing

[notmike-5]

Also be sure to address the CI check failures

The CI check failures are unrelated to the bip-0360.mediawiki file, which is the subject of this PR.

I think this failure is a result of the BIP-0360 mediawiki file not matching the table. You probably want to update the table

The other ones can probably be fixed by rebasing

This was an issue of spaces vs tabs in the preamble and, also, a license needed to appear there.

The other CI issues are a diff error and typos in some other files. These are unrelated to the PR, and were not fixed by rebase.

[cryptoquick]

Good work so far

Just two changes requested of existing unresolved conversations

[EthanHeilman]

LGTM, all my requested changes have been resolved

[cryptoquick]

Many notable differences between this and the original Google doc after going through line by line in comparison

Also, the entire Conclusion section is missing. That needs to be added.

Please review these changes and make sure that we didn't lose anything important, @EthanHeilman

Thanks! 🙏

[cryptoquick]

Suggested change

	Through this modification, P2TSH outputs provide a Tapscript-native, hashed output type that is:
	Through this modification, P2TSH outputs create the option of using Taproot in a manner that is:

[notmike-5]

P2TSH is not Taproot, it is totally different than Taproot. There are really just three similarities between P2TSH and Taproot: 1) both are Segwit output types, 2) you form a common signature message when signing, and 3) locking scripts in both use Tapscript rather than Script.

[cryptoquick]

Suggested change

	# resistant to known attacks by cryptographically-relevant quantum computers (CRQCs), and
	# resistant to potential attacks by cryptographically relevant quantum computers (CRQCs)

[notmike-5]

It is not true that P2TSH protects against all potential attacks by a CRQC - it mitigates Shor's. P2TSH is still susceptible, for example, to improved quantum algorithms for unstructured search.

[cryptoquick]

Suggested change

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

[notmike-5]

Saying that P2TSH is resistant to "any future cryptanalytic approaches..." is ill-advised at best, even if you do try to restrict the claim to those that compromise ECC as well. For example, if P = NP with practical algorithms, then turning all cryptographic attacks into SAT would break ECC and hash-based cryptography simultaneously.

[cryptoquick]

Suggested change

	Protection against more sophisticated quantum attacks - including protection against the recovery of secret keys from public keys that are exposed in mempools while a transaction is waiting to be confirmed (what we term “short-exposure attacks”) - may require the introduction of post-quantum signature schemes in Tapscript.
	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.

[notmike-5]

Again, these changes conflate addresses with outputs, it makes the attack you are talking about (i.e. quantum key recovery) less clear, and the last sentence contradicts the decision to separate this BIP from discussions about PQC schemes.

As you said weeks ago @EthanHeilman (and @cryptoquick approved at that time) in #31 (comment):

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

And I agree.

[cryptoquick]

Suggested change

	P2TSH does not, by itself, protect against short-exposure quantum attacks, but such attacks might be mitigated by the future activation of post-quantum signature schemes in P2TSH outputs.
	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.
	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.

[notmike-5]

@EthanHeilman to my eye this looks substantially the same as the language you provided (and @cryptoquick approved) weeks ago in #31 (comment).

[cryptoquick]

Suggested change

	That said, the protection offered by resistance to long-exposure attack alone should not be underestimated. It is likely that the first CRQCs will not be able to perform short-exposure attacks - as such, defense against long-exposure attacks is more time-sensitive than is defense against short-exposure attacks.
	That said, the protection offered by resistance to long-exposure attacks alone should not be underestimated. It is likely that the first CRQCs will not be able to perform short-exposure attacks - as such, defense against long-exposure attacks is more time-sensitive than prevention against short-exposure attacks.

[cryptoquick]

Suggested change

	Quantum-resistant signature algorithms (e.g. ML-DSA or SLH-DSA) offer different theorized levels of protection (e.g. NIST I - V), and each should be scrutinized before use. We are currently researching options for the potential proposal of post-quantum signatures into Bitcoin – and encourage others to engage in this research as well.
	Quantum-resistant signature algorithms (e.g. ML-DSA or SLH-DSA) offer different theorized levels of protection and should be scrutinized as such before use. We are currently researching options for the potential proposal of post-quantum signatures into Bitcoin and encourage others to engage in this research as well.

[cryptoquick]

Suggested change

	Below we attempt to summarize some of the ideas related to P2TSH that have been discussed on the bitcoin-dev mailing list, bitcointalk.org, and elsewhere.
	Below we attempt to summarize some of the ideas discussed on the bitcoin-dev mailing list that relate to P2TSH.

[notmike-5]

I have no idea why it is now being proposed to return to the Word document text that contained numerous factual errors, incorrect terminology, and when viewed in the most favorable light was ambiguous and often repetitive.

@EthanHeilman You already reviewed most of this stuff after the Word document text was ported into a mediawiki file. Many of the changes are your own or were informed by your comments. Nevertheless, for your convenience, I have tried where possible to link to your specific comments, almost all of which @cryptoquick had already approved of. I cannot speak as to why they now want to revert them.

With respect to reintroducing the conclusion section, you addressed this in #31 (comment), @cryptoquick approved of the removal at the time, and so it was removed.