[Proposal] 64-bit arithmetic in Script

The ongoing discussion on the Great Opcode Restoration (GSR) initiative has attracted attention and prompted a request for updates regarding its progress since Rusty’s last public exposition approximately a year and a half ago, as detailed in his blog post The Great Opcode Restoration. There’s an interest in any new materials, including additional posts, work-in-progress Bitcoin Improvement Proposals (BIPs), or code, that could provide further insight or allow for prototyping and discussion. Despite not opposing the broad goals of GSR, concerns have been raised about its ambitious nature, particularly around the implementation of 64-bit precision to enable amount locks which is seen as a highly requested feature.

The conversation delves into the technical aspects, questioning the necessity of arbitrary precision beyond 64-bit arithmetic for executing certain opcodes. Two specific operations from the Elements project, ECMULSCALARVERIFY and TWEAKVERIFY, are highlighted as examples that operate on 256-bit stack arguments and verify cryptographic conditions without the need for parsing into CScriptNum, thus questioning the requirement for supporting more precision in Script. These operations, found at respective links ECMULSCALARVERIFY and TWEAKVERIFY, do not support composition with existing arithmetic opcodes like OP_ADD or OP_SUB, but simply verify cryptographic conditions.

There's an expressed interest in compiling a list of potential opcodes that would benefit from arbitrary precision in a centralized location. This compilation would assist other protocol developers by providing a comprehensive view of the possibilities enabled by such precision. The message concludes with an inquiry on how one can contribute to this effort, indicating a desire for collaborative development and feedback within the Bitcoin development community.