64 bit arithmetic soft fork

The discussion begins by addressing a misconception about the impact of certain Bitcoin operation codes (opcodes) on memory and disk space. Specifically, it is clarified that literals like OP_0, OP_1, and OP_2 consume only 1 byte in terms of disk space but their interpretation based on signature version could lead to an increase in memory consumption, as they expand to 8 bytes when pushed onto the stack.

The conversation then shifts to Bitcoin Improvement Proposal 62 (BIP62), which is noted not for optimizing disk space but for addressing transaction malleability issues. Transaction malleability has been problematic for Bitcoin businesses by causing them to lose track of withdrawals; the infamous MtGox incident is cited as an example. The introduction of the fRequireMinimal flag in the Bitcoin interpreter, referenced by a specific commit, is tied back to BIP62 rules 3 and 4, further emphasizing that the intent was not to reduce disk space usage.

Subsequently, there's a proposal to simplify the interpreter.cpp for future soft forks by eliminating the need for SCRIPT_VERIFY_MINIMALDATA. This is seen as a potential benefit arising from the discussed changes. However, the current proposal does not address encoding for push operations, which the author plans to research further.

The conversation touches on the existence of the CScriptNum class due to its historical use of the OpenSSL number implementation, although this point remains unconfirmed due to challenges in tracking the history on GitHub.

A suggestion is made to consolidate the multiple number encodings in the Bitcoin protocol into a single format. Currently, two formats exist: the traditional int64_t and the "exotic" one introduced by Satoshi, which has undergone modifications to address malleability issues. Moving away from these unique encodings toward standard representations used across the software ecosystem is advocated to streamline understanding and implementation.

Lastly, the implications of the proposal for wallet software are considered. It's believed that wallets using standard signing logic should not be affected. There's a recognition that OP_PUSHDATAx is not widely used, although its prevalence in the NFT space may be an exception. The overarching sentiment is that standardizing Bitcoin's numbering system will lead to future reflections on its current uniqueness as a mere historical quirk, rather than a continuing complication.