path: root/7f/76390e07162d728014ddf817fa3b3da0871b3f

Delivery-date: Wed, 14 May 2025 02:36:53 -0700
Received: from mail-oo1-f61.google.com ([209.85.161.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDML5DFJWQEBBKWISHAQMGQEWHSABHY@googlegroups.com>)
	id 1uF8Xj-0004cb-Ra
	for bitcoindev@gnusha.org; Wed, 14 May 2025 02:36:53 -0700
Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-6021ab9731dsf591520eaf.1
        for <bitcoindev@gnusha.org>; Wed, 14 May 2025 02:36:51 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1747215406; cv=pass;
        d=google.com; s=arc-20240605;
        b=P8Kxemrx6YCjfUULmrK5RLBJSLHgkQ5tQafeoqKp86ezy7SvsocDN8IWzx0bZgsxg3
         4jOi4xzpXZNL/7DMDxeSs9gAsucTJLBwUrEqR5C+v6XgO4dO5590c6zo1Yw9si3azcWx
         uQAxsM72yA/VcGQz3F63HlH42QB+Iv59lQXdCo1kp07nj1huT/9w2Z0UNg041YPURaO4
         aRF1uidaD4emEfLf42F1vFh0cnF1/pvn77MzrDCmEReSx4P82PPo2HLXy1l0REMPPd6B
         FZQB+g2eT6M9nn8EgQp09Rabhczki8/L39Nf6MtCiQFb/uPqvcJG/+b1B3+zm0C7hqdT
         ynvw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=Zx4hvFuqdl2rL3PhJsep7LMEXcy8nwuOKezEErCmp5Q=;
        fh=0slkUmdvi1TMXqkgIk5zwZJpparzy99OGnedvgAT/1U=;
        b=COoZh7VFEWorfPJLHjWAr+q1wL6sEvuHsy2R6NzY0ZxALJoFVAgeYRa0KGhLyrZI9m
         LwKwbbd+XEq4JjXJULbJHk7uEshE4Z8Jmy9YBOQ0GGGPpawFPNch/rLzTgzGOpDcM7fL
         wjU8QQ/07YVFYp5Yb4f/mx7T4cbrrV65c53D7E6IjQf3q4Xr1l8GoD94rStHbxzNgl7+
         z3zM08ok8Gc7gHw7AGgqHdJnmUyz+wBEaAVtI9KnDal9zS4hmGqFO/apLlWe5KGAa4ob
         6p6VJ6P3lsxJkrBAeye7mRnYpx6vu9U+KOPpvdOdVTeRW6FHt910fy1pgB/shBkv4LDB
         tHow==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=keE9S2JP;
       spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::b34 as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1747215406; x=1747820206; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Zx4hvFuqdl2rL3PhJsep7LMEXcy8nwuOKezEErCmp5Q=;
        b=MpBZpSGxMjRf/7ViSBx/VFGnhhJnmtim/7GHQDttBjF8wpEehofwRpWAyA+7rGWgYc
         bLVmwDFvGoj6w0nZGvO6Vf7/zrhlIQHsTyICIxd6duxd+Jq1r431yM/vWdMgxQIinu5J
         VDsIOs3gmnatpNBcOpag8HlsmmKLXWPGf04sUstu88bNnApWtJ6ygNgG3/RuDIz4wHWp
         8S6MwwOAbN6TY8HleCgLQpmjkm7sUu+qTTQJblqkT5InMrnfJNUwzRmDnlClM3BWt5kn
         6qGveXda+y8q6ptKVmNJ3vJxK685qr24U5BfEzhpMwELVvzlt/XemRSEqwzvoMUpBKhN
         kocA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747215406; x=1747820206; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Zx4hvFuqdl2rL3PhJsep7LMEXcy8nwuOKezEErCmp5Q=;
        b=EQ0RVjqJez3Nk7Weto/+QN5s7qSuDJYB1no2B61IqQFlOk1YOM5zTld6IUmapi8YP5
         i208gJGv0qZWBj0COIFfmMStYDvAA80lj181fd99OcMSX/eWQ0EBkLwjvAKV0jeXlzaK
         ox7XvWok2t72DQOTApwlV+749zoMLKBZif8G/PlVsrFmr1KrukROjo0jiIKqSqA3QpT1
         2e7KgFUC+P1g0IaTj2JahVNM5RkNviqN+5CAKE4WVVttoG4Ke+RIK61jdGXDJLYZwjBC
         7w7NPqHnVmClDMe9G94y7pI7HYlccHrT55bHtg7rXp2JkIGTamyWFdKeaO+0LjxF/r1y
         dCiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747215406; x=1747820206;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=Zx4hvFuqdl2rL3PhJsep7LMEXcy8nwuOKezEErCmp5Q=;
        b=dChwX4yd0VzMLbYIytpPf0Xm8qdK5E9DbpsaQ/WC/SB5hHoT6C03YU14SXGx1MHopN
         c87Nurxz5Gr3ULG4nYUCzAavr++D7Y1EXadV2H6m4aM7tMfD75dL8UvFlwDQNCuWR3vx
         akx59LZcNEByPc93ktGrLWo06BzGAKsDS51G1J0uQQncww5/l+qpRtyYVzqSoqda2+aS
         jD9uQjkrupZbe7PVsxzuNsWlcjAhz+5HzwashchbkKYUtAu2EDU3/Rcy04il1dzslXHi
         uVD7ATx3y1MWbs0W4xq5zsLTjYfKqEsCcdJ20Gr1WSDJabHsiLumxB0iXO5VLaJ5fdPU
         jS4A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVIga5vqEhC8FMpK2ixYaE90GCUMogQKASC4jYbaG8hwAK19quh2Ge7FsdLkJO0qJSz5jCf4B77z1kN@gnusha.org
X-Gm-Message-State: AOJu0YzNPerJ4Relhz+cEXk2+x/fLruOlpMsJ47jjfBZfW1nLoXbNRWc
	nwntVbuThaRnZ+/SXl+/zmFJajoy89o0kx/yTWOqxIprl1cMSEMn
X-Google-Smtp-Source: AGHT+IG/LEwKiFWNlBsqBWvna+b30nAHaXVv1gF2bkdFeWeeMbqlZcxqq8XRwWL2Oe6bwD8d/XYX1w==
X-Received: by 2002:a05:6871:2b25:b0:2da:87a2:f223 with SMTP id 586e51a60fabf-2e27a04ed21mr1384524fac.11.1747215405248;
        Wed, 14 May 2025 02:36:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBH0pJNQa+958zBRNVh9H5ud3PawTOzM6gEDjBBLjI+lwg==
Received: by 2002:a05:6871:788a:b0:2d5:17b7:9f8c with SMTP id
 586e51a60fabf-2db804b0b3cls43668fac.1.-pod-prod-00-us; Wed, 14 May 2025
 02:36:41 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCXeWo4AaG8KU77ZyGTQb2ei0KfgIOAp04dZoOoTdVNv1o/BuZVEFsJVCiSeXCbgoez8a0evhcy+z4Ea@googlegroups.com
X-Received: by 2002:a05:6808:338a:b0:3f6:a851:fe85 with SMTP id 5614622812f47-404c20a148fmr1349224b6e.14.1747215401667;
        Wed, 14 May 2025 02:36:41 -0700 (PDT)
Received: by 2002:a05:6808:2d29:b0:3fa:da36:efcd with SMTP id 5614622812f47-403800066d4msb6e;
        Wed, 14 May 2025 01:24:39 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCXNSBOPW9TIsmwRrxVd1bUBuevAuSREfkuMDQuBHjrIMLcvV4nmX+daIB19ejxoOdGzgq2YdCnkMclc@googlegroups.com
X-Received: by 2002:a17:90b:2d48:b0:30a:3e8e:ea30 with SMTP id 98e67ed59e1d1-30e0de3cda3mr9416851a91.11.1747211078605;
        Wed, 14 May 2025 01:24:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1747211078; cv=none;
        d=google.com; s=arc-20240605;
        b=gPz4nd4tcW//DBTJtsoJ/IFY4+bP1yuv9x1NT/ycFgmCTP7q/o5ZedUNmiGambCMAp
         5tzsYXLBFg/XTpzm6AqIEFNMbuZQKnIXYl0+GkTnjPmVGq7ynhFhi/NZlrphv/3WTuhC
         1njyk9dVjjq3wMbR/gz0z0q+TR2pgHrBzkwXSmlEnQEoDB9X5oYku/JsA11uraYd1sYd
         d+H4MIK5sO50bCeU3bKUslIYGZXrGRN6zkKAEvGocpdjHsI0aqoZpEIsxT6b+u2NWHAj
         DISgb5rsTFhADYWqrW9ncyReh+j4ijuEB/J60Hjm3gYLTWYFvP0FAmh38TcXIx5FRIcs
         ASxQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=BqAD6rZkFBc38aaeJTuW43ZX6doPnFhsbd7jrq6jcgY=;
        fh=bN800fnRahCBfPc7D570l6KisXTRdsREQY2UZEdG6fI=;
        b=K4Anf6cHhELXDcFvvWw31aXEpRrO7vHPA4Fcy4KGhhiFX4xInnV0aFQj6MgmLpj+le
         0HIhRNAlfPGzuRFBN/SMz8y3aO/sZUF8jT+K2xUixdnGaaQLGLgCp0YaalBv4RuBQORy
         26OfMM5Ssq7+CemueOWq53xj54H+nQejWTpiI3GyC5aeitExeD7K9D1+nqTJzy1h/8BO
         VWPGKd8oFd6RFURJqqcQsfJwg7nKqMycG4oSxA+L+y6796RjH1dat/3ws/Hj9f+9UHaS
         aYtuHngSia6TytVdMmUAQ1glK5jDjONizc/Dbc8ZV7sj7jfGwYsZ8YZQroI3wHrxYJnf
         YD2w==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=keE9S2JP;
       spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::b34 as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com. [2607:f8b0:4864:20::b34])
        by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-30e11e4446fsi157145a91.1.2025.05.14.01.24.38
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 14 May 2025 01:24:38 -0700 (PDT)
Received-SPF: pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::b34 as permitted sender) client-ip=2607:f8b0:4864:20::b34;
Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-e73e9e18556so653533276.0
        for <bitcoindev@googlegroups.com>; Wed, 14 May 2025 01:24:38 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCW1A/c3OdqNyVbh/E+tHTlK1+dWmCS5eFRWRixeDeLQcBEswz1cN7gImPNj8hcFKfeDR5/Mav4Xijp8@googlegroups.com
