Having larger numbers in script will simplify scripts[1] involving arbitrary satoshi amounts and other calculations. Perhaps even more importantly, it will make those scripts safer where the scripts are currently required to use additional artificial calculation techniques[2]. It is possible that it will increase the number of use cases as well, for example where artificial calculation techniques may not cover all needs or may be impossible to fit in script size limits.
Making op_mul available will have similar benefits by allowing multiplication instead of workarounds involving division or artificial calculation techniques.
The combination of larger integers and op_mul can be seen as a set that completes the basic calculation capability of Bitcoin Cash script. If they should be separated, I will remove op_mul from this topic.
I think this topic deserves discussion and evidence around:
- Benefits and risks of different sizes (64, 128, 256, 512, ā¦, bignum, other?) from a scripting safety and complexity perspective.
- Benefits and risks of different sizes from an implementation perspective.
- Desired behavior with respect to overflow.
- Desired behavior of op_mul.
- Should everything be done in one step, or should it be more than one to get to the end result?
[1] Two specific examples of use cases that would benefit from increased simplicity and safety:
- Mecenas, etc. scripts created by @Licho (predicting username here) and others are limited to about 20 BCH in the best case.
- The majority of complexity in AnyHedge contract is truncation math to get around the 31-bit positive integer limitation and retain precision. An alternative 60-bit math technique created by @Tobias_Ruck would solve the precision better, but still the vast majority of complexity would be a workaround for the 31-bit positive integer limitation.
[2] Artificial calculation techniques
- As linked above, 60-bit math technique created by @Tobias_Ruck
- Also as linked above, truncation math and precision recovery