From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 13 May 2025 02:06:27 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uElak-0003p3-0A for bitcoindev@gnusha.org; Tue, 13 May 2025 02:06:27 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6044db45c83sf4136196eaf.1 for ; Tue, 13 May 2025 02:06:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1747127179; cv=pass; d=google.com; s=arc-20240605; b=ZeBSW0nVR+/lLl8MOyKIY5wVrBqwvBJdiadOWPwSlOGbv3M+I6QqaEDMHR00c4OdYf Z3m1m1S4LZXKjXO9VB2XL8BOID95ZuIXJiO5/q/kodoHnIs0firNjyjtQFDpTZ7db3wj wTnBdv4UQ82EaA3Qc1TsuZWESpRSlFnIWQoys+PFUGwTpG+S5Fo2KBTkh1PL5NHun56q 6D9S7SWpfzMNBXXd1kEdpk3cTuTxU/Vw7ej/p68ep2YoLlx9xn0sH3zbk+GtJxCRKIEX DY50kSBbWJNyb9ypWZ1PFxN0dhfbUnpxxqCbBzjHnD1c16VxZU50MYpGk2itmovkuYCM ghCw== 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=89n8gLPOB99VlwjlCyHbzL4P1fagX/2UtIc2wVW0Jbw=; fh=3bI5ifkk+xFT2u474ySxpeZB/HnFx/SBxl0wmAFADeQ=; b=TuMzJzYlU0R/nLnPlViarF8/wsQAOUt4dn9UFLHPORYsyk13RChjYLkkrMzKk26oqV MURchQklKxno1pF9PSQ+RFUTcrxxFHkfTG1hs1LPDlHsKAJ0fg1bjWIkXtCfMmgV/O6w Ayq+A+XiOlhaIhylPL1GG3YcBA0zbocNVTCGc2vYtghS0QryT+y/j24BDqDkDoFQblYU WRW5C2UqONMoQn+cgzWPAemM4mOqKalPMeI1w1errt3ypoYwK/aCJg7mKRR5HlA/aVIb 6GnTjuYVS+7fhUkSCdlndL74PLu6znvnk7laGk+c4Hit85k33tAMV266RaLGYudGZbIK oWQg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=XUwYpwdQ; spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::112f 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=1747127179; x=1747731979; 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=89n8gLPOB99VlwjlCyHbzL4P1fagX/2UtIc2wVW0Jbw=; b=lT1rMMTGKpGu5VV3q4Zcr48Zfb3T2RLDxszR0w/T2I3vQszb9eXQGGuoG/vrv8eN2D u4gEY/Xc3SccCKQsSQWP82jcmUr/5NhdzZyPn13l5oEUGlbjzQUNWMgomhEpDnSqk+f2 VpltIh/wrwz+7hGhTL8++orhN//ZQjpUmbgWkbmUpZhzQGZC2g1Q0ZzYd8/8YI7uQ/U5 RkWNXbFPOdd9mTF6dcie7oxejg8GOSCydK9d14/tailAFDgJXvScSvMzh5ofS2bHoVH1 Ld4wgyk9SgCOxIzPnwvpBnQEON9/LExLMLtM2zN+uwwXZTx7tjSFSfbUEeI7tAtr07Uk crSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747127179; x=1747731979; 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=89n8gLPOB99VlwjlCyHbzL4P1fagX/2UtIc2wVW0Jbw=; b=PiY2Jn1WPAoBD6rcvGXWXVV16aXV3542J/FfGFUDAUumZGQSydEn/ulVhatgOAWErF mYSfiDnYMWeO25S7ew05p+ptpvxjCTYvW+GQDU52XjRZLS55Tw1riXK8UQGX0G+fmwsw McpIfoQhsV7MX3XQQvGhsVSNk84EHBHvlROHLUDZFjhz32afaIq6zAgqA+okTRmaTe1S P835/HwZi6jE/7QsfJETmw2EN352fpLgo9tTurYcg4YVuN/Ot1Ddil+XvqXYlU2Nu8ms mVCBG1O0nMRvvC3/DvgLhPX0p+a5fbYtw83Hqp19HzKxCmhTw1uO2bQ7X0FqBH6+6Bso MtUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747127179; x=1747731979; 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=89n8gLPOB99VlwjlCyHbzL4P1fagX/2UtIc2wVW0Jbw=; b=L5Z4zoQ4tHo/CB9umBbYDTLGnUtsgeDSA+kTX9XnpNv0U8NvDFFazuqU4IkwMrRL/P EXztonLBE0Wr6WKED3Z2oW615H71WHDSZ4bCPrGj5ng8mUvH7CYgJLQGARCdIvWd2hCf S+xkzO/GmqUoqJfT9A/ApLLDBs3e/swfjbrnanN0IfHt1XQUiVoodh32jtMlGXz7eY5p 8FNLfF8/6Q45Lk/81saHNpccnDCKW8Up0gtGK/8CZDK7UC6FnM7LZHLtlMSSDFEjyMyU r3mrPGdNyo2TJ3+338z4864WeMwGxM0a+Cl3hw4+bBGjWsmn9/nk7Hq/1d+C/Ga1xf3i g+tA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXqFxSrK3VLboeCHDXIXV+gwRygIQgiQkra1huQabP4rzEX15u1JnRNBidiz0iM4o4UTwDQrNyFdpfz@gnusha.org X-Gm-Message-State: AOJu0Yz/tmhq706DrXcdKGEFGOfDoz+KFCRngzg2QU811Y8XAOsAyYdZ B6uLbFZ/DzAfmz9cKuGApHXq/h6CMMcM6s6ets9CLzpIEVca2Waw X-Google-Smtp-Source: AGHT+IFv27cn6f7GhGzfPFi9SMrnCY7MaEULxWFppzjgFAUcLX7cFkz3OJ99Kx661fomX3f8Pw4haQ== X-Received: by 2002:a05:6871:741a:b0:2c8:340d:1076 with SMTP id 586e51a60fabf-2dba455318cmr9127407fac.32.1747127179232; Tue, 13 May 2025 02:06:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBH50fCWOydnxsh2HxHJ+dwGRz21+d8W4gwoBlK/+A8rUw== Received: by 2002:a05:6871:3a8e:b0:2ab:4267:cb7c with SMTP id 586e51a60fabf-2db810296b1ls346991fac.1.-pod-prod-07-us; Tue, 13 May 2025 02:06:15 -0700 (PDT) X-Received: by 2002:a05:6808:2f06:b0:404:78f9:711c with SMTP id 5614622812f47-40478f97214mr8072374b6e.19.1747127175676; Tue, 13 May 2025 02:06:15 -0700 (PDT) Received: by 2002:a05:6808:13d0:b0:3f6:a384:eb6f with SMTP id 5614622812f47-4037feaf8bdmsb6e; Tue, 13 May 2025 02:04:33 -0700 (PDT) X-Received: by 2002:a05:6a00:3d16:b0:73f:f816:dd7f with SMTP id d2e1a72fcca58-7423c01db46mr21539148b3a.15.1747127072032; Tue, 13 May 2025 02:04:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1747127072; cv=none; d=google.com; s=arc-20240605; b=i0h2GWXH45PC9NUDvirssxm6dNQKr6u89ZzdMp6tfgPXKFhVr6NsEBibKE+oKCtlpS snyCa1fMnXEEe0vtf0rYKLJ61hDzIMgAIRW6sQcyspJa/PxSANh7UYx1EPoryUTm/Fbd ERqf2W2qCg5vcegRe1ASO6bD6E4D3/l1sZwdKUqwGFhcFdvRT5Lf7t2yVTPdLcT83APe vCqDNV45uFpKOsZs+RMDAX2YNppglucs9e2HvHgXe1KN+vkjQ/QBzIwmF+2tQD/NaI23 auQNWV9ftQc9UXwPCaKVV1aXvjZ/wv112uaSqta/u4zu9EMmS1aaQ0GroCep6PM+fwwG T5/A== 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=FU7fXAdkFTuXkzZ2wMmUoNH14NzZOv/3yufeBs98dpU=; fh=FHPCOD3vptmuEQg9drujpZ488lCS6X5YsZgbHrlMbXI=; b=EiLRLI1dxeIqzW9qb/0jW+EZ6ynOd1MNeKkiYQoiKGPfKD8STdfhbFErwYnJ0FHSAU KGTkXwQvmVlrottF4rsyGzblqW9avjDyyyQUU8OVQWepABoNLrUfkT4TD8fQiBu2zSfU X1tSCWRznQyro2A8ak2QYQkgfQukGZNBtMY6D+DJlxjo+Lrx/DUVWWK5ZvHSZW0Za8Ny IiNbpAeMLnne7MdVPDcGBcWGqeEMtXw5WwGwyhw9/53ZKznOS5O1FIcccmtIiLNcT+Pg R7Cx4d/GW6AIxlXWxlCa9A0LMojCmRm8jK7pJtKqu5kW5pKaExAqiwtE3+ccYuk72JdJ BAFA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=XUwYpwdQ; spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::112f 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-yw1-x112f.google.com (mail-yw1-x112f.google.com. [2607:f8b0:4864:20::112f]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-b234c37c404si349339a12.5.2025.05.13.02.04.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 May 2025 02:04:32 -0700 (PDT) Received-SPF: pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) client-ip=2607:f8b0:4864:20::112f; Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-70a1f2eb39aso49464467b3.1 for ; Tue, 13 May 2025 02:04:31 -0700 (PDT) X-Gm-Gg: ASbGncuZUERS/Opg8GnTEWIsMmWN+83b5IOT1so1l3/7muknszKgZpbaIK69W8dUxul r4bkQjtwvQliuRe2gQlDW7t1Ngu9LI7gRXG5Re4w6rfeHGVKznxIdqumBymhWVwyLT8FwL6WaIu /FfdDqXyx6eCzD6BC0qvU5GQaSN6kCBz4= X-Received: by 2002:a05:690c:9b02:b0:709:1529:c24f with SMTP id 00721157ae682-70a3f9f34ffmr196653147b3.4.1747127071283; Tue, 13 May 2025 02:04:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Stewart Date: Tue, 13 May 2025 04:03:00 -0500 X-Gm-Features: AX0GCFvMoD_Br6jMmkVP7TfGQ66yae6_riYIX3WbDlVl8KipkTzFjTEcU3VDYYo Message-ID: Subject: Re: [bitcoindev] [Proposal] 64-bit arithmetic in Script To: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000762793063500b875" 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=XUwYpwdQ; spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::112f 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 (/) --000000000000762793063500b875 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 mentions 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 featur= es 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 cryptographic = 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_SUCCESSx, arbitrary precision becomes a real option . I chose 64 bits because it covers what=E2=80=99s needed for amount locks. I= f 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 doesn= =E2=80=99t support looping, so it=E2=80=99s not straightforward to iterate over and su= m 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, thou= gh. -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 soft for= k, > at least without using a different leaf version. But it also mentions > 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 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 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 the supported precision. >> >> >> https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.m= ediawiki >> >> The purpose for this BIP is to lay the groundwork for introducing amount= s >> 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 serio= us >> 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 Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9iq5_SR-Fa5zVZ= RoTpHasX7xoprYeJZRd5D80J1GqA%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%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A%40mail.gmail.com. --000000000000762793063500b875 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin

