Great answer. I hadn’t thought of it from that angle. Thank you.
Hi all, I just opened an MR to update the CHIP for this with a full spec for the 64-bit + OP_MUL proposal. I’d appreciate any feedback either here or on the MR:
(Direct link to contents:)
The spec is excessively complex because the normative definition of overflows refers to X86-64 GNU C Integer Overflow Builtins, instead of simply referring to mathematics. I would recommend to rewrite the definition of overflows using simple mathematics. For example, use this definition of 64-bit math:
The valid number range is from -9223372036854775807 to +9223372036854775807 inclusive. Both inputs and outputs must lie within this range. Otherwise, an overflow error occurs, causing script execution to fail immediately.
Implementations are then free to decide how to compute whether the result lies within this range and if so, what the result is. Any usage of X86-64 GNU C Integer Overflow Builtins in combination with blacklisting -9223372036854775808 then becomes an optional implementation consideration that can be mentioned in a separate section.
@bitjson at this point I only have one comment, and that is on the test vectors which at the moment cover only valid and invalid representations of integers, but should, I think, be extended to cover the upgraded operations.
i.e. testing of operations with results that would’ve previously just exceeded the 32 bit floor/ceiling and testing the new floor and ceiling with overflow / underflow cases from various operators.
EDIT: nevermind the above, I was looking at the script vectors section. Now I see you already have a separate Test Cases section which is still in progress.
Also, reading back in this thread to the good idea from @emergent_reasons about a regression test on past transactions … I suppose that could be done by just revalidating past blocks going back suitably far with the upgraded integer logic. Really curious to see if there would be any surprises there.