64 bit arithmetic soft fork

[halseth]

@sipa

Moreover, it has the enormous benefit of being already implemented, tested, deployed, and in use.

I find the arguments pretty convincing; if we can enable 64-bit arithmetics using the existing CSScriptNum implementation, that sounds desirable.

I do see the benefits of having a more approachable number format available for new developers, but CScriptNum is already there so they kinda have to deal with it in some form anyway.

@sipa

it’s minimal-length big endian, which for literals inside the script has the advantage of being more compact than forcing a full length constant.

If we introduce fixed-size LE version in addition to the existing minimal-length BE, this could possibly give developers incentives to convert between them and only use the fixed-length types when needed to save on space. Not saying this is a dealbreaker, but it could slow the clean transition to a 64 bit number version.

@Chris_Stewart_5

Perhaps I am not understanding what this alternative implementation looks like, so please correct me if I am wrong.

There might be some edge cases in using the existing CScriptNum type for 8 byte values, but if I understand @sipa correctly, it could be as easy as this: interpreter: allow 8 byte CScriptNum by halseth · Pull Request #1 · halseth/bitcoin · GitHub

(This includes 64-bit support for all the numeric opcodes, including OP_WITHIN, OP_1ADD etc)

We already have leaf_version available from the interpreter, so it’s just about defining a new one.

@sipa

If OP_MUL or a variant thereof is added, I can see why detecting/dealing with overflows becomes an issue that the existing interface doesn’t deal well with.

If we want to re-enable these opcodes, it would be nice indeed to have them be backwards compatible with the existing number format (still with a leaf_version bump of course).