Hi Thread,
I made a reply to the OP but didn't "reply all" so it just went directly to Ethan. Since the comments were interesting I'll attempt to salvage them by posting them in full:
== Lloyd's post ==
Hi Ethan,
I'd be interested to know what protocols you need OP_CAT for. I'm trying to figure out if there really exists any script based protocol that doesn't have a more efficient scriptless counterpart. For example, A²L[1] achieves the same thing as Tumblebit but requires no script. I can imagine paying based on a merkle path could be useful, but a protocol was recently suggested on lightning-dev [2] that does this but without OP_CAT (and without any script!).
== Ethan's response ==
Hi Lloyd,
Thanks for your response. I am not sure if you intended to take this off list or not.
I plan to at some point to enumerate in detail protocols that OP_CAT would benefit. A more important point is that OP_CAT is a basic building block and that we don't know what future protocols it would allow. In my own research I have avoiding going down certain paths because it isn't worth the time to investigate knowing that OP_CAT wouldn't make the protocol practical.
In regards to scriptless scripts they almost always require an interactive protocol and sometimes ZKPs. A2L is very impressive but like TumbleBit it places a large burden on the developer. Additionally I am aware of no way to reveal a subset of preimages with scriptless scripts, do a conditioned reveal i.e. these preimages can only spend under these two pubkeys and timelockA where after timelockZ this other pubkey can spend without a preimages. Scriptless scripts are a fantastic tool but they shouldn't be the only tool that we have.
I'm not sure I follow what you are saying with [2]
This brings me back a philosophical point:
Bitcoin should give people basic tools to build protocols without first knowing what all those protocols are especially when those tools have very little downside.
I really appreciate your comments.
Thanks,
Ethan
==
*Back to normal thread*
Hi Ethan,
Thanks for the insightful reply and sorry for my mailing list errors.
> I plan to at some point to enumerate in detail protocols that OP_CAT would benefit.
Sweet. Thanks.
> Additionally I am aware of no way to reveal a subset of preimages with scriptless scripts, do a conditioned reveal i.e. these preimages can only spend under these two pubkeys and timelockA where after timelockZ this other pubkey can spend without a preimages. Scriptless scripts are a fantastic tool but they shouldn't be the only tool that we have.
Yes. With adaptor signatures there is no way to reveal more than one pre-image; you are limited to revealing a single scalar. But you can have multiple transactions spending from the same output, each with a different set of scriptless conditions (absolute time locks, relative time locks and pre-image reveal). This is enough to achieve what I think you are describing. FWIW there's a growing consensus that you can do lightning without script [1]. Perhaps we can't do everything with this technique. My current focus is figuring out what useful things we can't do like this (even if we were to go wild and add whatever opcodes we wanted). So far it looks like covenants are the main exception.
> I'm not sure I follow what you are saying with [2]
I was pointing to the surprising result that you can actually pay for a merkle path with a particular merkle root leading to a particular leaf that you're interested in without validating the merkle path on chain (e.g. OP_CAT and OP_SHA256). The catch is that the leaves have to be pedersen commitments and you prove the existence of your data in the merkle root by showing an opening to the leaf pedersen commitment. This may not be general enough to cover every merkle tree use case (but I'm not sure what those are!).
> This brings me back a philosophical point:
> Bitcoin should give people basic tools to build protocols without first knowing what all those protocols are especially when those tools have very little downside.
This is a really powerful idea. But I've started feeling like you have to just design the layer 2 protocols first and then design layer 1! It seems like almost every protocol that people want to make requires very particular fundamental changes: SegWit for LN-penalty and NOINPUT for eltoo for example. On top of that it seems like just having the right signature scheme (schnorr) at layer 1 is enough to enable most useful stuff in an elegant way.
Cheers,
LL