Thanks for your in= terest in the topic.

>It mentions upgrading exi= sting opcodes, which is a hardfork, not soft=20 fork, at least without using a different leaf version. But it also=20 mentions OP_SUCCESSX which are different opcodes

I= view 64-bit arithmetic as a feature of a wider set of consensus changes. H= ere is what I think the most likely deployment story is

>This pro= posal could be deployed in conjunction with any of the new=20 opcode proposals in the Motivation section using Tapscript's OP_SUCCESS= x semantics.[18]

The opcodes mentioned in the motivation section are OP_{IN,O= UT}_AMOUNT, OP_VAULT, OP_CHECKCONTRACTVERIFY, OP_CTV

As an example, this proposal could (hypothetically) be deployed in conju= nction with OP_CCV. OP_CCV would take advantage of the OP_SUCCESSx semantic= s allowing us to redefine existing opcode's (OP_ADD,OP_SUB, etc) semant= ics.=C2=A0

There=E2=80=99s been some discussion= around deploying OP_CTV via a NOP opcode ins= tead of OP_SUCCESSx. I think that would be a poor choice, as i= t wouldn=E2=80=99t allow new Script features to be shipped in parallel with= the new opcode.

I found this Stac= kExchange post helpful in thinking through various deployment strategie= s for new Tapscript-based consensus upgrades.

