I don't think Elements engineering decisions or management timelines should have any bearing on what Bitcoin adopts, beyond learning what works/doesn't. Same as litecoin, dogecoin, or bitcoin cash :)
With my understanding of elements it makes sense that you wouldn't want to break compatibility script version to script version, although that seems inevitable that you will need to either hard fork or break compatibility if you want to fix the CHECKSIGFROMSTACK has verify semantics bug. But perhaps that's a smaller change than the # of stack elements popped? It makes sense having CAT that adding a split CSFS wouldn't be a priority. However, I'd suggest that as far as elements is concerned, if the bitcoin community decides on something that is incompatible, elements can use up some addition opcodes or a keytype to add CSFS_BITCOIN_COMPAT ops.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
