# 64 bit arithmetic soft fork

**URL:** <https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397>\
**Category:** Protocol Design\
**Tags:** softfork\
**Created:** [January 10, 2024, 3:36pm UTC](https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397 "2024-01-10T15:36:12Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![ajtowns](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/ajtowns/32/417_2.png) [@ajtowns](https://delvingbitcoin.org/u/ajtowns)\
**Post date:** [January 11, 2024, 5:42pm UTC](https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397/13 "2024-01-11T17:42:51Z")

</div>

> [@sipa](#):
>
> One possibility is having an `OP_ENABLE64BIT`, which has no effect on the stack when executed, but its presence in a script makes all arithmetic opcodes accept up to 8-byte inputs for example.

The semantics proposed here copy those from liquid/elements – that is maths opcodes like ADD and SUB tend to leave two two values to the stack, on the top, a boolean TRUE/FALSE indicating whether the operands were in range, and if they were, underneath that, the actual result of the operation. That’s pretty different to the way bitcoin’s existing operations work, so I’m not sure modifying the existing opcodes to such a different new behaviour makes sense.

---

_[View the full topic](https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397)._