* [bitcoindev] [Proposal] 64-bit arithmetic in Script
@ 2025-05-12 16:15 Chris Stewart
2025-05-12 19:32 ` Martin Habovštiak
0 siblings, 1 reply; 6+ messages in thread
From: Chris Stewart @ 2025-05-12 16:15 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]
This soft fork proposal extends the range of numeric operands in Script
from -2^31+1 to 2^31-1, to -2^63+1 to 2^63-1. It further expands the result
range for arithmetic operations from -2^63 to 2^63-1, to -2^127 to 2^127-
1.
All existing opcodes[1
<https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-1>
] that interpret stack elements as numbers are upgraded to support 64-bit
parameters.
The existing number encoding format[2
<https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-2>
] and arithmetic semantics[3
<https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-3>
] from the original Bitcoin implementation are preserved, while enhancing
the supported precision.
https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
The purpose for this BIP is to lay the groundwork for introducing amounts
into Script. This document takes no opinion on how this is done.
I've prototyped a few different proposals now introducing amount locks into
Script[0][1] and feel like this proposal is stable enough for serious
review.
-Chris
[0] - https://delvingbitcoin.org/t/op-inout-amount/549/4?u=chris_stewart_5
[1] - https://delvingbitcoin.org/t/op-inout-amount/549/5?u=chris_stewart_5
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2669 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script
2025-05-12 16:15 [bitcoindev] [Proposal] 64-bit arithmetic in Script Chris Stewart
@ 2025-05-12 19:32 ` Martin Habovštiak
2025-05-13 9:03 ` Chris Stewart
0 siblings, 1 reply; 6+ messages in thread
From: Martin Habovštiak @ 2025-05-12 19:32 UTC (permalink / raw)
To: Chris Stewart; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3116 bytes --]
Hi,
the proposal seems to be quite confused about how it's going to do that. It
mentions upgrading existing opcodes, which is a hardfork, not soft fork, at
least without using a different leaf version. But it also mentions
OP_SUCCESSX which are different opcodes. I think it needs some analysis.
(leaf version seems better intuitively)
I'd also love to see analysis why stop at 64 bits and not go all the way to
256 which could be useful for cryptography.
Anyway, pushing amounts on the stack would be great. Though I'm surprised
you're only proposing the sum, not individual outputs. Why?
Good luck!
Martin
Dňa po 12. 5. 2025, 14:21 Chris Stewart <stewart.chris1234@gmail•com>
napísal(a):
> This soft fork proposal extends the range of numeric operands in Script
> from -2^31+1 to 2^31-1, to -2^63+1 to 2^63-1. It further expands the
> result range for arithmetic operations from -2^63 to 2^63-1, to -2^127 to
> 2^127- 1.
>
> All existing opcodes[1
> <https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-1>
> ] that interpret stack elements as numbers are upgraded to support 64-bit
> parameters.
>
> The existing number encoding format[2
> <https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-2>
> ] and arithmetic semantics[3
> <https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-3>
> ] from the original Bitcoin implementation are preserved, while enhancing
> the supported precision.
>
>
> https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
>
> The purpose for this BIP is to lay the groundwork for introducing amounts
> into Script. This document takes no opinion on how this is done.
>
> I've prototyped a few different proposals now introducing amount locks
> into Script[0][1] and feel like this proposal is stable enough for serious
> review.
>
> -Chris
>
> [0] - https://delvingbitcoin.org/t/op-inout-amount/549/4?u=chris_stewart_5
>
> [1] - https://delvingbitcoin.org/t/op-inout-amount/549/5?u=chris_stewart_5
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALkkCJbeAYA2X8jv8iWthKBB8GqxA49DCFm%2BUMnhmXYpexTNtw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4896 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script
2025-05-12 19:32 ` Martin Habovštiak
@ 2025-05-13 9:03 ` Chris Stewart
2025-05-13 11:44 ` Christian Decker
0 siblings, 1 reply; 6+ messages in thread
From: Chris Stewart @ 2025-05-13 9:03 UTC (permalink / raw)
To: Martin Habovštiak; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6262 bytes --]
Hi Martin
Thanks for your interest in the topic.
>It mentions upgrading existing opcodes, which is a hardfork, not soft
fork, at least without using a different leaf version. But it also mentions
OP_SUCCESSX which are different opcodes
I view 64-bit arithmetic as a feature of a wider set of consensus changes.
Here is what I think the most likely deployment story is
>This proposal could be deployed in conjunction with any of the new opcode
proposals in the Motivation section using Tapscript's OP_SUCCESSx semantics.
[18
<https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-18>
]
The opcodes mentioned in the motivation section are OP_{IN,OUT}_AMOUNT,
OP_VAULT, OP_CHECKCONTRACTVERIFY, OP_CTV
As an example, this proposal could (hypothetically) be deployed in
conjunction with OP_CCV. OP_CCV would take advantage of the OP_SUCCESSx
semantics allowing us to redefine existing opcode's (OP_ADD,OP_SUB, etc)
semantics.
There’s been some discussion
<https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/48?u=chris_stewart_5>
around deploying OP_CTV via a NOP opcode instead of OP_SUCCESSx. I think
that would be a poor choice, as it wouldn’t allow new Script features to be
shipped in parallel with the new opcode.
I found this StackExchange post <https://bitcoin.stackexchange.com/q/125237>
helpful in thinking through various deployment strategies for new
Tapscript-based consensus upgrades.
>I'd also love to see analysis why stop at 64 bits and not go all the way
to 256 which could be useful for cryptography.
In my view, there’s still a lot of uncertainty about cryptographic features
being added to Script. There's increasing discussion around quantum
computing, which raises the question of how much numerical precision we may
eventually need. I'm not opposed to extending precision further—but if we
go beyond 64 bits, why stop at 256? With OP_SUCCESSx, arbitrary precision
becomes a real option <https://bitcoin.stackexchange.com/a/126153/20835>.
I chose 64 bits because it covers what’s needed for amount locks. If
someone strongly believes that 64 bits isn't enough, I’d welcome a
competing BIP and would be happy to review and discuss it with the author.
>Anyway, pushing amounts on the stack would be great. Though I'm surprised
you're only proposing the sum, not individual outputs. Why?
Good question—and slightly out of scope for this BIP. Script doesn’t
support looping, so it’s not straightforward to iterate over and sum all
elements unless the transaction structure (i.e., number of inputs or
outputs) is known in advance.
You can measure the number of stack elements with OP_DEPTH, but there’s no
way to write something like OP_ADD [num-stack-elements-from-OP_DEPTH] to
sum them all. I’m definitely open to hearing other approaches, though.
-Chris
On Mon, May 12, 2025 at 2:32 PM Martin Habovštiak <
martin.habovstiak@gmail•com> wrote:
> Hi,
>
> the proposal seems to be quite confused about how it's going to do that.
> It mentions upgrading existing opcodes, which is a hardfork, not soft fork,
> at least without using a different leaf version. But it also mentions
> OP_SUCCESSX which are different opcodes. I think it needs some analysis.
> (leaf version seems better intuitively)
>
> I'd also love to see analysis why stop at 64 bits and not go all the way
> to 256 which could be useful for cryptography.
>
> Anyway, pushing amounts on the stack would be great. Though I'm surprised
> you're only proposing the sum, not individual outputs. Why?
>
> Good luck!
>
> Martin
>
> Dňa po 12. 5. 2025, 14:21 Chris Stewart <stewart.chris1234@gmail•com>
> napísal(a):
>
>> This soft fork proposal extends the range of numeric operands in Script
>> from -2^31+1 to 2^31-1, to -2^63+1 to 2^63-1. It further expands the
>> result range for arithmetic operations from -2^63 to 2^63-1, to -2^127
>> to 2^127- 1.
>>
>> All existing opcodes[1
>> <https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-1>
>> ] that interpret stack elements as numbers are upgraded to support
>> 64-bit parameters.
>>
>> The existing number encoding format[2
>> <https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-2>
>> ] and arithmetic semantics[3
>> <https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki#cite_note-3>
>> ] from the original Bitcoin implementation are preserved, while
>> enhancing the supported precision.
>>
>>
>> https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
>>
>> The purpose for this BIP is to lay the groundwork for introducing amounts
>> into Script. This document takes no opinion on how this is done.
>>
>> I've prototyped a few different proposals now introducing amount locks
>> into Script[0][1] and feel like this proposal is stable enough for serious
>> review.
>>
>> -Chris
>>
>> [0] -
>> https://delvingbitcoin.org/t/op-inout-amount/549/4?u=chris_stewart_5
>>
>> [1] -
>> https://delvingbitcoin.org/t/op-inout-amount/549/5?u=chris_stewart_5
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to bitcoindev+unsubscribe@googlegroups•com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9096 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script
2025-05-13 9:03 ` Chris Stewart
@ 2025-05-13 11:44 ` Christian Decker
2025-05-14 8:23 ` Chris Stewart
0 siblings, 1 reply; 6+ messages in thread
From: Christian Decker @ 2025-05-13 11:44 UTC (permalink / raw)
To: Chris Stewart; +Cc: Martin Habovštiak, Bitcoin Development Mailing List
Hi Chris,
quite an interesting proposal, but much like Martin I wonder if we
shouldn't go beyond. For comparison Rusty's GSR comprises arbitrary
sized integers and their associated operations, with fine-grained
accounting of operations based on the operands size, so scripts stay
performant and manageable.
That proposal is much further along in both design and analysis, so
maybe you could join that effort for your use-cases too?
Cheers,
Christian
On Tue, May 13, 2025 at 11:06 AM Chris Stewart
<stewart.chris1234@gmail•com> wrote:
>
> Hi Martin
>
> Thanks for your interest in the topic.
>
> >It mentions upgrading existing opcodes, which is a hardfork, not soft fork, at least without using a different leaf version. But it also mentions OP_SUCCESSX which are different opcodes
>
> I view 64-bit arithmetic as a feature of a wider set of consensus changes. Here is what I think the most likely deployment story is
>
> >This proposal could be deployed in conjunction with any of the new opcode proposals in the Motivation section using Tapscript's OP_SUCCESSx semantics.[18]
>
> The opcodes mentioned in the motivation section are OP_{IN,OUT}_AMOUNT, OP_VAULT, OP_CHECKCONTRACTVERIFY, OP_CTV
>
> As an example, this proposal could (hypothetically) be deployed in conjunction with OP_CCV. OP_CCV would take advantage of the OP_SUCCESSx semantics allowing us to redefine existing opcode's (OP_ADD,OP_SUB, etc) semantics.
>
> There’s been some discussion around deploying OP_CTV via a NOP opcode instead of OP_SUCCESSx. I think that would be a poor choice, as it wouldn’t allow new Script features to be shipped in parallel with the new opcode.
>
> I found this StackExchange post helpful in thinking through various deployment strategies for new Tapscript-based consensus upgrades.
>
> >I'd also love to see analysis why stop at 64 bits and not go all the way to 256 which could be useful for cryptography.
>
> In my view, there’s still a lot of uncertainty about cryptographic features being added to Script. There's increasing discussion around quantum computing, which raises the question of how much numerical precision we may eventually need. I'm not opposed to extending precision further—but if we go beyond 64 bits, why stop at 256? With OP_SUCCESSx, arbitrary precision becomes a real option.
>
> I chose 64 bits because it covers what’s needed for amount locks. If someone strongly believes that 64 bits isn't enough, I’d welcome a competing BIP and would be happy to review and discuss it with the author.
>
> >Anyway, pushing amounts on the stack would be great. Though I'm surprised you're only proposing the sum, not individual outputs. Why?
>
> Good question—and slightly out of scope for this BIP. Script doesn’t support looping, so it’s not straightforward to iterate over and sum all elements unless the transaction structure (i.e., number of inputs or outputs) is known in advance.
> You can measure the number of stack elements with OP_DEPTH, but there’s no way to write something like OP_ADD [num-stack-elements-from-OP_DEPTH] to sum them all. I’m definitely open to hearing other approaches, though.
>
> -Chris
>
>
>
> On Mon, May 12, 2025 at 2:32 PM Martin Habovštiak <martin.habovstiak@gmail•com> wrote:
>>
>> Hi,
>>
>> the proposal seems to be quite confused about how it's going to do that. It mentions upgrading existing opcodes, which is a hardfork, not soft fork, at least without using a different leaf version. But it also mentions OP_SUCCESSX which are different opcodes. I think it needs some analysis. (leaf version seems better intuitively)
>>
>> I'd also love to see analysis why stop at 64 bits and not go all the way to 256 which could be useful for cryptography.
>>
>> Anyway, pushing amounts on the stack would be great. Though I'm surprised you're only proposing the sum, not individual outputs. Why?
>>
>> Good luck!
>>
>> Martin
>>
>> Dňa po 12. 5. 2025, 14:21 Chris Stewart <stewart.chris1234@gmail•com> napísal(a):
>>>
>>> This soft fork proposal extends the range of numeric operands in Script from -2^31+1 to 2^31-1, to -2^63+1 to 2^63-1. It further expands the result range for arithmetic operations from -2^63 to 2^63-1, to -2^127 to 2^127- 1.
>>>
>>> All existing opcodes[1] that interpret stack elements as numbers are upgraded to support 64-bit parameters.
>>>
>>> The existing number encoding format[2] and arithmetic semantics[3] from the original Bitcoin implementation are preserved, while enhancing the supported precision.
>>>
>>> https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
>>>
>>> The purpose for this BIP is to lay the groundwork for introducing amounts into Script. This document takes no opinion on how this is done.
>>>
>>> I've prototyped a few different proposals now introducing amount locks into Script[0][1] and feel like this proposal is stable enough for serious review.
>>>
>>> -Chris
>>>
>>> [0] - https://delvingbitcoin.org/t/op-inout-amount/549/4?u=chris_stewart_5
>>>
>>> [1] - https://delvingbitcoin.org/t/op-inout-amount/549/5?u=chris_stewart_5
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
>>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALxbBHW8YD-F2N9PYcAii5wXfEAPratQ6i6ke-i59pdoFczSoA%40mail.gmail.com.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script
2025-05-13 11:44 ` Christian Decker
@ 2025-05-14 8:23 ` Chris Stewart
2025-05-14 8:27 ` Christian Decker
0 siblings, 1 reply; 6+ messages in thread
From: Chris Stewart @ 2025-05-14 8:23 UTC (permalink / raw)
To: Christian Decker; +Cc: Martin Habovštiak, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 8830 bytes --]
Hi Christian,
Thank you for the interest in this proposal!
I’d like to invite you, Rusty, or any other contributors to provide an
update to the list on the status of GSR. The most recent public writing I’m
aware of is Rusty’s blog post
<https://rusty.ozlabs.org/2024/01/19/the-great-opcode-restoration.html>,
which is now around 18 months old. Are there any newer materials — such as
additional posts, WIP BIPs, or code — that we could review or experiment
with? Even rough drafts would be helpful for prototyping and discussion.
I’m not opposed to the broader goals of GSR, but I do think it’s a bit
ambitious. That’s partly why I’ve focused my efforts on isolating what I
believe is the most requested feature: 64-bit precision to enable amount
locks.
>arbitrary sized integers
It would be helpful to see some concrete examples of opcodes that would
*require* arbitrary precision, but wouldn’t be achievable with 64-bit
arithmetic. Looking at the Elements project, there are a couple of examples
— ECMULSCALARVERIFY
<https://github.com/ElementsProject/elements/blob/7ed597f4a5f713e33aac04c87c1a9da5ecd7d52c/src/script/interpreter.cpp#L2193>
and TWEAKVERIFY
<https://github.com/ElementsProject/elements/blob/7ed597f4a5f713e33aac04c87c1a9da5ecd7d52c/src/script/interpreter.cpp#L2219>
— which operate on 256-bit stack arguments. Notably, these opcodes don’t
support composition with existing arithmetic opcodes like OP_ADD or OP_SUB;
they simply verify cryptographic conditions. I would argue they do not
actually require supporting more precision in Script as the stack arguments
aren't parsed into CScriptNum.
It could be useful to have a list of these potential opcodes that could be
enabled in a single place to give other protocol developers an idea of what
is enabled by arbitrary precision.
>maybe you could join that effort for your use-cases too?
Where can one go to join the effort?
-Chris
On Tue, May 13, 2025 at 6:45 AM Christian Decker <decker.christian@gmail•com>
wrote:
> Hi Chris,
>
> quite an interesting proposal, but much like Martin I wonder if we
> shouldn't go beyond. For comparison Rusty's GSR comprises arbitrary
> sized integers and their associated operations, with fine-grained
> accounting of operations based on the operands size, so scripts stay
> performant and manageable.
>
> That proposal is much further along in both design and analysis, so
> maybe you could join that effort for your use-cases too?
>
> Cheers,
> Christian
>
> On Tue, May 13, 2025 at 11:06 AM Chris Stewart
> <stewart.chris1234@gmail•com> wrote:
> >
> > Hi Martin
> >
> > Thanks for your interest in the topic.
> >
> > >It mentions upgrading existing opcodes, which is a hardfork, not soft
> fork, at least without using a different leaf version. But it also mentions
> OP_SUCCESSX which are different opcodes
> >
> > I view 64-bit arithmetic as a feature of a wider set of consensus
> changes. Here is what I think the most likely deployment story is
> >
> > >This proposal could be deployed in conjunction with any of the new
> opcode proposals in the Motivation section using Tapscript's OP_SUCCESSx
> semantics.[18]
> >
> > The opcodes mentioned in the motivation section are OP_{IN,OUT}_AMOUNT,
> OP_VAULT, OP_CHECKCONTRACTVERIFY, OP_CTV
> >
> > As an example, this proposal could (hypothetically) be deployed in
> conjunction with OP_CCV. OP_CCV would take advantage of the OP_SUCCESSx
> semantics allowing us to redefine existing opcode's (OP_ADD,OP_SUB, etc)
> semantics.
> >
> > There’s been some discussion around deploying OP_CTV via a NOP opcode
> instead of OP_SUCCESSx. I think that would be a poor choice, as it wouldn’t
> allow new Script features to be shipped in parallel with the new opcode.
> >
> > I found this StackExchange post helpful in thinking through various
> deployment strategies for new Tapscript-based consensus upgrades.
> >
> > >I'd also love to see analysis why stop at 64 bits and not go all the
> way to 256 which could be useful for cryptography.
> >
> > In my view, there’s still a lot of uncertainty about cryptographic
> features being added to Script. There's increasing discussion around
> quantum computing, which raises the question of how much numerical
> precision we may eventually need. I'm not opposed to extending precision
> further—but if we go beyond 64 bits, why stop at 256? With OP_SUCCESSx,
> arbitrary precision becomes a real option.
> >
> > I chose 64 bits because it covers what’s needed for amount locks. If
> someone strongly believes that 64 bits isn't enough, I’d welcome a
> competing BIP and would be happy to review and discuss it with the author.
> >
> > >Anyway, pushing amounts on the stack would be great. Though I'm
> surprised you're only proposing the sum, not individual outputs. Why?
> >
> > Good question—and slightly out of scope for this BIP. Script doesn’t
> support looping, so it’s not straightforward to iterate over and sum all
> elements unless the transaction structure (i.e., number of inputs or
> outputs) is known in advance.
> > You can measure the number of stack elements with OP_DEPTH, but there’s
> no way to write something like OP_ADD [num-stack-elements-from-OP_DEPTH] to
> sum them all. I’m definitely open to hearing other approaches, though.
> >
> > -Chris
> >
> >
> >
> > On Mon, May 12, 2025 at 2:32 PM Martin Habovštiak <
> martin.habovstiak@gmail•com> wrote:
> >>
> >> Hi,
> >>
> >> the proposal seems to be quite confused about how it's going to do
> that. It mentions upgrading existing opcodes, which is a hardfork, not soft
> fork, at least without using a different leaf version. But it also mentions
> OP_SUCCESSX which are different opcodes. I think it needs some analysis.
> (leaf version seems better intuitively)
> >>
> >> I'd also love to see analysis why stop at 64 bits and not go all the
> way to 256 which could be useful for cryptography.
> >>
> >> Anyway, pushing amounts on the stack would be great. Though I'm
> surprised you're only proposing the sum, not individual outputs. Why?
> >>
> >> Good luck!
> >>
> >> Martin
> >>
> >> Dňa po 12. 5. 2025, 14:21 Chris Stewart <stewart.chris1234@gmail•com>
> napísal(a):
> >>>
> >>> This soft fork proposal extends the range of numeric operands in
> Script from -2^31+1 to 2^31-1, to -2^63+1 to 2^63-1. It further expands the
> result range for arithmetic operations from -2^63 to 2^63-1, to -2^127 to
> 2^127- 1.
> >>>
> >>> All existing opcodes[1] that interpret stack elements as numbers are
> upgraded to support 64-bit parameters.
> >>>
> >>> The existing number encoding format[2] and arithmetic semantics[3]
> from the original Bitcoin implementation are preserved, while enhancing the
> supported precision.
> >>>
> >>>
> https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
> >>>
> >>> The purpose for this BIP is to lay the groundwork for introducing
> amounts into Script. This document takes no opinion on how this is done.
> >>>
> >>> I've prototyped a few different proposals now introducing amount locks
> into Script[0][1] and feel like this proposal is stable enough for serious
> review.
> >>>
> >>> -Chris
> >>>
> >>> [0] -
> https://delvingbitcoin.org/t/op-inout-amount/549/4?u=chris_stewart_5
> >>>
> >>> [1] -
> https://delvingbitcoin.org/t/op-inout-amount/549/5?u=chris_stewart_5
> >>>
> >>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups "Bitcoin Development Mailing List" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoindev+unsubscribe@googlegroups•com.
> >>> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoindev+unsubscribe@googlegroups•com.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A%40mail.gmail.com
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmFF8noQxXWy8PXBT9vSBQv0Hx3jn7cFtQMkv4PcnhyGyw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 11300 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script
2025-05-14 8:23 ` Chris Stewart
@ 2025-05-14 8:27 ` Christian Decker
0 siblings, 0 replies; 6+ messages in thread
From: Christian Decker @ 2025-05-14 8:27 UTC (permalink / raw)
To: Chris Stewart; +Cc: Martin Habovštiak, Bitcoin Development Mailing List
Hi Chris,
I was contacted by other ML members pointing out that the GSR may not
have announced on the ML. I was not aware, and would not have brought
it up as a competing effort in such a case.
Apologies for the noise, and I hope that an update on the idea and
current status of the GSR will be published eventually :-)
Regards,
Christian
On Wed, May 14, 2025 at 10:24 AM Chris Stewart
<stewart.chris1234@gmail•com> wrote:
>
> Hi Christian,
>
> Thank you for the interest in this proposal!
>
> I’d like to invite you, Rusty, or any other contributors to provide an update to the list on the status of GSR. The most recent public writing I’m aware of is Rusty’s blog post, which is now around 18 months old. Are there any newer materials — such as additional posts, WIP BIPs, or code — that we could review or experiment with? Even rough drafts would be helpful for prototyping and discussion.
>
> I’m not opposed to the broader goals of GSR, but I do think it’s a bit ambitious. That’s partly why I’ve focused my efforts on isolating what I believe is the most requested feature: 64-bit precision to enable amount locks.
>
> >arbitrary sized integers
>
> It would be helpful to see some concrete examples of opcodes that would require arbitrary precision, but wouldn’t be achievable with 64-bit arithmetic. Looking at the Elements project, there are a couple of examples — ECMULSCALARVERIFY and TWEAKVERIFY — which operate on 256-bit stack arguments. Notably, these opcodes don’t support composition with existing arithmetic opcodes like OP_ADD or OP_SUB; they simply verify cryptographic conditions. I would argue they do not actually require supporting more precision in Script as the stack arguments aren't parsed into CScriptNum.
>
> It could be useful to have a list of these potential opcodes that could be enabled in a single place to give other protocol developers an idea of what is enabled by arbitrary precision.
>
> >maybe you could join that effort for your use-cases too?
>
> Where can one go to join the effort?
>
> -Chris
>
>
> On Tue, May 13, 2025 at 6:45 AM Christian Decker <decker.christian@gmail•com> wrote:
>>
>> Hi Chris,
>>
>> quite an interesting proposal, but much like Martin I wonder if we
>> shouldn't go beyond. For comparison Rusty's GSR comprises arbitrary
>> sized integers and their associated operations, with fine-grained
>> accounting of operations based on the operands size, so scripts stay
>> performant and manageable.
>>
>> That proposal is much further along in both design and analysis, so
>> maybe you could join that effort for your use-cases too?
>>
>> Cheers,
>> Christian
>>
>> On Tue, May 13, 2025 at 11:06 AM Chris Stewart
>> <stewart.chris1234@gmail•com> wrote:
>> >
>> > Hi Martin
>> >
>> > Thanks for your interest in the topic.
>> >
>> > >It mentions upgrading existing opcodes, which is a hardfork, not soft fork, at least without using a different leaf version. But it also mentions OP_SUCCESSX which are different opcodes
>> >
>> > I view 64-bit arithmetic as a feature of a wider set of consensus changes. Here is what I think the most likely deployment story is
>> >
>> > >This proposal could be deployed in conjunction with any of the new opcode proposals in the Motivation section using Tapscript's OP_SUCCESSx semantics.[18]
>> >
>> > The opcodes mentioned in the motivation section are OP_{IN,OUT}_AMOUNT, OP_VAULT, OP_CHECKCONTRACTVERIFY, OP_CTV
>> >
>> > As an example, this proposal could (hypothetically) be deployed in conjunction with OP_CCV. OP_CCV would take advantage of the OP_SUCCESSx semantics allowing us to redefine existing opcode's (OP_ADD,OP_SUB, etc) semantics.
>> >
>> > There’s been some discussion around deploying OP_CTV via a NOP opcode instead of OP_SUCCESSx. I think that would be a poor choice, as it wouldn’t allow new Script features to be shipped in parallel with the new opcode.
>> >
>> > I found this StackExchange post helpful in thinking through various deployment strategies for new Tapscript-based consensus upgrades.
>> >
>> > >I'd also love to see analysis why stop at 64 bits and not go all the way to 256 which could be useful for cryptography.
>> >
>> > In my view, there’s still a lot of uncertainty about cryptographic features being added to Script. There's increasing discussion around quantum computing, which raises the question of how much numerical precision we may eventually need. I'm not opposed to extending precision further—but if we go beyond 64 bits, why stop at 256? With OP_SUCCESSx, arbitrary precision becomes a real option.
>> >
>> > I chose 64 bits because it covers what’s needed for amount locks. If someone strongly believes that 64 bits isn't enough, I’d welcome a competing BIP and would be happy to review and discuss it with the author.
>> >
>> > >Anyway, pushing amounts on the stack would be great. Though I'm surprised you're only proposing the sum, not individual outputs. Why?
>> >
>> > Good question—and slightly out of scope for this BIP. Script doesn’t support looping, so it’s not straightforward to iterate over and sum all elements unless the transaction structure (i.e., number of inputs or outputs) is known in advance.
>> > You can measure the number of stack elements with OP_DEPTH, but there’s no way to write something like OP_ADD [num-stack-elements-from-OP_DEPTH] to sum them all. I’m definitely open to hearing other approaches, though.
>> >
>> > -Chris
>> >
>> >
>> >
>> > On Mon, May 12, 2025 at 2:32 PM Martin Habovštiak <martin.habovstiak@gmail•com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> the proposal seems to be quite confused about how it's going to do that. It mentions upgrading existing opcodes, which is a hardfork, not soft fork, at least without using a different leaf version. But it also mentions OP_SUCCESSX which are different opcodes. I think it needs some analysis. (leaf version seems better intuitively)
>> >>
>> >> I'd also love to see analysis why stop at 64 bits and not go all the way to 256 which could be useful for cryptography.
>> >>
>> >> Anyway, pushing amounts on the stack would be great. Though I'm surprised you're only proposing the sum, not individual outputs. Why?
>> >>
>> >> Good luck!
>> >>
>> >> Martin
>> >>
>> >> Dňa po 12. 5. 2025, 14:21 Chris Stewart <stewart.chris1234@gmail•com> napísal(a):
>> >>>
>> >>> This soft fork proposal extends the range of numeric operands in Script from -2^31+1 to 2^31-1, to -2^63+1 to 2^63-1. It further expands the result range for arithmetic operations from -2^63 to 2^63-1, to -2^127 to 2^127- 1.
>> >>>
>> >>> All existing opcodes[1] that interpret stack elements as numbers are upgraded to support 64-bit parameters.
>> >>>
>> >>> The existing number encoding format[2] and arithmetic semantics[3] from the original Bitcoin implementation are preserved, while enhancing the supported precision.
>> >>>
>> >>> https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
>> >>>
>> >>> The purpose for this BIP is to lay the groundwork for introducing amounts into Script. This document takes no opinion on how this is done.
>> >>>
>> >>> I've prototyped a few different proposals now introducing amount locks into Script[0][1] and feel like this proposal is stable enough for serious review.
>> >>>
>> >>> -Chris
>> >>>
>> >>> [0] - https://delvingbitcoin.org/t/op-inout-amount/549/4?u=chris_stewart_5
>> >>>
>> >>> [1] - https://delvingbitcoin.org/t/op-inout-amount/549/5?u=chris_stewart_5
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
>> >>> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
>> >>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail.com.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
>> > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALxbBHWP%3DzOfT0%2BYM%3D4MgR6SEuT9CCFHQEuH_mkgtDKiRxpfog%40mail.gmail.com.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-05-14 9:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-05-12 16:15 [bitcoindev] [Proposal] 64-bit arithmetic in Script Chris Stewart
2025-05-12 19:32 ` Martin Habovštiak
2025-05-13 9:03 ` Chris Stewart
2025-05-13 11:44 ` Christian Decker
2025-05-14 8:23 ` Chris Stewart
2025-05-14 8:27 ` Christian Decker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox