summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChris Stewart <stewart.chris1234@gmail.com>2025-05-14 03:23:00 -0500
committerbitcoindev <bitcoindev@googlegroups.com>2025-05-14 02:36:53 -0700
commit3d7f83394ec7d5ee0305db01038e6e02b00c2e7a (patch)
treea15ac464eddb791069437b113409eb64313591d6
parent97beee8522ab7c1cd979cb98828fd06342bb81f9 (diff)
downloadpi-bitcoindev-3d7f83394ec7d5ee0305db01038e6e02b00c2e7a.tar.gz
pi-bitcoindev-3d7f83394ec7d5ee0305db01038e6e02b00c2e7a.zip
Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script
-rw-r--r--7f/76390e07162d728014ddf817fa3b3da0871b3f640
1 files changed, 640 insertions, 0 deletions
diff --git a/7f/76390e07162d728014ddf817fa3b3da0871b3f b/7f/76390e07162d728014ddf817fa3b3da0871b3f
new file mode 100644
index 000000000..ab488d614
--- /dev/null
+++ b/7f/76390e07162d728014ddf817fa3b3da0871b3f
@@ -0,0 +1,640 @@
+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--
+