Hi list. I'm following up on an idea I sketched in this thread debating P2MR vs P2TRv2. The premise is this: What if we modified this line of BIP360:
> The last stack element is called the control block c, and must have length 1 > + 32 * m, for a value of m that is an integer between 0 and 128, inclusive. > Fail if it does not have such a length. To this: > The last stack element is called the control block c, and must have length 1 > + 32 * m, for a value of m that is an integer between 1 and 128, inclusive. > Fail if it does not have such a length. The key change is that the control block must now include at least one merkle authentication path. This effectively bans depth-zero script trees in P2MR, and requires every P2MR address to always pay the cost of having at least two spending conditions. This seems like a reduction in P2MR's features and efficiency. Why would we want to ban depth-zero script trees? Well these seem to be the source of a perverse incentive, as pointed out by Matt Corallo and Antoine Poinsot in prior threads. Bitcoin script users are economically and practically incentivized by P2MR to use depth-zero script trees because their witnesses are smaller than if the same script were used in a taproot script spend. Furthermore, depending on the exact scripts and the developers' resources, devs using P2MR for a multi-party scripting protocol may not be sufficiently incentivized to add a cooperative spending path, even if their protocol might allow it. Doing so would require a depth-1 tree, which increases the witness size of the non-cooperative script spend path by 32 bytes. For some short scripts, e.g `<height> CLTV <pubkey> CHECKSIG`, the devs may actually have incentive not to add a cooperative spending path, because the cooperative path would actually be less-efficient than just using the non-cooperative path as the single leaf of a depth-zero tree. This leads to easy fingerprinting of scripting protocols, less privacy for everyone else, and undoes a key design goal of P2TR. In Matt's words: > The value of taproot is that its design natively adds [a cooperative spending > path] *for free* to every contracting protocol, and not only adds it for free > but *forces* every contracting protocol to carry at least some of the cost if > they decline to do this. This results in a massive net privacy win across the > entire Bitcoin ecosystem... > a goal of taproot is *privacy* while offering efficiency for the common > (all-sign) case. That is generally true across contracting protocols and > makes things net-cheaper with a taproot-style system where you hit the common > case often. This is another reason why P2MR is quite a loss By eliminating depth-zero script trees, we'd force all P2MR users to pay for the cost of having at least two spending conditions. We'd eliminate the incentive for script devs to use P2MR over P2TR because both are equally efficient, and incentivize P2MR users to add a cooperative spending path using BIP340, since those users are already paying for the cost of having a depth-1 tree anyway. This change to BIP360 wouldn't affect the recommended standard use-cases for single-signer and multisig P2MR: hybrid addresses with one Schnorr leaf and one PQ leaf. If anything, this change would encourage the proper use of PQ fallback scripts, because the incentive logic can be applied to someone who tries to use P2MR with only a single EC Schnorr leaf: This user must pay for the cost of a second leaf script anyway, so why not follow best-practices and add a PQ leaf? AFAICT this change only affects use cases which would otherwise degrade the fungibility of the UTXO set according to BIP360 critics, and encourages those use-cases to adopt a cooperative spending path which (assuming all other factors equal) will be indistinguishable from a regular single-signer P2MR wallet with a PQ fallback leaf. I've already chatted about this off-list with some BIP360 proponents and they seem receptive, but I'm really curious about the opinions of those who are leaning towards P2TRv2. Would this change to BIP360 address your concerns surrounding P2MR's privacy incentives? If not, why? regards, conduition -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Q8YTY1ArMzia7tRvcZ5v769WPxCMxAl_0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-PuGB6QtI28qRjE5Vob-l44UmBH6L8aXInoSk%3D%40proton.me.
publickey - [email protected] - 0x474891AD.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
