Hi Russell, Thanks for this detailed comparison. The COSHV BIP does include a brief comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more detailed.
I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's clearly one of the more flexible options available and would enable a multitude of new use cases. When I originally presented my work on congestion control at Jan 2017 BPASE, I also discussed it as an option for covenants. Unfortunately I think it may be on the edge of too powerful -- there are a lot of use cases and implications from having a potentially recursive covenant. If you see my response to Matt in the OP_COSHV BIP thread I classify it as enabling a non-computationally enumerable set of restrictions. I think also from a developer point of view working with OP_COSHV is much much simpler (maybe this can be abstracted) which will lead to increased adoption. OP_COSHV also uses less per-block bandwidth which also makes it preferable for a measure intended to decongest blocks. Do you know the exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating changes to taproot, can be a single byte. OP_COSHV also has less potential to have a negative interaction with future opcodes we may want like OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK unless there's an exact specification which makes us confident we're hitting all the points. If the main complaint about OP_COSHV is that it peeks at surrounding data, it's also possible to implement it more closely to a multi-byte pushdata opcode or do the template optimization. Lastly, as I have previously noted, OP_LEFT is probably safer to implement than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK scripts.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
