Major BIP 360 Update

Protocol Design
1

After reviewing community feedback, Ethan Heilman and I have enlisted the help of a third co-author, Isabel Foxen Duke, in an editorial role to lead and execute a clean sheet rewrite of BIP 360.

Because previous revisions introduced meaningful technical changes, we determined that a full rewrite, rather than incremental edits, was warranted to improve clarity, internal coherence, and to better articulate our intentions for managing potential quantum-related risks.

Consistent with its previous version, this proposal does not introduce post-quantum signature schemes. Instead, BIP 360 proposes the addition of a new output type with the key path spend removed, which is thus protected from hypothetical breaks of Elliptic Curve Cryptography (ECC).

We have renamed this proposed output type "Pay-to-Tapscript-Hash (P2TSH)" for clarity, and believe its adoption is an important first step in protecting Bitcoin from potential threats to ECC, via quantum computers or any other cryptanalytic advancements.

Additionally, the proposal now includes test vectors in Python and Rust.

With gratitude, we hope you’ll review these changes in the BIP Repo or at BIP360.org. We look forward to ongoing community feedback, and new ideas in our efforts to Make Bitcoin Quantum Resistant.

Thank you for your time, Hunter Beast

5 Likes
2

We have renamed this proposed output type "Pay-to-Tapscript-Hash (P2TSH)" for clarity

Why did you settle on Pay-to-Tapscript-Hash? I worry this name could be confusing if a new tapleaf version is added that supports Simplicity.

1 Like
3

This makes a lot of sense! if we also enabled TXHASH that would allow people to commit to a spending path that requires multi-step secret reveal. that allows spending under adversarial quantum conditions. In other words.. we don’t technically need signatures at all. This would allow people to vault their coins and spend them safely even if quantum came out tomorrow and we still hadn’t gotten a signature scheme.

see: A quantum resistance script only using op_ctv/op_txhash and no new signatures

1 Like
4

Indeed, that seems like a confusing name.

I’d interpret it as a scriptPubKey which contains the hash of a BIP-342 tapscript, but it’s (a) not the hash of a script but a Merkle root and (b) not restricted to tapscript.

I think these would be more descriptive:

  • “pay to script tree Merkle root”
  • “pay to taptree root”
  • “pay to MAST”
1 Like
5

The reason I chose Pay to Tapscript Hash was because it rhymes with Pay to Script Hash and Pay to Witness Script Hash.

I think it compares well in lists, too:

  • P2SH
  • P2WSH
  • P2TR
  • P2TSH

I also ran it by Stephen Roose in a past thread here on Delving and he gave me the thumbs up on it.

Also, MAST is confusing because Merkelized Alternative Script Trees are different than prior MAST proposals, and the retronym makes it more difficult to disambiguate.

As for the suggestions, P2STMR, P2TTR, and P2MAST are not superior acronyms in my opinion, at least, from an aesthetic sense… And while naming is subjective and difficult and imperfect, I think P2TSH works well in the context of what’s currently in Bitcoin now.

Thank you for the feedback so far.

1 Like
6

How about Pay to Script Tree (P2ST)? Keep it simple.

7

I think it should end in the word Hash because it helps communicate quantum resistance. And of course a MAST merkle root is a technically just a hash like any other.

8

I’m going to be blunt here. I realize it’s petty to criticize just the name of a proposal, but I’m pretty annoyed here because I feel you’re not understanding my comments.

BIP-360 as written in the open PR is essentially “all of BIP-341, but remove taproot”. Why do you want the keep the name “tap”/“taproot” in there? It’s exactly not taproot.

BIP-342 defines “tapscript”: the specific variant of Bitcoin Script that is used in BIP-341 script tree leaves with leaf version 0xc0. My understanding is that BIP-360 intends(*) to inherit all semantics from the BIP-341 script tree - whether that’s the BIP-342 semantics for 0xc0 leaves, or any future script semantics added separately. For that reason, I think invoking the name “tapscript” here is just wrong: it’s not paying to “tapscript”, it’s paying to a tree of scripts which include any and all script types (even though tapscript is currently the only one defined). If your intent is to only allow paying to BIP-342 tapscript, that is not clear at all.

The reason I chose Pay to Tapscript Hash was because it rhymes with Pay to Script Hash and Pay to Witness Script Hash.

Because it rhymes? You’re seriously suggesting that’s a justification for giving a misleading name?

I also ran it by Stephen Roose in a past thread here on Delving and he gave me the thumbs up on it.

…

Also, MAST is confusing because Merkelized Alternative Script Trees are different than prior MAST proposals, and the retronym makes it more difficult to disambiguate.

Fair enough.

As for the suggestions, P2STMR, P2TTR, and P2MAST are not superior acronyms in my opinion, at least, from an aesthetic sense…

…

I think it should end in the word Hash because it helps communicate quantum resistance.

Sigh, ok.

And while naming is subjective and difficult and imperfect, I think P2TSH works well in the context of what’s currently in Bitcoin now.

I think it’s highly misleading, and you’re doing the ecosystem a disservice by letting aesthetics guide things.

If you insist on having “hash” at the end, at least “pay to script tree hash” wouldn’t be misleading.

(*) I note that BIP-360 just copies the line

Execute the script, according to the applicable script rules, using the witness stack elements excluding the script s, the control block c, and the annex a if present, as initial stack.

… from BIP-341, but then never defines what the applicable script rules are. Since BIP-342 specifically says it only applies when spending BIP-341 outputs, and BIP-360 outputs are not that, technically there just aren’t any applicable spending rules according to the current writing, and any leaf is an anyone-can-spend. I assume that’s not what you meant, but it’s worth addressing too.

2 Likes
9

“Pay to script tree hash” / p2sth seems pretty decent to me as a name for a new address class whose scriptPubKey holds the merkle root of a tree of scripts (and much better than the alternatives).

I reserve the right to pronounce “p2sth” as “pay-to-something”, though :slight_smile:

6 Likes
10

I reserve the right to pronounce “p2sth” as “pay-to-something”, though :slight_smile:

“Pay-to-something” is such a great name. That being said…

I think it should end in the word Hash because it helps communicate quantum resistance.

Honestly, “hash” is redundant, if not misleading. To pay to a script tree is to pay to the tree’s root. There is no other way to pay to a tree of scripts.

On the other hand, to pay to a script tree hash implies you are hashing the root. That’s clearly not what is going on, and if it were, it would only make sense if you hashed the root with a different algorithm than what is used to construct the tree (for hypothetical security reasons).

Pay-to-Script-Tree (P2ST) would be more accurate in my opinion than P2STH. To include the word “hash” purely for marketing reasons is hardly justifiable, especially when the alternative is fewer syllables, easier to say, and technically more precise.

(Big fan of this work by the way @cryptoquick! I see no reason why semantics should get in the way of adoption. Hopefully we can reach consensus on naming and then move on to the technical merits)

1 Like
11

If you didn’t do hashing at all, you could pay to a bare scriptPubKey of all the leafs in your tree, separating them by “IF/ELSE” in some form. Taproot’s merkle root is fundamentally just a hash generated from a particular priority ordering of a set of leaves.

3 Likes