My idea is, that is why we can/will just remove the limitations after a trial period. And then we can have cool stuff like Quantumroot.
1 Like
Really, we should just have everything working now so we never have to worry about this again… and so BCH is clearly lightyears ahead of the competition. 
Well I lack the technical competence to make the right decision, also evidence from more competent people I could use does not exist, so I will just drop this topic.
Maybe you can simply make the decision yourself?
Later, guys.
1 Like
Thanks heaps for writing these up Calin. I’m leaning towards (1) still also. In some ways, I actually think losing the static analyze-ability (for lack of better term) might be a perk because it makes it difficult for miners to omit evaluating transactions they think might be computationally expensive which I think might make the VM Limits CHIP more reliable as an indicator of inclusion (but it’s very possible I’ve overlooked something here).
Just a question on Take II:
This flag (and thus the restriction on how
OP_DEFINEcan be used) may be removed in a future Bitcoin Cash network upgrade in order to explicitly allow “code that writes code”.
If we do remove this restriction, can you think of any situations where it might make an existing contract insecure? E.g. I write a contract with the assumption that fCanDefineFunctions exists and, once removed, it then makes the contract-system I’ve developed insecure/vulnerable? This would probably be my biggest concern, but haven’t thought through whether that’s actually valid. If it is, we might want to look at doing something like this in tandem with something like an OP_ENV opcode? ( Wider discussion, an OP_ENV for the VM upgrades - #9 by tom )