>= I'd also love to see analysis why stop at 64 bits and not go all the wa= y to 256 which could be useful for cryptography.

I= n my view, there=E2=80=99s still a lot of uncertainty about cryptographic f= eatures being added to Script. There's increasing discussion around qua= ntum computing, which raises the question of how much numerical precision w= e 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_SUCCES= Sx, arbitrary precision becomes a real option.
I chose 64 bits because it covers what=E2=80=99s needed for amo= unt locks. 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 t= he stack would be great. Though I'm=20 surprised you're only proposing the sum, not individual outputs. Why?

Good question=E2=80=94and slightly out of scope for= this BIP. Script doesn=E2=80=99t support looping, so it=E2=80=99s not stra= ightforward to iterate over and sum all elements unless the transaction str= ucture (i.e., number of inputs or outputs) is known in advance.
You can measure the number of stack elements with OP_DEPTH, bu= t there=E2=80=99s no way to write something like OP_ADD [num-stack-el= ements-from-OP_DEPTH] to sum them all. I=E2=80=99m definitely open t= o hearing other approaches, though.

-Chris



On Mon, May 12, 2025 at 2:32=E2=80=AFPM Marti= n Habov=C5=A1tiak <martin.habovstiak@gmail.com> wrote:
Hi,

the proposal seems to be quite confused abou= t how it's going to do that. It mentions upgrading existing opcodes, wh= ich is a hardfork, not soft fork, at least without using a different leaf v= ersion. But it also mentions OP_SUCCESSX which are different opcodes. I thi= nk it needs some analysis. (leaf version seems better intuitively)

