Yes. I'd be interested in hearing your plans for byte code
verification; as far as I can tell it is a halting problem, and the
false sense of security it might provide is one of the reasons it was
removed from Lua 5.2.
I wonder whether it'd be more worthwhile coming at it from the other side, optionally hardening the Lua VM against malicious bytecode. AFAIK, the weakness to bytecode is in the form of unchecked object types and free stack space, the sort of thing that some #ifdef'd checks could find at minimal runtime cost. Alternatively, source could be sent instead of bytecode, compiled on the receiving end (and compared to a hash of the original bytecode, to suss out compiler differences) and the stack state checked against the expected stack state for the instruction pointer.
Ben
