It is clarified that while literals such as OP_0, OP_1, OP_2, etc., occupy only one byte on disk, they expand to eight bytes in memory when pushed onto the stack. This expansion impacts memory consumption and is restricted to the numbers 0-16. For numbers greater than 16, an 8-byte representation must be added to the script, leading to the suggestion that variable length encoding should remain the default to avoid extra costs.

The conversation also touches upon the integration of RISC-V emulation within Bitcoin Script, referencing a project called Eltrace. The email highlights the potential benefits of adding support for converting numbers to a 32/64-bit little-endian (LE) format during script execution without necessitating full arithmetic support for another format. The importance of 64-bit arithmetic is underscored by its utility in enforcing values on subsequent transactions, noting that most relevant values are encoded in fixed-length LE format.

Furthermore, the handling of these scenarios is suggested to be dependent on the introspection opcodes, which could be designed to place ScriptNum on the stack. The writer recommends reviewing Rusty Russell's piece titled Arithmetic Opcodes: What Could They Look Like? for further insights. Finally, the idea of moving to unsigned-only values is entertained as it could streamline complexities, particularly if this change is made backwards compatible with the existing ScriptNum format for positive numbers. The possibility of repurposing existing opcodes by updating the leaf version is also mentioned, potentially eliminating the need for new opcodes like OP_ADDV.