This consideration is particularly focused on whether to require all existing op codes to accept 8-byte inputs, which would be made backwards compatible through the use of a SigVersion. An alternative approach being discussed is to simply add new arithmetic op codes that would handle 64-bit numbers and provide conversion op codes—OP_LE64TOSCRIPTNUM, OP_SCRIPTNUMTOLE64, OP_LE32TOLE64—to allow for compatibility with stack items from older scripts.

The proposal leans toward the latter option, which does not mandate an across-the-board input size change for existing op codes such as OP_CLTV, OP_CSV, OP_WITHIN, or OP_DEPTH. This means that while legacy Scripts like p2sh, p2wsh, and p2trsp would not need to be rewritten, script programmers who wish to utilize the enhanced capabilities offered by the proposed soft fork would need to update their Scripts accordingly if they want to take advantage of the new 8-byte input requirement. The decision at hand is whether the benefits justify the complexity added by requiring all inputs to existing op codes to be 8 bytes. The author of the proposal is seeking feedback from peers to gauge interest and evaluate whether the additional effort required is proportional to the value it brings.