OP_CAT was Re: Continuing the discussion about noinput / anyprevout



Summary:

In this email thread, Lloyd asks Ethan what protocols they need OP_CAT for and wonders if there are any script-based protocols that don't have a more efficient scriptless counterpart. Ethan responds by saying that he plans to enumerate the protocols that OP_CAT would benefit in detail and that OP_CAT is a basic building block that could enable future protocols. He also mentions that scriptless scripts require an interactive protocol and sometimes ZKPs, and that while they are a fantastic tool, they shouldn't be the only tool we have. The conversation then shifts to adaptor signatures, which can reveal only one pre-image at a time. However, multiple transactions spending from the same output with different sets of scriptless conditions can achieve what is needed. They also discuss lightning without script and covenants being the main exception. Later on, Ethan talks about paying for a merkle path with a particular merkle root leading to a particular leaf without validating the merkle path on chain, using OP_CAT and OP_SHA256. While this may not be general enough to cover every use case, it's still a surprising result. Finally, Lloyd brings up a philosophical point about Bitcoin giving people basic tools to build protocols without first knowing what all those protocols are, especially when those tools have very little downside. Ethan agrees and says that designing the layer 2 protocols first and then designing layer 1 seems to be the way to go, as almost every protocol requires very particular fundamental changes.


Updated on: 2023-06-13T21:41:22.713033+00:00