From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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: In-Reply-To: From: Chris Stewart Date: Wed, 14 May 2025 03:23:00 -0500 X-Gm-Features: AX0GCFvL6U0h-3nyj93nZ_zAyQGQgr-WRezYd4pY1rYP9xC88aCKhCKPPwsRfEI Message-ID: Subject: Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script To: Christian Decker Cc: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= , Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 , 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 and TWEAKVERIFY =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 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 > 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 > 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
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 li= st on the status of GSR. The most recent public writing I=E2=80=99m aware o= f is Rusty=E2=80=99s blog post, 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.

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.

>arbi= trary sized integers

It would be helpful to see so= me concrete examples of opcodes that would require 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 ECMULSCALARVERIFY and TWEAKVERIFY =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 OP_ADD or OP_SUB; 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.

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.

>maybe you could join that effort fo= r your use-cases too?

Where can one go to join the= =20 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
<stewar= t.chris1234@gmail.com> wrote:
>
> Hi Martin
>
> Thanks for your interest in the topic.
>
> >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
>
> I view 64-bit arithmetic as a feature of a wider set of consensus chan= ges. Here is what I think the most likely deployment story is
>
> >This proposal could be deployed in conjunction with any of the new= opcode proposals in the Motivation section using Tapscript's OP_SUCCES= Sx 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 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.
>
> There=E2=80=99s been some discussion around deploying OP_CTV via a NOP= opcode instead of OP_SUCCESSx. I think that would be a poor choice, as it = wouldn=E2=80=99t allow new Script features to be shipped in parallel with t= he new opcode.
>
> I found this StackExchange post helpful in thinking through various de= ployment strategies for new Tapscript-based consensus upgrades.
>
> >I'd also love to see analysis why stop at 64 bits and not go a= ll the way to 256 which could be useful for cryptography.
>
> In my view, there=E2=80=99s still a lot of uncertainty about cryptogra= phic features being added to Script. There's increasing discussion 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.
>
> 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.
>
> >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 d= oesn=E2=80=99t support looping, so it=E2=80=99s not straightforward to iter= ate over and sum all elements unless the transaction structure (i.e., numbe= r of inputs or outputs) is known in advance.
> You can measure the number of stack elements with OP_DEPTH, but there= =E2=80=99s no way to write something like OP_ADD [num-stack-elements-from-O= P_DEPTH] to sum them all. I=E2=80=99m definitely open to hearing other appr= oaches, though.
>
> -Chris
>
>
>
> On Mon, May 12, 2025 at 2:32=E2=80=AFPM Martin Habov=C5=A1tiak <martin.habovs= tiak@gmail.com> wrote:
>>
>> Hi,
>>
>> 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)
>>
>> 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.
>>
>> 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 = the result range for arithmetic operations from -2^63 to 2^63-1, to -2^127 = to 2^127- 1.
>>>
>>> All existing opcodes[1] that interpret stack elements as numbe= rs are upgraded to support 64-bit parameters.
>>>
>>> The existing number encoding format[2] and arithmetic semantic= s[3] from the original Bitcoin implementation are preserved, while enhancin= g the supported precision.
>>>
>>> https:/= /github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
>>>
>>> The purpose for this BIP is to lay the groundwork for introduc= ing amounts into Script. This document takes no opinion on how this is done= .
>>>
>>> I've prototyped a few different proposals now introducing = amount locks into Script[0][1] and feel like this proposal is stable enough= for serious review.
>>>
>>> -Chris
>>>
>>> [0] - https://del= vingbitcoin.org/t/op-inout-amount/549/4?u=3Dchris_stewart_5
>>>
>>> [1] - https://del= vingbitcoin.org/t/op-inout-amount/549/5?u=3Dchris_stewart_5
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Go= ogle Groups "Bitcoin Development Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from = it, send an email to bitcoindev+unsubscribe@googlegroups.com.
>>> To view this discussion visit https://groups.= google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZRoTpHasX7xoprYeJZR= d5D80J1GqA%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send= an email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.c= om/d/msgid/bitcoindev/CAGL6%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS= 5A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CAGL6%2BmFF8noQxXWy8PXBT9vSBQv0Hx3jn7cFtQMkv4PcnhyGyw%40ma= il.gmail.com.
--0000000000009c58a306351447fa--