bitjson
commented
2 months ago I think this issue is resolved after https://github.com/bitjson/bch-vm-limits/commit/4eba48ea4648a5ad39f40ff11bfebbe3459fca83 – @cculianu, do you think we need to add any further clarifications now about when particular limits apply?
I drafted the latest spec updates as if limits are always aggressively applied (before even running the relevant operation), but unless I'm missing something, implementations can choose how aggressive they want to be. (Tradeoff code complexity for saving cycles here and there vs. maliciously-invalid transactions.)
E.g. in BCHN it would be possible to limit control stack depth only within the OP_IF and OP_NOTIF case statements, but the performance improvement would be trivial compared to the defense-in-depth of simply checking the control stack depth at the bottom of the opcode switch block (i.e. after every operation). I think the same tradeoff applies to all the runtime limits (operation cost, hashing, and sigchecks): any combination of 1) tallying things up and checking them at the bottom or 2) aggressive checking and bailing early, produces the same valid/invalid net results.
cculianu
I would suggest the specification specify that the 130,000 byte limit is enforced after the currently-executed OP code completes.
Why specify this? Because it makes it very clear and future-proofs the specification.
Note: the current stack limit of 1000 only is enforced after the execution of the current OP code completes.
Further rationale: We may introduce future opcodes that are complex and that temporarily exceed limits, only to resume back to below-limit after op-code-completion. As such, the limit should be specified to apply at some specific point. And it makes sense to mirror current operation of the stack depth limit (which only applies the stack depth limit after the current op-code completes execution).