From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 28 Nov 2025 05:47:49 -0800 Received: from mail-ot1-f62.google.com ([209.85.210.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vOypA-0002T0-7t for bitcoindev@gnusha.org; Fri, 28 Nov 2025 05:47:49 -0800 Received: by mail-ot1-f62.google.com with SMTP id 46e09a7af769-7c7032a5b40sf723612a34.1 for ; Fri, 28 Nov 2025 05:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764337662; x=1764942462; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=cFeUhNcS2Qncggh+D/K5UwcqlUQZ4JKKCXBTtZOaTWQ=; b=QoNtz78C6tJsqRVUdWojsQjIbCr3o74shXO5bB7fTY+gIm3jqUqkO98g3KrY2DnGn2 68Wim/Z4V6QOpqtzybaucnoBm9ggDwBBcea8+UmJOwJZEj/iJD6NGSI7jJlfn4okUUCb 4mwjGXZf9OBpqa8SppeYw+19EPTrCS+X6CzBPf+OkD556JMZT1vRgEAEbBteeV2GZ7om Tl3TJ1mvFWyplikJ8SVaATlfFtO8XMycAsGuIhO1dCWJIVSg0DB/VjHoQSZF8GPCSm1X TTSM1dHDKVp+Uchrkb/Ed6w+7Z6Rgm2cH9ri2TRmHG8c4K7d96Yb4fckxQVzAjPPSx8Z AuRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764337662; x=1764942462; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cFeUhNcS2Qncggh+D/K5UwcqlUQZ4JKKCXBTtZOaTWQ=; b=hHL7pJi/LVCDJYjIcaWkQ1qgFaNn1iip94OxiZjp1MTuYVnb6be5B5lPjukAZdDdOQ jc16wzBV+4yTydOUggkQQpuhL60mp7Cyya7efBxr5Xkoxqe5/6oVCWq4gGtlbouzfPfo m72pkVjmQDW12OXWF6zS9ak8EghlBHQgMOizb6Cte5hDnwGBi+ffIEyKYxXo9ZV6z8gR 1ebLm7XFJoUkzk6ECRZtAenHOX08MYTJnPGEAVi19wJx8HRN84sIAh3C/656PTTXRlxm aNkfaY5+IsfD0T3lK4niEeJeRCiZ14P119cR5kJvPqRJ99OikoqbrldIEfQmfH5RDafH XjEA== X-Forwarded-Encrypted: i=1; AJvYcCV/MW8QKE7Oo+w49aEhFDJpB3s4brplFCsRiscPGQe2ulzq2vRvNK1/ankN2SZDLoEIwSaFQ5InkhZW@gnusha.org X-Gm-Message-State: AOJu0YwZa0LT7Py6AfOLHoaTKh7ISbveTLddu+44mBkiZAB79sbyioWQ rRYuoWkqamk6anA5US9nlM2cxDi0a72pt6FOK6x1b2XbwO1TGQmKcWmu X-Google-Smtp-Source: AGHT+IH2X4p0qjxd9ux+hBC9tVkL7fDSNkKjV8AYKhsep2HUKhl/UZ4jpdRRhkqJES/+4Lc/qNYmyw== X-Received: by 2002:a05:6830:4408:b0:7c7:5458:75f8 with SMTP id 46e09a7af769-7c79908f31emr12334409a34.29.1764337661651; Fri, 28 Nov 2025 05:47:41 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YKNIievmj3AyhPbtBwMd6rp6qdck1kK/KvA+afmOCJPQ==" Received: by 2002:a05:6870:2408:b0:3d5:54c4:3245 with SMTP id 586e51a60fabf-3f0d2734145ls1083724fac.2.-pod-prod-01-us; Fri, 28 Nov 2025 05:47:35 -0800 (PST) X-Received: by 2002:a05:6808:884c:10b0:451:4c8a:25e8 with SMTP id 5614622812f47-4514c8a52e7mr5035929b6e.6.1764337655670; Fri, 28 Nov 2025 05:47:35 -0800 (PST) Received: by 2002:a05:690c:2a8e:b0:786:6c46:840 with SMTP id 00721157ae682-78ac2e8224fms7b3; Fri, 28 Nov 2025 05:09:27 -0800 (PST) X-Received: by 2002:a05:690e:83:b0:63f:b410:e93 with SMTP id 956f58d0204a3-64302abb9f1mr15171065d50.42.1764335366059; Fri, 28 Nov 2025 05:09:26 -0800 (PST) Date: Fri, 28 Nov 2025 05:09:25 -0800 (PST) From: "'Julian' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <5906e2bb-c215-44b0-bb61-0bb91d55717dn@googlegroups.com> In-Reply-To: References: <19fde638-aa4f-4a02-9aad-ea437c73b3c1n@googlegroups.com> Subject: Re: [bitcoindev] Benchmarking Bitcoin Script Evaluation for the Varops Budget (GSR) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_926338_203397445.1764335365586" X-Original-Sender: Julian.Moik@googlemail.com X-Original-From: Julian Reply-To: Julian 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: -1.0 (-) ------=_Part_926338_203397445.1764335365586 Content-Type: multipart/alternative; boundary="----=_Part_926339_511551798.1764335365586" ------=_Part_926339_511551798.1764335365586 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Russell, thanks for taking a look at the code. In interpreter.cpp the static function EvalChecksigTapscript(...) is=20 responsible for subtracting from execdata.m_validation_weight_left, for the= =20 original SigVersion::TAPSCRIPT this is still the case, but Tapscript v2 is= =20 implemented as a new SigVersion::TAPSCRIPT_V2 and therefore it will not=20 take the original sigops constraint into account (there is an if condition= =20 right above checking for the SigVersion). The new varops budget replaces this sigops constraint and is contained in= =20 the new EvalScript(...) overload. Currently it will only subtract from the= =20 budget if the checksig succeeds, but I think this should be moved up a=20 statement, such that it will always subtract the varops cost, making the=20 cost calculation more static. The changes have not been reviewed in depth and I am looking for someone=20 interested in helping me with that. On Monday, 10 November 2025 at 15:48:27 UTC+1 Russell O'Connor wrote: My understanding is that in order to avoid block assembly becoming an=20 NP-hard packing problem, there must be only one dimension of constraint=20 solving. However, AFAICT, in your tarscript V2 code you have both the new= =20 varops constraint and the original sigops constraint. FWIW, in Simplicity we reuse the same budget mechanism introduced in=20 tapscript (V1) with our cost calculations (though our costs are computed=20 statically instead of dynamically at runtime for better or for worse). On Fri, Nov 7, 2025 at 11:06=E2=80=AFAM 'Julian' via Bitcoin Development Ma= iling=20 List wrote: Hello everyone interested in Great Script Restoration and the Varops Budget= , The main concerns that led to the disabling of many opcodes in v0.3.1 were= =20 denial-of-service attacks through excessive computational time and memory= =20 usage in Bitcoin script execution. To mitigate these risks, we propose to= =20 generalize the sigops budget in a new Tapscript leaf version and apply it= =20 to all operations before attempting to restore any computationally=20 expensive operations or lifting any other script limits. Similar to the sigops budget (which is applied to each input individually),= =20 the varops budget is based on transaction weight, a larger transaction has= =20 proportionally more compute units available. Currently, the budget is set= =20 to 5,200 units per weight unit of the transaction. The varops cost of each opcode depends on the length of its arguments and= =20 how it acts on the data; whether it copies, compares, moves, performs=20 hashing, or does arithmetic etc. More details can be found in the BIP: bips= /bip-unknown-varops-budget.mediawiki=20 at guilt/varops =C2=B7 rustyrussell/bips =C2=B7 GitHub=20 To validate that this approach is working and that the free parameters are= =20 reasonable, we need to understand how it constrains script execution and=20 what the worst-case scripts are. =3D=3D=3D Benchmark Methodology =3D=3D=3D For simplicity, we benchmark the script evaluation of block sized scripts= =20 with the goal of finding the slowest possible script to validate. This=20 block sized script is limited by: - Size: 4M weight units - Varops budget: 20.8B compute units (4M =C3=97 5,200) To construct and execute such a large script, it must be looped until one= =20 of the two limits is exhausted. For example, a loop of OP_DUP OP_DROP would= =20 take an initial stack element and benchmark the copying and dropping=20 repeatedly until either the maximum size or the varops budget is reached.= =20 Computationally intensive operations like arithmetic or hashing on large=20 numbers are generally bound by the varops budget, while faster operations= =20 like stack manipulation or arithmetic on small numbers are bound by the=20 block size limit. For simple operations like hashing (1 in =E2=86=92 1 out), we create a loop= like: OP_SHA256 OP_DROP OP_DUP (repeated)=20 Other operations have different restoration patterns. For bit operations (2= =20 in =E2=86=92 1 out): OP_DUP OP_AND OP_DROP OP_DUP (repeated)=20 These scripts act on initial stack elements of various sizes. The initial= =20 elements are placed onto the stack =E2=80=9Cfor free=E2=80=9D for simplicit= y and to make=20 the budget more conservative. In reality, these elements would need to be= =20 pushed onto the stack first, consuming additional space and varops budget. =3D=3D=3D Baseline: Signature Validation =3D=3D=3D Currently, the theoretical limit for sigops in one block is: 4M weight units / 50 weight units per sig =3D 80,000 signature checks per= =20 block=20 Using nanobench, we measure how long it takes to execute=20 pubkey.VerifySchnorr(sighash, sig) 80,000 times. On a modern CPU, this=20 takes between one and two seconds. If we want the varops budget to limit script execution time to be no slower= =20 than the worst case signature validation time, we need to collect=20 benchmarks from various machines and architectures. This is especially=20 important for hashing operations, where computational time does not scale= =20 linearly and depends on the implementation, which varies between chips and= =20 architectures. =3D=3D=3D How to Help =3D=3D=3D To collect more data, we would like to run benchmarks on various machines.= =20 You can run the benchmark by: 1. Checking out the GSR prototype implementation branch: GitHub - jmoik/bitcoin at gsr 2. Compiling with benchmarks enabled (-DBUILD_BENCH=3DON) 3. Running the benchmark: ./build/bin/bench_varops --file bench_varops_data.csv This will store the results in a csv and predict a maximum value for the=20 varops budget specifically for your machine depending on your Schnorr=20 checksig times and the slowest varops limited script. It would be very=20 helpful if you shared your results so we can analyze the data across=20 different systems and verify if the budget is working well or has to be=20 adjusted! Cheers Julian --=20 You received this message because you are subscribed to the Google Groups= =20 "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an= =20 email to bitcoindev+...@googlegroups.com. To view this discussion visit=20 https://groups.google.com/d/msgid/bitcoindev/19fde638-aa4f-4a02-9aad-ea437c= 73b3c1n%40googlegroups.com=20 . --=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/= 5906e2bb-c215-44b0-bb61-0bb91d55717dn%40googlegroups.com. ------=_Part_926339_511551798.1764335365586 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Russell,

thanks for taking a look at the code.

In interpreter.cpp the static function EvalChecksigT= apscript(...) is responsible for subtracting from execdata.m_validation_wei= ght_left, for the original SigVersion::TAPSCRIPT this is still the case, bu= t Tapscript v2 is implemented as a new SigVersion::TAPSCRIPT_V2 and therefo= re it will not take the original sigops constraint into account (there is a= n if condition right above checking for the SigVersion).
The new varops budget replaces this sigops constraint and is= contained in the new EvalScript(...) overload. Currently it will only subt= ract from the budget if the checksig succeeds, but I think this should be m= oved up a statement, such that it will always subtract the varops cost, mak= ing the cost calculation more static.

The change= s have not been reviewed in depth and I am looking for someone interested i= n helping me with that.



<= /div>
On Monday, 10 November 2025 at 15:48:27 UTC+1 R= ussell O'Connor wrote:
My understan= ding is that in order to avoid block assembly becoming an NP-hard packing p= roblem, there must be only one dimension=C2=A0of constraint solving.=C2=A0 = However, AFAICT, in your tarscript V2 code you have both the new varops con= straint and the original=C2=A0sigops constraint.

FWIW, in Simplicity we reuse the same budget mechanism introduced in tapsc= ript (V1) with our cost calculations (though our costs are computed statica= lly instead of dynamically at runtime for better or for worse).
=
On Fri, Nov 7, 2025 at 11:06=E2=80= =AFAM 'Julian' via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:
<= blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bord= er-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: = 1ex;">

Hello everyone interested in Great Script= Restoration and the Varops Budget,

The main concerns that le= d to the disabling of many opcodes in v0.3.1 were denial-of-service attacks= through excessive computational time and memory usage in Bitcoin script ex= ecution. To mitigate these risks, we propose to generalize the sigops budge= t in a new Tapscript leaf version and apply it to all operations before att= empting to restore any computationally expensive operations or lifting any = other script limits.

Similar to the sigops budget (which is a= pplied to each input individually), the varops budget is based on transacti= on weight, a larger transaction has proportionally more compute units avail= able. Currently, the budget is set to 5,200 units per weight unit of the tr= ansaction.

The varops cost of each opcode depends on the leng= th of its arguments and how it acts on the data; whether it copies, compare= s, moves, performs hashing, or does arithmetic etc. More details can be fou= nd in the BIP:=C2=A0bips/bip-unknown-var= ops-budget.mediawiki at guilt/varops =C2=B7 rustyrussell/bips =C2=B7 GitHub=

To validate that this approach is working and that the f= ree parameters are reasonable, we need to understand how it constrains scri= pt execution and what the worst-case scripts are.

=3D=3D=3D B= enchmark Methodology =3D=3D=3D

For simplicity, we benchmark t= he script evaluation of block sized scripts with the goal of finding the sl= owest possible script to validate. This block sized script is limited by:

- Size: 4M weight units

- Varops budget: 20.8B c= ompute units (4M =C3=97 5,200)

To construct and execute such = a large script, it must be looped until one of the two limits is exhausted.= For example, a loop of OP_DUP OP_DROP would take an initial stack element = and benchmark the copying and dropping repeatedly until either the maximum = size or the varops budget is reached. Computationally intensive operations = like arithmetic or hashing on large numbers are generally bound by the varo= ps budget, while faster operations like stack manipulation or arithmetic on= small numbers are bound by the block size limit.

For simple = operations like hashing (1 in =E2=86=92 1 out), we create a loop like:

<= span style=3D"font-size: 16px; font-family: var(--d-font-family--monospace)= ; max-height: 2000px; display: block; overflow: visible; color: rgb(34, 34,= 34);">
OP_SHA256 OP_DR= OP OP_DUP (repeated)

Other operations have different restoration patter= ns. For bit operations (2 in =E2=86=92 1 out):

OP_DUP OP_AND OP_DROP OP_DUP (repeated)

These scripts act on initial stack elements of var= ious sizes. The initial elements are placed onto the stack =E2=80=9Cfor fre= e=E2=80=9D for simplicity and to make the budget more conservative. In real= ity, these elements would need to be pushed onto the stack first, consuming= additional space and varops budget.

=3D=3D=3D Baseline: Sign= ature Validation =3D=3D=3D

Currently, the theoretical limit f= or sigops in one block is:

<= span style=3D"font-family: var(--d-font-family--monospace); font-size: 14px= ; line-height: 1.30769; overflow: auto; display: block; padding: 12px; max-= height: 500px;">4M weight units / 50 weight units per sig =3D 80,000 signat= ure checks per block

Using nanobench, we measure how long it takes to e= xecute pubkey.VerifySchnorr(sighash, sig) 80,000 times. On a modern CPU, th= is takes between one and two seconds.

If we want the varops b= udget to limit script execution time to be no slower than the worst case si= gnature validation time, we need to collect benchmarks from various machine= s and architectures. This is especially important for hashing operations, w= here computational time does not scale linearly and depends on the implemen= tation, which varies between chips and architectures.

=3D=3D= =3D How to Help =3D=3D=3D

To collect more data, we woul= d like to run benchmarks on various machines. You can run the benchmark by:=

1. Checking out the GSR prototype implementation branch:

=

Git= Hub - jmoik/bitcoin at gsr

2. Compiling with benchmarks e= nabled (-DBUILD_BENCH=3DON)

3. Running the benchmark:

./build/bin/bench_varops --file bench_varops_data.csv

= This will store the results in a csv and predict a maximum value for the va= rops budget specifically for your machine depending on your Schnorr checksi= g times and the slowest varops limited script. It would be very helpful if = you shared your results so we can analyze the data across different systems= and verify if the budget is working well or has to be adjusted!

Cheers

Julian

--
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+...@googlegroups.com.<= br /> To view this discussion visit htt= ps://groups.google.com/d/msgid/bitcoindev/19fde638-aa4f-4a02-9aad-ea437c73b= 3c1n%40googlegroups.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/bitcoind= ev/5906e2bb-c215-44b0-bb61-0bb91d55717dn%40googlegroups.com.
------=_Part_926339_511551798.1764335365586-- ------=_Part_926338_203397445.1764335365586--