From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 07 Nov 2025 08:06:21 -0800 Received: from mail-oi1-f184.google.com ([209.85.167.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vHOyj-0005PU-0L for bitcoindev@gnusha.org; Fri, 07 Nov 2025 08:06:21 -0800 Received: by mail-oi1-f184.google.com with SMTP id 5614622812f47-450120486e8sf456161b6e.0 for ; Fri, 07 Nov 2025 08:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762531575; x=1763136375; 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:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=waXMhrrYtL0klN72W1hFcESUCHN6R4Zm9OUNzSlcycs=; b=vmIOx40tFjNM+kge33aZ8sb+VwL4Tyw43EAsoPIM8Lr7ybfITAuBH5p9Wf5cOsXP2W cWS/p2YXlN5Vo24nyUdXKZ65CXuObgucBmSNTb5Eo3kEQ2oahQRP4jKtzzPqG4QhpwBY jRe+aNR5h7grW/hicQm4+tPq7U0cpZw/SXzfMjJlzdquAIzpTgNFBnuk/N9XZR1d6x9d EQDGcgicsEqu5SFkglSzU8z3fOtFcpeSTWJ8xRmdi4/ufVTftoDdULxfcI7rlEZWmUYs qmhkWEOi7MgqmBpcX6pmPpsgqTEzGUSaYpivi8EBmjR3t7C6p1mcwUtFcMjcWXuqQ2yD PUvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762531575; x=1763136375; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=waXMhrrYtL0klN72W1hFcESUCHN6R4Zm9OUNzSlcycs=; b=d2FwMup1TBW1uZunfX8fSUZotQrX7k9QPBTYBslNxsC/suLchJbfm59O2xqwXkpwfR 0/MK+DPp1c2Q7YcPnccIuDTccRsSW+81m38iN077/ekUs/LNdVtpQNySv7CaDQrTyFN5 wi00zbB8Y230dqQJYiv+V3UwbRchfMtQeiuRz5LpY6botKrmIInOkiKHBsOn8EehZruT X/Zmrc9KUCozJXUWdMdxXlkc7DWyfzl0L5PCL5/CgSbFz+g/vkEq+Z0mEba2CN25qLpm ztTiZqhlz1Hkdt4lsDLO0FFMgHSpMEhLBR4Zlkr+Bvn7+iXazqumGrHeOvb3+jQjxaI/ 4CoQ== X-Forwarded-Encrypted: i=1; AJvYcCVfvOGpv/Jf8ma1vo9DSVOECfJrGNSUrpYYECHTY0aPbf50bt6NFtrd90BhvJ6yALkZLxtRQ2kwEsyj@gnusha.org X-Gm-Message-State: AOJu0YzmzNyxuAqQeuAtZgoZczHUKKSH39rZTkUYxhrWz8rbiw0Z2mJq 3E+AtdMYKJvNEoE3dtsICIUOyyD+d1qHOsLU16LGj8WgkNGMo/gF1KZw X-Google-Smtp-Source: AGHT+IFudPrZkHYYib8Euka0f1dhhNPHose1b1r7bn2C0jjOh3TOZFN1AkkUAQVITz45zyoHIeTnXg== X-Received: by 2002:a05:6808:30a3:b0:44d:b27f:a791 with SMTP id 5614622812f47-45015caa7d7mr1852448b6e.3.1762531573806; Fri, 07 Nov 2025 08:06:13 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+aRX4ODUwKuTPce79rSbsI6Vzm5SyQ/ys5I2E8MAuuM1g==" Received: by 2002:a4a:db69:0:b0:656:d1ea:96fc with SMTP id 006d021491bc7-656d1ea9ae8ls190934eaf.2.-pod-prod-06-us; Fri, 07 Nov 2025 08:06:07 -0800 (PST) X-Received: by 2002:a05:6808:17aa:b0:44f:6ab9:4b14 with SMTP id 5614622812f47-45015f5ac1dmr2135740b6e.62.1762531567608; Fri, 07 Nov 2025 08:06:07 -0800 (PST) Received: by 2002:a05:690c:5c16:b0:780:f7eb:fdf with SMTP id 00721157ae682-786a51170c0ms7b3; Fri, 7 Nov 2025 07:50:56 -0800 (PST) X-Received: by 2002:a05:690e:1508:b0:63c:f5a7:40f with SMTP id 956f58d0204a3-640c43b1b0fmr2683625d50.67.1762530655660; Fri, 07 Nov 2025 07:50:55 -0800 (PST) Date: Fri, 7 Nov 2025 07:50:55 -0800 (PST) From: "'Julian' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <19fde638-aa4f-4a02-9aad-ea437c73b3c1n@googlegroups.com> Subject: [bitcoindev] Benchmarking Bitcoin Script Evaluation for the Varops Budget (GSR) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_181298_123572791.1762530655312" 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_181298_123572791.1762530655312 Content-Type: multipart/alternative; boundary="----=_Part_181299_2083078295.1762530655312" ------=_Part_181299_2083078295.1762530655312 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 "= 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/= 19fde638-aa4f-4a02-9aad-ea437c73b3c1n%40googlegroups.com. ------=_Part_181299_2083078295.1762530655312 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

The main concerns that led to the disabling of= many opcodes in v0.3.1 were denial-of-service attacks through excessive co= mputational time and memory usage in Bitcoin script execution. To mitigate = these risks, we propose to generalize the sigops budget in a new Tapscript = leaf version and apply it to all operations before attempting to restore an= y computationally expensive operations or lifting any other script limits.<= /p>

Similar to the sigops budget (w= hich is applied to each input individually), the varops budget is based on = transaction weight, a larger transaction has proportionally more compute un= its available. Currently, the budget is set to 5,200 units per weight unit = of the transaction.

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

To validate that this approach is wo= rking and that the free parameters are reasonable, we need to understand ho= w it constrains script execution and what the worst-case scripts are.

=3D=3D=3D Benchmark Methodology =3D= =3D=3D

For simplicity, we bench= mark the script evaluation of block sized scripts with the goal of finding = the slowest possible script to validate. This block sized script is limited= by:

- Size: 4M weight units

- Varops budget: 20.8B compute un= its (4M =C3=97 5,200)

To constr= uct 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 i= nitial stack element and benchmark the copying and dropping repeatedly unti= l either the maximum size or the varops budget is reached. Computationally = intensive operations like arithmetic or hashing on large numbers are genera= lly bound by the varops budget, while faster operations like stack manipula= tion or arithmetic on small numbers are bound by the block size limit.

<= p style=3D"font-size: 16px; caret-color: rgb(34, 34, 34); color: rgb(34, 34= , 34); font-family: Arial, sans-serif;">For simple operations like hashing = (1 in =E2=86=92 1 out), we create a loop like:

OP_SHA256 OP_DROP = OP_DUP (repeated)

Other operations hav= e different restoration patterns. 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 various sizes. The initial elements are placed o= nto the stack =E2=80=9Cfor free=E2=80=9D for simplicity and to make the bud= get more conservative. In reality, these elements would need to be pushed o= nto the stack first, consuming additional space and varops budget.

=3D=3D=3D Baseline: Signature Validatio= n =3D=3D=3D

Currently, the theo= retical limit for sigops in one block is:

4M weight units / 50 we= ight units per sig =3D 80,000 signature checks per block

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

If we want the varops budget to limit = script execution time to be no slower than the worst case signature validat= ion time, we need to collect benchmarks from various machines and architect= ures. This is especially important for hashing operations, where computatio= nal time does not scale linearly and depends on the implementation, which v= aries between chips and architectures.

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

To collect more data, we would like to run benchmarks on var= ious machines. You can run the benchmark by:

1. Checking out the GSR prototype implementation branch:

<= p style=3D"font-size: 16px; caret-color: rgb(34, 34, 34); color: rgb(34, 34= , 34); font-family: Arial, sans-serif;">GitHub - jmoik/bitcoin = at gsr

2. Compiling with be= nchmarks enabled (-DBUILD_BENCH=3DON)

3. Running the benchmark:

This will store the results in a csv and predict a= maximum value for the varops budget specifically for your machine dependin= g on your Schnorr checksig 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 t= o be adjusted!

Cheers

Julian

--
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/19fde638-aa4f-4a02-9aad-ea437c73b3c1n%40googlegroups.com.
------=_Part_181299_2083078295.1762530655312-- ------=_Part_181298_123572791.1762530655312--