Mailing list post: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE
Delving bitcoin discussion: https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397
S/o to the “Write a BIP” talk at btc++ by Ava Chow to motivate me to actually submit this :-)
If you are interested in previous versions of this idea, see #1538 and #1533
105+
106+<references />
107+
108+==Copyright==
109+
110+This document is placed in the public domain.
12+</pre>
13+
14+==Abstract==
15+
16+This BIP proposes to extend the range of numeric operands in Script from -2^<sup>31</sup>+1 to 2^<sup>31</sup>-1, to -2^<sup>63</sup>+1 to 2^<sup>63</sup>-1.
17+It further expands the result range for arithmetic operations from -2^<sup>63</sup> to 2^<sup>63</sup>-1, to -2^<sup>127</sup> to 2^<sup>127</sup>-1.
Would this change help?
“this BIP is intentionally limited to supporting 64 bits of precision” -> “this BIP is intentionally limited to supporting 64-bit operands”.
If :+1: I will make that change.
However, I was unable to find anything that explains how results overflowing the supported range are to be handled.
Here is the foot note that is intended to cover it. Namely, we retain existing overflow semantics (i.e. an exception) if an arithmetic operation is performed on a value larger than 64 bits.
Sorry, I must have skimmed a bit too quickly. It’s wild that we can return numbers larger than what we’d accept as inputs. TIL.
I think the rephrasing would be an improvement.
It’s wild that we can return numbers larger than what we’d accept as inputs.
Agree, while this BIP tries to make as conservative choices as possible with changing the semantics of interpreting numbers in Script, there are other efforts that would like to make more radical changes if the topic is of interest to you. From a cursory glance I can’t tell if GSR changes this or not - but definitely would be a discussion worth happening in that proposal as its more aggressive.
If you have better things to do, I also understand :joy:
75+
76+BIP342 permits the introduction of new opcodes that bypass the 520-byte push size limitation.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki Since OP_SUCCESSx precedes the size check for the initial stack and push opcodes, an OP_SUCCESSx-derived opcode requiring stack elements larger than 520 bytes could uplift the limit in a soft fork]</ref>
77+This mechanism could theoretically allow for arbitrary-precision numeric operations.
78+However, the scope of this BIP is intentionally limited to supporting 64 bits of precision, sufficient for expressing native Bitcoin amounts.
79+
80+==Detailed Specification==
Did you mean:
0==Reference Implementation==
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
57+
58+Given that Bitcoin amounts can occupy up to 51 bits, OP_AMOUNTVERIFY and related CTV enhancements would benefit from support for 64-bit arithmetic operations.
59+
60+==Specification==
61+
62+All existing opcodes<ref name="numeric-opcodes" /> that interpret stack elements as numbers are modified to support 64-bit operands.
I intended the reconciliation to happen in the deployment section.
I think the most optimal deployment story is this BIP gets bundled with a wider set of BIPs that actually allocate a new opcode - ideally any of the 4 BIPs cited in the motivation section. Multiple BIPs were deployed as part of Taproot and segwit so I don’t think this would be a problem.
An alternative that has been discussed is an OP_ENABLE64BIT opcode that uses the OP_SUCCESS semantics if this proposal was deployed on its own. I would advocate for taking the former path rather than allocating a speicific opcode like OP_ENABLE64BIT though.
With that being said, if you think this can be reworded to be clearer, or perhaps deleting parts that are confusing, I’m interested in hearing your thoughts.
Perhaps I’m being a bit dense, but isn’t that what I’m already saying the deployment section. Is the OP_ENABLE64BIT opcode the part you would like me to add?
Or do you want me to add a section about the deployment story in the specification section?
The way I understand the first line of the Specification (“All existing opcodes that interpret stack elements as numbers are modified to support 64-bit operands”) and the first line of the Abstract (“This BIP proposes to extend the range of numeric operands in Script […]”), it sounds that your proposal would modify all number processing opcodes in all versions of Script , but the Backward Compatibility section states that it should be deployed as a soft fork, and the Deployment section mentions OP_SUCCESSx semantics. It seems to me that there is an unstated assumption here that’s the missing link. Extending the accepted inputs of opcodes in Script or Tapscript would be a hard fork, so you may be thinking that the 64-bit arithmetic would only be introduced for a new script leaf version, but if so, I missed where the proposal explains this restricted scope.
I was hoping that you would update the phrasing of those sections to clarify in what scope the changed opcode behavior is introduced, so that the sections are compatible and it becomes obvious how this proposal could be deployed as a soft fork.
I think we’re still crossing the wires. It seems to me that the arithmetic opcodes could only be upgraded to 64-bit inputs if there is an OP_SUCCESS opcode present in that very same script, not generally by introducing a new OP_SUCCESS-based opcode. I don’t see how the 64-bit arithmetic could be introduced into legacy script, as OP_SUCCESS opcodes only exist in Tapscript.
It sounds to me that it could be made to work in a script that already has a new opcode that was introduced per an OP_SUCCESSx upgrade hook, or if there were a new opcode that explicitly toggles 64-bit arithmetic on for the script it appears in, introduced per an OP_SUCCESSx opcode. Although, it seems somewhat awkward if some opcodes work differently depending on the presence of another opcode.
Alternatively, the arithmetic opcodes could be reimplemented on basis of OP_SUCCESS opcodes, but I’m not sure that’s what you meant.