> but then if we have that why do we need CSFS?

1. the same reason we have CHECKSIG and CHECKSIGVERIFY and EQUAL and EQUALVERIFY. different contracts are easier with either. bitcoin script has a lot of redundancies for slight optimizations.

2. because we can not soft-fork into legacy script a new opcode that alters the stack, this is only possible with OP_SUCCESS in tapscript. so the CSFSVERIFY will simply fail the script if the signature is not valid, but won't consume any stack elements. which is sometimes very inconvenient.

moonsettler

btw: we removed CSFSV from LNhance. you can call CSFS VERIFY if you need that.

Reasoning:
- CSFS is more likely to be used in Symmetry
- In case where CSFSV is desired OP_CSFS OP_VERIFY is perfectly workable.
- Simplifies code
- Don't have an actual use case for CSFSV in legacy rn
- Upgradeable NOPs are scarce
- Backporting tapscript would bring all functionality to legacy


Works like CSFS but is compatible with all script types, not only tapscript.

but then if we have that why do we need CSFS?

bitcoin

LNhance LAUNCHES WEBSITE🎊🎊🎊 (THE GREATEST OF SOFT FORKS)

EverythingSatsoshi

This is new:
>OP_CHECKSIGFROMSTACKVERIFY
Works like CSFS but is compatible with all script types, not only tapscript.

but then if we have that why do we need CSFS? 