X-Gm-Gg: ASbGncuOYn3RZKVjOi1tDnrA3PxE/MAHKxqTPSzM/KDtEfkmunCJlNfddYR/N5tsQbh
	EW+Nc7j6YT//j3oq0Q/iHOxXsLd1AFJYgu0N1dA8F8pnLq4TRZyAO1uop/k2Bzny0eoDZwUG5LV
	y6LuBARsYc8RZo70oW+3esdfGrP5FkDjM=
X-Received: by 2002:a05:6902:100d:b0:e73:40bb:3304 with SMTP id
 3f1490d57ef6-e7b3c8c47cdmr3284448276.1.1747211077308; Wed, 14 May 2025
 01:24:37 -0700 (PDT)
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>
In-Reply-To: <CALxbBHW8YD-F2N9PYcAii5wXfEAPratQ6i6ke-i59pdoFczSoA@mail.gmail.com>
From: Chris Stewart <stewart.chris1234@gmail.com>
Date: Wed, 14 May 2025 03:23:00 -0500
X-Gm-Features: AX0GCFvL6U0h-3nyj93nZ_zAyQGQgr-WRezYd4pY1rYP9xC88aCKhCKPPwsRfEI
Message-ID: <CAGL6+mFF8noQxXWy8PXBT9vSBQv0Hx3jn7cFtQMkv4PcnhyGyw@mail.gmail.com>
Subject: Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script
To: Christian Decker <decker.christian@gmail.com>
Cc: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000009c58a306351447fa"
X-Original-Sender: stewart.chris1234@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=keE9S2JP;       spf=pass
 (google.com: domain of stewart.chris1234@gmail.com designates
 2607:f8b0:4864:20::b34 as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--0000000000009c58a306351447fa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Christian,

Thank you for the interest in this proposal!

I=E2=80=99d 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=
=E2=80=99m
aware of is Rusty=E2=80=99s 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 =E2=80=94 =
such as
additional posts, WIP BIPs, or code =E2=80=94 that we could review or exper=
iment
with? Even 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 iso=
lating 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=E2=80=99t be achievable with 64-b=
it
arithmetic. Looking at the Elements project, there are a couple of examples
=E2=80=94 ECMULSCALARVERIFY
<https://github.com/ElementsProject/elements/blob/7ed597f4a5f713e33aac04c87=
c1a9da5ecd7d52c/src/script/interpreter.cpp#L2193>
and TWEAKVERIFY
<https://github.com/ElementsProject/elements/blob/7ed597f4a5f713e33aac04c87=
c1a9da5ecd7d52c/src/script/interpreter.cpp#L2219>
=E2=80=94 which operate on 256-bit stack arguments. Notably, these opcodes =
don=E2=80=99t
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=E2=80=AFAM 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=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 mentio=
ns
> 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=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 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=E2=80=99s still a lot of uncertainty about cryptograp=
hic
> 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=E2=80=94but if we go beyond 64 bits, why stop at 256? With OP_SUC=
CESSx,
> arbitrary precision becomes a real option.
> >
> > I chose 64 bits because it covers what=E2=80=99s needed for amount lock=
s. If
> someone strongly believes that 64 bits isn't enough, I=E2=80=99d 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=E2=80=94and slightly out of scope for this BIP. Script do=
esn=E2=80=99t
> support looping, so it=E2=80=99s 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=
=E2=80=99s
> no way to write something like OP_ADD [num-stack-elements-from-OP_DEPTH] =
to
> sum them all. I=E2=80=99m definitely open to hearing other approaches, th=
ough.
> >
> > -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
> that. It mentions upgrading existing opcodes, which is a hardfork, not so=
ft
> fork, at least without using a different leaf version. But it also mentio=
ns
> 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=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
> Script from -2^31+1 to 2^31-1, to -2^63+1 to 2^63-1. It further expands t=
he
> 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 t=
he
> supported precision.
> >>>
> >>>
> https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.me=
diawiki
> >>>
> >>> 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 lock=
s
> into Script[0][1] and feel like this proposal is stable enough for seriou=
s
> review.
> >>>
> >>> -Chris
> >>>
> >>> [0] -
> https://delvingbitcoin.org/t/op-inout-amount/549/4?u=3Dchris_stewart_5
> >>>
> >>> [1] -
> https://delvingbitcoin.org/t/op-inout-amount/549/5?u=3Dchris_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, sen=
d
> an email to bitcoindev+unsubscribe@googlegroups.com.
> >>> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZR=
oTpHasX7xoprYeJZRd5D80J1GqA%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%2Bkn6SU9pf0Rz3Fm=
M5OfcsmEtqGBRJ7Upb-b0MofS5A%40mail.gmail.com
> .
>

--=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/=
CAGL6%2BmFF8noQxXWy8PXBT9vSBQv0Hx3jn7cFtQMkv4PcnhyGyw%40mail.gmail.com.

--0000000000009c58a306351447fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Christian,</div><div><br></div><div>Thank you for =
the interest in this proposal!<div><p class=3D"gmail-">I=E2=80=99d like to =
invite you, Rusty, or any other contributors to provide an update to the li=
st on the status of GSR. The most recent public writing I=E2=80=99m aware o=
f is <a href=3D"https://rusty.ozlabs.org/2024/01/19/the-great-opcode-restor=
ation.html">Rusty=E2=80=99s blog post</a>, which is now around 18 months ol=
d. Are there any newer materials =E2=80=94 such as additional posts, WIP BI=
Ps, or code =E2=80=94 that we could review or experiment with? Even rough d=
rafts would be helpful for prototyping and discussion.</p>
<p class=3D"gmail-">I=E2=80=99m not opposed to the broader goals of GSR, bu=
t 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 request=
ed feature: 64-bit precision to enable amount locks.</p></div><div>&gt;arbi=
trary sized integers</div><div><br></div><div>It would be helpful to see so=
me concrete examples of opcodes that would <em>require</em> arbitrary preci=
sion, 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 <a href=3D"=
https://github.com/ElementsProject/elements/blob/7ed597f4a5f713e33aac04c87c=
1a9da5ecd7d52c/src/script/interpreter.cpp#L2193"><code>ECMULSCALARVERIFY</c=
ode></a> and <a href=3D"https://github.com/ElementsProject/elements/blob/7e=
d597f4a5f713e33aac04c87c1a9da5ecd7d52c/src/script/interpreter.cpp#L2219"><c=
ode>TWEAKVERIFY</code></a> =E2=80=94 which operate on 256-bit stack argumen=
ts. Notably, these opcodes don=E2=80=99t support composition with existing =
arithmetic opcodes like <code>OP_ADD</code> or <code>OP_SUB</code>; they si=
mply verify cryptographic conditions. I would argue they do not actually re=
quire supporting more precision in Script as the stack arguments aren&#39;t=
 parsed into CScriptNum.</div><div><br></div><div>It could be useful to hav=
e 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.</div><div><br></div><div>&gt;maybe you could join that effort fo=
r your use-cases too?</div><div><br></div><div>Where can one go to join the=
=20
effort?</div><div><br></div><div>-Chris</div><br></div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Tue, May 13, 2025 at 6:45=E2=80=AFAM Christian Decker &lt;<a href=3D"m=
ailto:decker.christian@gmail.com">decker.christian@gmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
quite an interesting proposal, but much like Martin I wonder if we<br>
shouldn&#39;t go beyond. For comparison Rusty&#39;s GSR comprises arbitrary=
<br>
sized integers and their associated operations, with fine-grained<br>
accounting of operations based on the operands size, so scripts stay<br>
performant and manageable.<br>
<br>
That proposal is much further along in both design and analysis, so<br>
maybe you could join that effort for your use-cases too?<br>
<br>
Cheers,<br>
Christian<br>
<br>
On Tue, May 13, 2025 at 11:06=E2=80=AFAM Chris Stewart<br>
&lt;<a href=3D"mailto:stewart.chris1234@gmail.com" target=3D"_blank">stewar=
t.chris1234@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi Martin<br>
&gt;<br>
&gt; Thanks for your interest in the topic.<br>
&gt;<br>
&gt; &gt;It mentions upgrading existing opcodes, which is a hardfork, not s=
oft fork, at least without using a different leaf version. But it also ment=
ions OP_SUCCESSX which are different opcodes<br>
&gt;<br>
&gt; 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<br>
&gt;<br>
&gt; &gt;This proposal could be deployed in conjunction with any of the new=
 opcode proposals in the Motivation section using Tapscript&#39;s OP_SUCCES=
Sx semantics.[18]<br>
&gt;<br>
&gt; The opcodes mentioned in the motivation section are OP_{IN,OUT}_AMOUNT=
, OP_VAULT, OP_CHECKCONTRACTVERIFY, OP_CTV<br>
&gt;<br>
&gt; 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&#39;s (OP_ADD,OP_SUB, etc) sema=
ntics.<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt; I found this StackExchange post helpful in thinking through various de=
ployment strategies for new Tapscript-based consensus upgrades.<br>
&gt;<br>
&gt; &gt;I&#39;d also love to see analysis why stop at 64 bits and not go a=
ll the way to 256 which could be useful for cryptography.<br>
&gt;<br>
&gt; In my view, there=E2=80=99s still a lot of uncertainty about cryptogra=
phic features being added to Script. There&#39;s increasing discussion arou=
nd quantum computing, which raises the question of how much numerical preci=
sion we may eventually need. I&#39;m not opposed to extending precision fur=
ther=E2=80=94but if we go beyond 64 bits, why stop at 256? With OP_SUCCESSx=
, arbitrary precision becomes a real option.<br>
&gt;<br>
&gt; I chose 64 bits because it covers what=E2=80=99s needed for amount loc=
ks. If someone strongly believes that 64 bits isn&#39;t enough, I=E2=80=99d=
 welcome a competing BIP and would be happy to review and discuss it with t=
he author.<br>
&gt;<br>
&gt; &gt;Anyway, pushing amounts on the stack would be great. Though I&#39;=
m surprised you&#39;re only proposing the sum, not individual outputs. Why?=
<br>
&gt;<br>
&gt; 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.<br>
&gt; 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.<br>
&gt;<br>
&gt; -Chris<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, May 12, 2025 at 2:32=E2=80=AFPM Martin Habov=C5=A1tiak &lt;<a =
href=3D"mailto:martin.habovstiak@gmail.com" target=3D"_blank">martin.habovs=
tiak@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; the proposal seems to be quite confused about how it&#39;s going t=
o 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 me=
ntions OP_SUCCESSX which are different opcodes. I think it needs some analy=
sis. (leaf version seems better intuitively)<br>
&gt;&gt;<br>
&gt;&gt; I&#39;d also love to see analysis why stop at 64 bits and not go a=
ll the way to 256 which could be useful for cryptography.<br>
&gt;&gt;<br>
&gt;&gt; Anyway, pushing amounts on the stack would be great. Though I&#39;=
m surprised you&#39;re only proposing the sum, not individual outputs. Why?=
<br>
&gt;&gt;<br>
&gt;&gt; Good luck!<br>
&gt;&gt;<br>
&gt;&gt; Martin<br>
&gt;&gt;<br>
&gt;&gt; D=C5=88a po 12. 5. 2025, 14:21 Chris Stewart &lt;<a href=3D"mailto=
:stewart.chris1234@gmail.com" target=3D"_blank">stewart.chris1234@gmail.com=
</a>&gt; nap=C3=ADsal(a):<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; All existing opcodes[1] that interpret stack elements as numbe=
rs are upgraded to support 64-bit parameters.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The existing number encoding format[2] and arithmetic semantic=
s[3] from the original Bitcoin implementation are preserved, while enhancin=
g the supported precision.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; <a href=3D"https://github.com/Christewart/bips/blob/2025-03-17=
-64bit-pt2/bip-XXXX.mediawiki" rel=3D"noreferrer" target=3D"_blank">https:/=
/github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki</=
a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The purpose for this BIP is to lay the groundwork for introduc=
ing amounts into Script. This document takes no opinion on how this is done=
.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I&#39;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.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -Chris<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [0] - <a href=3D"https://delvingbitcoin.org/t/op-inout-amount/=
549/4?u=3Dchris_stewart_5" rel=3D"noreferrer" target=3D"_blank">https://del=
vingbitcoin.org/t/op-inout-amount/549/4?u=3Dchris_stewart_5</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [1] - <a href=3D"https://delvingbitcoin.org/t/op-inout-amount/=
549/5?u=3Dchris_stewart_5" rel=3D"noreferrer" target=3D"_blank">https://del=
vingbitcoin.org/t/op-inout-amount/549/5?u=3Dchris_stewart_5</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt;&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an email to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroup=
s.com" target=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
&gt;&gt;&gt; To view this discussion visit <a href=3D"https://groups.google=
.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J=
1GqA%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.=
google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZR=
d5D80J1GqA%40mail.gmail.com</a>.<br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" t=
arget=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
&gt; To view this discussion visit <a href=3D"https://groups.google.com/d/m=
sgid/bitcoindev/CAGL6%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A%40m=
ail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.c=
om/d/msgid/bitcoindev/CAGL6%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS=
5A%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAGL6%2BmFF8noQxXWy8PXBT9vSBQv0Hx3jn7cFtQMkv4PcnhyGyw%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAGL6%2BmFF8noQxXWy8PXBT9vSBQv0Hx3jn7cFtQMkv4PcnhyGyw%40ma=
il.gmail.com</a>.<br />

--0000000000009c58a306351447fa--