diff options
author | Chris Stewart <stewart.chris1234@gmail.com> | 2025-05-14 03:23:00 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-05-14 02:36:53 -0700 |
commit | 3d7f83394ec7d5ee0305db01038e6e02b00c2e7a (patch) | |
tree | a15ac464eddb791069437b113409eb64313591d6 | |
parent | 97beee8522ab7c1cd979cb98828fd06342bb81f9 (diff) | |
download | pi-bitcoindev-3d7f83394ec7d5ee0305db01038e6e02b00c2e7a.tar.gz pi-bitcoindev-3d7f83394ec7d5ee0305db01038e6e02b00c2e7a.zip |
Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script
-rw-r--r-- | 7f/76390e07162d728014ddf817fa3b3da0871b3f | 640 |
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>>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'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>>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 <<a href=3D"m= +ailto:decker.christian@gmail.com">decker.christian@gmail.com</a>> 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't go beyond. For comparison Rusty'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> +<<a href=3D"mailto:stewart.chris1234@gmail.com" target=3D"_blank">stewar= +t.chris1234@gmail.com</a>> wrote:<br> +><br> +> Hi Martin<br> +><br> +> Thanks for your interest in the topic.<br> +><br> +> >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> +><br> +> 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> +><br> +> >This proposal could be deployed in conjunction with any of the new= + opcode proposals in the Motivation section using Tapscript's OP_SUCCES= +Sx semantics.[18]<br> +><br> +> The opcodes mentioned in the motivation section are OP_{IN,OUT}_AMOUNT= +, OP_VAULT, OP_CHECKCONTRACTVERIFY, OP_CTV<br> +><br> +> 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) sema= +ntics.<br> +><br> +> 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> +><br> +> I found this StackExchange post helpful in thinking through various de= +ployment strategies for new Tapscript-based consensus upgrades.<br> +><br> +> >I'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> +><br> +> In my view, there=E2=80=99s still a lot of uncertainty about cryptogra= +phic features being added to Script. There's increasing discussion arou= +nd quantum computing, which raises the question of how much numerical preci= +sion we may eventually need. I'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> +><br> +> 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= + welcome a competing BIP and would be happy to review and discuss it with t= +he author.<br> +><br> +> >Anyway, pushing amounts on the stack would be great. Though I'= +m surprised you're only proposing the sum, not individual outputs. Why?= +<br> +><br> +> 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> +> 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> +><br> +> -Chris<br> +><br> +><br> +><br> +> On Mon, May 12, 2025 at 2:32=E2=80=AFPM Martin Habov=C5=A1tiak <<a = +href=3D"mailto:martin.habovstiak@gmail.com" target=3D"_blank">martin.habovs= +tiak@gmail.com</a>> wrote:<br> +>><br> +>> Hi,<br> +>><br> +>> the proposal seems to be quite confused about how it'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> +>><br> +>> I'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> +>><br> +>> Anyway, pushing amounts on the stack would be great. Though I'= +m surprised you're only proposing the sum, not individual outputs. Why?= +<br> +>><br> +>> Good luck!<br> +>><br> +>> Martin<br> +>><br> +>> D=C5=88a po 12. 5. 2025, 14:21 Chris Stewart <<a href=3D"mailto= +:stewart.chris1234@gmail.com" target=3D"_blank">stewart.chris1234@gmail.com= +</a>> nap=C3=ADsal(a):<br> +>>><br> +>>> 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> +>>><br> +>>> All existing opcodes[1] that interpret stack elements as numbe= +rs are upgraded to support 64-bit parameters.<br> +>>><br> +>>> 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> +>>><br> +>>> <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> +>>><br> +>>> 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> +>>><br> +>>> 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.<br> +>>><br> +>>> -Chris<br> +>>><br> +>>> [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> +>>><br> +>>> [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> +>>><br> +>>><br> +>>><br> +>>> --<br> +>>> You received this message because you are subscribed to the Go= +ogle Groups "Bitcoin Development Mailing List" group.<br> +>>> 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> +>>> 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> +><br> +> --<br> +> You received this message because you are subscribed to the Google Gro= +ups "Bitcoin Development Mailing List" group.<br> +> 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> +> 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" 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-- + |