A few incidental remarks, sorry if too far afield.
I agree here that there’s little practical difference between softforking to add a new opcode and softforking to enable new argument-based behavior. Clients still need to update, fork still needs to be deployed, and code savings on the Core side are pretty minor I think.
This is less a comment about roconnor’s remarks per se and more about the notion of essentially assembling a sighash message on the stack, but:
I think it would be really unfortunate if we got to the point where we were using CAT and rolling SHA opcodes to slice and dice txn components into tailor made hashes. Not only am I skeptical that there are many uses that call for fundamentally different txn component combinations to be hashed, but it strikes me that doing this kind of stuff on the stack is more in the “computation” than “verification” camp, and so is a waste of space and time when it comes to L1.
I think this explains my bias for “CISC” vs. “RISC”-style opcodes in Bitcoin. Of course the trade-off here is that CISC implies being able to anticipate things that people want to do, and I suppose there’s no reason that both styles can’t exist in script. Maybe this is worth elaborating on in another post.
I think it would be helpful to have some kind of listing of uses that having CSFS enables (e.g. key delegation, although to be honest I can’t explain this use much deeper than just saying “key delegation”; something-something federations maybe?). Because if the only use for CSFS that we can think of here is allowing a unification of BIP 118 and 119, I’d say it’s more expeditious just to activate the two together as written.
In any case, great work @reardencode - there’s some really useful stuff in your document, like the “what is hashed?” table. And in general, it’s enjoyable to consider the novel approach you’ve introduced.