Delivery-date: Wed, 14 May 2025 02:37:29 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of decker.christian@gmail.com designates 2607:f8b0:4864:20::12b as permitted sender) client-ip=2607:f8b0:4864:20::12b;
MIME-Version: 1.0
References: <CAGL6+mH+9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA@mail.gmail.com>
 <CALkkCJbeAYA2X8jv8iWthKBB8GqxA49DCFm+UMnhmXYpexTNtw@mail.gmail.com>
 <CAGL6+mHv+kn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A@mail.gmail.com>
 <CALxbBHW8YD-F2N9PYcAii5wXfEAPratQ6i6ke-i59pdoFczSoA@mail.gmail.com> <CAGL6+mFF8noQxXWy8PXBT9vSBQv0Hx3jn7cFtQMkv4PcnhyGyw@mail.gmail.com>
In-Reply-To: <CAGL6+mFF8noQxXWy8PXBT9vSBQv0Hx3jn7cFtQMkv4PcnhyGyw@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 14 May 2025 10:27:54 +0200
Message-ID: <CALxbBHWP=zOfT0+YM=4MgR6SEuT9CCFHQEuH_mkgtDKiRxpfog@mail.gmail.com>
Subject: Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script
To: Chris Stewart <stewart.chris1234@gmail.com>
Cc: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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=E2=80=AFAM Chris Stewart
<stewart.chris1234@gmail.com> wrote:
>
> Hi Christian,
>
> Thank you for the interest in this proposal!
>
> I=E2=80=99d like to invite you, Rusty, or any other contributors to provi=
de an update to the list on the status of GSR. The most recent public writi=
ng I=E2=80=99m aware of is Rusty=E2=80=99s blog post, which is now around 1=
8 months old. Are there any newer materials =E2=80=94 such as additional po=
sts, WIP BIPs, or code =E2=80=94 that we could review or experiment with? E=
ven rough drafts would be helpful for prototyping and discussion.
>
> I=E2=80=99m not opposed to the broader goals of GSR, but I do think it=E2=
=80=99s a bit ambitious. That=E2=80=99s partly why I=E2=80=99ve focused my =
efforts on isolating what I believe is the most requested feature: 64-bit p=
recision to enable amount locks.
>
> >arbitrary sized integers
>
> It would be helpful to see some concrete examples of opcodes that would r=
equire arbitrary precision, but wouldn=E2=80=99t be achievable with 64-bit =
arithmetic. Looking at the Elements project, there are a couple of examples=
 =E2=80=94 ECMULSCALARVERIFY and TWEAKVERIFY =E2=80=94 which operate on 256=
-bit stack arguments. Notably, these opcodes don=E2=80=99t support composit=
ion with existing arithmetic opcodes like OP_ADD or OP_SUB; they simply ver=
ify cryptographic conditions. I would argue they do not actually require su=
pporting 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 b=
e enabled in a single place to give other protocol developers an idea of wh=
at 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=E2=80=AFAM Christian Decker <decker.christia=
n@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=E2=80=AFAM 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 mention=
s OP_SUCCESSX which are different opcodes
>> >
>> > I view 64-bit arithmetic as a feature of a wider set of consensus chan=
ges. Here is what I think the most likely deployment story is
>> >
>> > >This proposal could be deployed in conjunction with any of the new op=
code proposals in the Motivation section using Tapscript's OP_SUCCESSx sema=
ntics.[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 con=
junction with OP_CCV. OP_CCV would take advantage of the OP_SUCCESSx semant=
ics allowing us to redefine existing opcode's (OP_ADD,OP_SUB, etc) semantic=
s.
>> >
>> > There=E2=80=99s 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=E2=80=99t allow new Script features to be shipped in parallel with t=
he new opcode.
>> >
>> > I found this StackExchange post helpful in thinking through various de=
ployment 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=E2=80=99s still a lot of uncertainty about cryptogra=
phic features being added to Script. There's increasing discussion around q=
uantum computing, which raises the question of how much numerical precision=
 we may eventually need. I'm not opposed to extending precision further=E2=
=80=94but if we go beyond 64 bits, why stop at 256? With OP_SUCCESSx, arbit=
rary precision becomes a real option.
>> >
>> > I chose 64 bits because it covers what=E2=80=99s needed for amount loc=
ks. If someone strongly believes that 64 bits isn't enough, I=E2=80=99d wel=
come a competing BIP and would be happy to review and discuss it with the a=
uthor.
>> >
>> > >Anyway, pushing amounts on the stack would be great. Though I'm surpr=
ised you're only proposing the sum, not individual outputs. Why?
>> >
>> > Good question=E2=80=94and slightly out of scope for this BIP. Script d=
oesn=E2=80=99t support looping, so it=E2=80=99s not straightforward to iter=
ate over and sum all elements unless the transaction structure (i.e., numbe=
r of inputs or outputs) is known in advance.
>> > You can measure the number of stack elements with OP_DEPTH, but there=
=E2=80=99s no way to write something like OP_ADD [num-stack-elements-from-O=
P_DEPTH] to sum them all. I=E2=80=99m definitely open to hearing other appr=
oaches, though.
>> >
>> > -Chris
>> >
>> >
>> >
>> > On Mon, May 12, 2025 at 2:32=E2=80=AFPM Martin Habov=C5=A1tiak <martin=
.habovstiak@gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> the proposal seems to be quite confused about how it's going to do th=
at. It mentions upgrading existing opcodes, which is a hardfork, not soft f=
ork, at least without using a different leaf version. But it also mentions =
OP_SUCCESSX which are different opcodes. I think it needs some analysis. (l=
eaf 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 surpr=
ised you're only proposing the sum, not individual outputs. Why?
>> >>
>> >> Good luck!
>> >>
>> >> Martin
>> >>
>> >> D=C5=88a po 12. 5. 2025, 14:21 Chris Stewart <stewart.chris1234@gmail=
.com> nap=C3=ADsal(a):
>> >>>
>> >>> This soft fork proposal extends the range of numeric operands in Scr=
ipt from -2^31+1 to 2^31-1, to -2^63+1 to 2^63-1. It further expands the re=
sult range for arithmetic operations from -2^63 to 2^63-1, to -2^127 to 2^1=
27- 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] f=
rom the original Bitcoin implementation are preserved, while enhancing the =
supported precision.
>> >>>
>> >>> https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XX=
XX.mediawiki
>> >>>
>> >>> The purpose for this BIP is to lay the groundwork for introducing am=
ounts into Script. This document takes no opinion on how this is done.
>> >>>
>> >>> I've prototyped a few different proposals now introducing amount loc=
ks into Script[0][1] and feel like this proposal is stable enough for serio=
us review.
>> >>>
>> >>> -Chris
>> >>>
>> >>> [0] - https://delvingbitcoin.org/t/op-inout-amount/549/4?u=3Dchris_s=
tewart_5
>> >>>
>> >>> [1] - https://delvingbitcoin.org/t/op-inout-amount/549/5?u=3Dchris_s=
tewart_5
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google G=
roups "Bitcoin Development Mailing List" group.
>> >>> To unsubscribe from this group and stop receiving emails from it, se=
nd an email to bitcoindev+unsubscribe@googlegroups.com.
>> >>> To view this discussion visit https://groups.google.com/d/msgid/bitc=
oindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%40mail.gmail=
.com.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Gro=
ups "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/bitcoi=
ndev/CAGL6%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A%40mail.gmail.c=
om.

--=20
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 e=
mail 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.