BIP draft: 64-bit arithmetic opcodes

[Christewart]

This BIP describes a soft fork to add 64-bit arithmetic op codes to bitcoin

Implementation: bitcoin/bitcoin#29221

[EthanHeilman]

Why not push the overflow amount and the result back on the stack?

Rather than $2^{64}-1 + 3 = \mbox{FALSE}$, do $2^{64}-1 + 3 = 2, 1$. Where $2 = 2^{64}-1 + 3 \mod 2^{64}$ is the result and 1 is the overflow.

This would simply doing 256-bit math from 64-bit stack elements and I don't see any downsides for 64-bit operations.

[Christewart]

Why not push the overflow amount and the result back on the stack?

Rather than 264−1+3=FALSE, do 264−1+3=2,1. Where 2=264−1+3mod264 is the result and 1 is the overflow.

This would simply doing 256-bit math from 64-bit stack elements and I don't see any downsides for 64-bit operations.

Sorry I don't understand this. Could you maybe give a more concrete example, perhaps on delvingbitcoin? We have a thread going here: https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397/25

[murchandamus]

I just did a light first pass. I noticed that this document may be missing a Rationale Section that describes design decisions, alternate approaches, and related work, and a Backwards Compatibility section.

You may want to add the "Post-History" header to the preamble to link to discussions of this proposal on the mailing list or forums.

[murchandamus]

Please refrain from issuing your own BIP numbers.

[murchandamus]

Maybe:

Suggested change

	Title: 64 bit arithmetic operations
	Title: 64-bit arithmetic operations

[murchandamus]

Hey @Christewart, are you still working on this?

[Christewart]

Hey @Christewart, are you still working on this?

Yep i'm going to give it another go. I'll update soon.

[EthanHeilman]

I want to make sure I understand, this isn't proposing new opcodes that handle 64-bit arithmetic is it redefining the existing opcodes. Is that correct? It's probably on your TODO list, but what is the mechanism you are using to make this a softfork? Script versioning?

In the future we may wish to increase the supported precision again. What about adding a precision commitment to make soft-forking precision upgrades easier? For instance OP_PUSH x, OP_PRECIS, if x >64 then P_PUSH x OP_PRECIS is an OP_SUCCESSx. Then if we soft precision to 128 bits, OP_PUSH x, OP_PRECIS becomes a NOP.

[Christewart]

Hi Ethan thanks for your continued interest in this topic.

I want to make sure I understand, this isn't proposing new opcodes that handle 64-bit arithmetic is it redefining the existing opcodes. Is that correct?

👍

It's probably on your TODO list, but what is the mechanism you are using to make this a softfork? Script versioning?

My latest thinking for the upgrade mechanism is allocating a new tap leaf version to indicate the precision of arithmetic operations for Script. This was suggested by @sipa here. You can read about how this works on delving bitcoin and see my implementation of it here inside the bitcoin c++ code base.

I personally think this makes Scripts easier to reason about as the leaf version indicates the precision of all numeric operations during this Script's execution. If we want to increase precision again in the future, we can allocate a new leaf version and extend the underlying precision of CScriptNum and expose that functionality as I've done here

https://github.com/Christewart/bitcoin/blob/20fe67b5e4f2db7326ba5b8771c4516a7010861e/src/script/interpreter.cpp#L257

In the future we may wish to increase the supported precision again. What about adding a precision commitment to make soft-forking precision upgrades easier?

Committing to arbitrary precision seems hard, but i think this BIP lays the groundwork for extending precision in the future by making the precision of arithmetic operations linked with new tapleaf versions.

I pushed to this branch staged changes in a haphazard state, apologies. I'm working on a BIP currently to disallow 64 byte transactions in the bitcoin blockchain as I think that is more likely to be widely accepted by the community, and then will be coming back to this work.

[murchandamus]

Hi @Christewart, it’s my understanding that this document is currently not ready for BIP Editor review, so I have labeled the pull request as Draft. Please let us know when you would like us to take a look by returning it to "Ready for Review" when it has been updated.

[Roasbeef]

Big thumbs down at the idea of just pasting a blob of C++ code vs actually specifying the semantics of the new op codes.