I'd also love to see analysi= s why stop at 64 bits and not go all the way to 256 which could be useful f= or cryptography.

Anyway,= pushing amounts on the stack would be great. Though I'm surprised you&= #39;re only proposing the sum, not individual outputs. Why?

Good luck!
Martin

<= div dir=3D"ltr" class=3D"gmail_attr">D=C5=88a po 12. 5. 2025, 14:21 Chris S= tewart <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]= =20 that interpret stack elements as numbers are upgraded to support 64-bit par= ameters.

The existing number encoding format[2]=20 and arithmetic semantics[3]=20 from the original Bitcoin implementation are preserved, while enhancing the= supported precision.

https://github.com/Christewart/bips/blob/2025-03-17-64= bit-pt2/bip-XXXX.mediawiki

The purpose for this BIP is to lay the= groundwork for introducing amounts into Script. This document takes no opi= nion on how this is done.

I've prototyped a few different proposa= ls now introducing amount locks into Script[0][1] and feel like this propos= al is stable enough for serious review.

-Chris

[0] - https://delvingbitcoin.org/t/op-inout-am= ount/549/4?u=3Dchris_stewart_5

[1] - https://delvingbitcoin.org/t/op-inout-amount/549/5?u=3Dchr= is_stewart_5



--
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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAGL6%2BmH%2B9i= q5_SR-Fa5zVZRoTpHasX7xoprYeJZRd5D80J1GqA%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%2BmHv%2Bkn6SU9pf0Rz3FmM5OfcsmEtqGBRJ7Upb-b0MofS5A%= 40mail.gmail.com.
--000000000000762793063500b875--