Neat idea, basically taproot but with a hash. Yeah that could be an option, but like @sipa points out, it would only be quantum-secure before the first spend.
This would essentially be trading standalone PQ safety for 32 bytes more efficient EC spending prior to Q-day. Arguably safer than P2TRv2 because at least it’s safe if you stand perfectly still, but not actually usable after Q-day until EC spending is disabled by a soft-fork.
Could be an interesting compromise between P2MR and P2TRv2?
I believe this summarizes the exact conditions under which the various schemes have CRQC protection:
| Condition | P2TRv2 | P2TRH | P2MR | P2QR |
|---|---|---|---|---|
| After deposit |  |
 |
|
 |
| + PQC spend | |
 |
|
|
| + ECC spend | |
|
|
 |
(If P2MR is used in a PQC-only mode, it is equivalent to P2QR)
Where:
: only secure if EC was disabled, or no CRQC exists.: also secure under the combination of (a) there is no address reuse, (b) there is no pubkey sharing, (c) no short-range CRQC exists, and (d) there is no collusion between CRQC and hashrate majority: also secure under the combinaton of (a) no reuse and (b) no pubkey sharing, without the need for (c) or (d).: CRQC is no threat: not possibleI’m not sure what to think about this. It’s nice that it maintains the exact same incentive profile as P2TRv2, but the benefits are very thin and it’s more complicated. I don’t think we should consider interesting (as under it, even P2WSH remains secure, without any PQC opcodes or EC disabling), so the benefit is just no-spending deposit-security, and still only when limited to no-reuse no-sharing. I’m curious to what extent this would satisfy people who desire an ability to protect their own coins without relying on EC-disabling (as you know, I don’t think it’s very relevant, but I understand it sounds appealing).
That looks accurate. I think the spend costs are:
| Spend Type | P2TRv2 | P2TRH | P2MR | P2MR+PKR | P2PQ |
|---|---|---|---|---|---|
| PQC Overhead | 32B | 32B | 32B | 32B | 0B |
| ECC Sig | 64B | 64B (nb) | 128B | 96B (nb) | – |
Making an ECC path available adds a 32B (or 33B) overhead for accessing the PQ path in each case, I think; and for the ECC sig, the pubkey recovery requirement makes the signature verification unbatchable, and the P2MR approach adds a sibling reveal and a pubkey reveal.
Hmm, if we increased the block size because of the larger size of PQ signatures by adding an extension block area for PQ signature data, we could also put the extra overhead for ECC spends of P2MR or P2MR+PKR in that same extension block space, and arbitrarily reduce the cost of that overhead; having the first 32B or 64B per-input be free would be manageable, I think, and might be sufficient to make P2MR ECC paths economically competitive with p2wpkh and p2tr, even without abandoning batching.
It’s possible to recover P2TRH as a special case of P2MR. In P2TRH, the key-spend path could be viewed as a depth-zero P2MR tree with a single recoverable EC leaf, which may or may not contain a commitment to a deeper (nested) script tree.
In other words, users could have either
So there is one more option to add to the list. We could deploy P2MR with P2TRH as a special case. Then P2TRv2 proponents get their wish to keep the witness size overhead equivalent to P2TR, while P2MR proponents get their wish for full quantum-security without need for follow-ups.
Seems like this provides the best of both worlds at no cost to either side of the debate, and it’s all packaged inside a single address format.
Thoughts?
It’s true, that’s possible. But I think this construction is mostly equivalent to having both a P2MR and P2TRv2 output type, and if that’s acceptable, it’s better to do just that.
If I understand it correctly, this would boil down to always revealing, at spend time, whether it was a P2MR-style commitment or a P2TRH-style commitment. So from a spending-policy-privacy perspective, they are distinguishable anyway and function as separate anonymity sets.
It is desirable to have as few such sets as possible, but in my view we’ll need at least one new one anyway (to convey “ECC can be disabled in here without confiscation risk”, and post-Q-day also inevitably due to the distinguishable use of PQC opcodes). I saw P2TRH as an attempt to get some of the properties of P2MR and some of the properties of P2TRv2 in a single set (at least as long as the key path is used, just like P2TR), at the cost of additional complexity.
If this is overloaded further to provide both anyway, I feel we’ve gone full circle, given up on the single-set advantage, and created something with worse properties than both P2MR and P2TRv2 separately:
I don’t think any of the above are dealbreakers on their own, but taking them for just the benefit of no-spending-at-all security for those choosing P2TRH-style under very limited circumstances, and an output type that unifies the two before spending, seems like a bad trade-off to me.
For what it’s worth, I think it’s worth considering actually having both P2MR and P2TRv2 type outputs, but I’d like to ask you to consider another combination too: P2QR + P2TRv2.
I think P2QR is actually better at providing the option of security regardless of ecosystem actions, because in practice, I think many of those who’d be inclined to use that will still reuse addresses (which may not even be under their control, but the sender’s), and share public keys because it’s so ingrained in workflows. P2QR offers security even when all that is allowed. It comes at a high cost of course, and is clearly not for everyone, but I think that’s ok with the option of P2TRv2 too.
Reasonable counterpoints to this are that:
It would be equivalent to deploying both P2MR and P2TRH. P2TRv2 is very different in that it is susceptible to long-exposure attacks.
Unfortunately you’re correct: it would effectively be two address formats packaged into one, at least from the perspective of chain analysts. To users the two formats would look identical, and one could argue that is a good or bad thing depending on perspective.
After thinking about it some more, I’m inclined to agree that deploying two different output types would be equally useful, but more practical from an engineering perspective. Separate BIPs, simpler spec and code.
Why P2TRv2 and not P2TRH?
Yes, there is. But I think the difference’s relevance disappears when offering both (P2TRv2 or P2TRH) and P2MR, because the advantage (offering users the option to make coins CRQC-resistant without relying on ecosystem action) is offered (in a stronger form) by P2MR.
As I noted in my comparison table post above, I think it’s an advantage that comes with pretty serious restrictions (no reuse, no pubkey sharing, no spending, not even PQC spending, all until EC disabling), but I accept it’s a distinction that some will probably find relevant. However, with P2MR also available, I don’t see why anyone who feels strongly about that ability wouldn’t use P2MR instead (which remains secure under post-Q-day pre-EC-disabling PQC spending at least).
P2TRH comes with additional complexity (new BIP340 signature variant) and lacks some features (like ring signatures for proofs of reserve / UTXO DoS resistance) that P2TRv2 doesn’t have. As I said, I don’t think these are dealbreakers, but with the advantage of P2TRH over P2TRv2 mostly gone, I don’t see why not pick the most frictionless-to-adopt scheme possible.
Why P2TRv2 and not P2TRH?
Ah i see your earlier points now apply to this question:
To that i say:
If P2QR has no EC spending from inception, this does of course eliminate the risk of EC public key exposure, but it also means that P2MR has a different security advantage where, if a critical flaw is found in the chosen PQC algorithm before EC spending is disabled, you would still be able to migrate off it using the EC spending path.
Unless there is a hefty discount for the PQ signature from day 1 that makes it not significantly more expensive than existing address types, I don’t personally believe P2QR would see much uptake until there is a clear and imminent threat of CRQCs materializing in the very near future, or possibly not even before one has been proven to exist. Which I believe would be far too late. Ideally, most of the active coins should have migrated at that point, and the only way I see this happening is if the increase in cost of using it prior to day-QC is negligible.
While eliminating all forms of EC public key exposure would of course be difficult due to the use of xpubs for things like hardware wallets and auditing, this is still far less critical than on-chain exposure, which should be manageable for P2MR for someone who is aware of the dangers.
I think this claim of additional protection has important qualifications.
The restrictions on getting post-CRQC pre-EC-disabling security are in my view, very severe: no address reuse, no public key sharing, and no spending whatsoever. It’s certainly possible to comply with that if convinced it’s worth it and taking special effort, but it’s not something that applies to the casual user. They, or their senders, might even be using software that isn’t aware Q-day arrived. Convinced users who care about post-CRQC pre-EC-disabling security, and who are willing to adopt carefully chosen workflows that avoid the pitfalls, would just choose P2MR over P2TRv2 if both existed, in my view. Casual users will just keep reusing addresses etc., and thus not get the CRQC-resistance anyway, whether they use P2TRv2 or P2TRH.
This is a fair point, and I won’t push for retaining the advantages of batch validation. I think it’s a minor loss to lose the possibility of deploying it, but it’s fair that interest in it (even absent CRQC-threats) is low. It also doesn’t contribute to adoption friction, which IMO is the #1 thing to optimize for. It’s a very secondary ecosystem benefit at best.
No. It’s useful for proof-of-reserve systems, and it has been discussed in the context of denial-of-service protection in the future Lightning gossip system, but even there generic ZK proof systems may be preferable (which, unlike ringsigs, can deal with a hashing step on top, though at higher computation cost). I don’t know of any practical deployments though.
As you know, I believe this is pretty much a requirement regardless (not tripwire specifically, but timely EC disabling in general).
But even ignoring the “what’s left of Bitcoin if we have mass freeze or theft” concern, I believe the advantages of P2MR over P2TRv2, and even more so the advantages of P2TRH over P2TRv2, are mostly marketing. I certainly understand the appeal. If are you told you have the choice between two types of outputs, one is a bit cheaper and the other may remain secure post-Q-day for, many will likely happily take the second option. But when adding that for that “may” to hold you also must strictly never reuse an address, not use Lightning, not share descriptors or xpubs, the advantages of (current designs for) hardware wallet over software wallets disappear, and post Q-day, you must instruct your software to only use the PQC path anymore (or in the case of P2TRH, not transact at all), and treating incoming transactions that use EC witnesses as not-yet-confirmed, I don’t expect many users are going to follow all that.
So if there are users who would be skeptical about P2TRv2 and wouldn’t adopt it, but they would adopt P2TRH or P2MR, then that’s perhaps a good reason to offer it (too). That’s even the case when expecting that most of them will misuse it regardless and thus not actually get the benefit, but still be fine (in good outcomes) because they’ll end up being protected by EC-disabling anyway. This feels like disingenuous marketing to me, but perhaps it’s needed to get sufficiently wide adoption, I don’t know.
That’s fine, as far as I’m concerned, people shouldn’t to adopt it until then. But some may insist to have some option for post-CRQC pre-EC-disabling security, and P2QR is IMO the most honest option to provide that.
I think this is a severe false sense of security.
It seems the discussion is now mostly about P2TRv2+P2MR vs P2TRH+P2MR.
I see two different use cases here: (1) regular wallets and (2) responsibly managed high-value storage.
For responsibly managed high-value storage, P2MR looks like the better fit. Compared to P2QR it keeps cheap pre-Q-day EC spending, assuming the responsible operator can avoid EC key leaks. Compared to P2TRH it can be spent securely on Q-day before EC disabling.
So the main question is what is better for regular wallets: P2TRv2 or P2TRH?
The advantage of P2TRH is that a CRQC cannot steal from P2TRH if the EC public key has not been revealed on-chain or off-chain. P2TRv2 coins are vulnerable after Q-day and before EC disabling. With P2TRH at least some coins will still be safe, depending on user behavior. There will probably be a big run from P2TR(v2) to P2MR on Q-day. Some P2TRH owners (who did not leak their EC public keys) can wait. This is good for others who are under time pressure to migrate - a positive effect for the whole network.
The advantages of P2TRv2 are simplicity, existing BIP-340 verification, batch validation, direct-pubkey constructions, and a clearer security model. P2TRH may produce a false sense of security for people who reuse addresses, while P2TRv2 is explicitly insecure after Q-day before the EC-disabling fork. On the other hand, people will run from P2TRv2 to P2MR on Q day creating a big spike of mempool fees.
Haha sorry for hijacking your thread @starius! We did get a bit off-topic from the OP.
I have more to say on P2TRv2, but for now I will hold my tongue and issue a request to proponents of P2TRv2: solve the EC-disabling timing problem, then let’s circle back and reassess. Otherwise P2TRv2 is DOA, because it would be built on hope and not cryptography. Until then, I doubt further debate will be fruitful.
As for the excellent OP idea, I look forward to getting this into P2MR 
First I’m seeing this!
I love this idea and the work you did that inspired this approach might help solve another problem I’ve been worried about, something I call the laggards problem, but that’s a separate discussion.