From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 10 Nov 2025 06:48:35 -0800 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vITC6-00052g-6g for bitcoindev@gnusha.org; Mon, 10 Nov 2025 06:48:34 -0800 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-3d34aded76bsf8456443fac.2 for ; Mon, 10 Nov 2025 06:48:33 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762786108; cv=pass; d=google.com; s=arc-20240605; b=WDNkbacHtQj3diB7zldTiKrmlaVpOXCiHha9Lfykx9i54nxhrTPwE9wsZxC+PWZkGJ 7yE+u9hXRDdCD1YF5WwP53rWqf+hVlmfEF8XBUq0/+ILpeiNmlvgBMJ0FLqRKKOMbaYO QFtaMqGGA3Zq9jlCSFx1qpKVWoxAzTZXfDj5B74ZgQ4FKs/Wdouo/KzwkfwhcG3lHDHE MjqwW2s4xpwTbCJt5XBOr3a109mB0Fnlj52KsI1VmMMWZeUZ/Dd/cZ9vSnlFI3Fk1Z63 lOgVlgi1pohW0EQ559RmuHpDQMi/+UsVbiPdZrJuHtL2klEsppDnrJkS3pLJLqm7PI14 AqoQ== 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:reply-to:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:dkim-signature; bh=ItqB0XMLnrjWpxsj/2K+MF+UaiRKAuSb6KxphXfvcSA=; fh=FR0wCKdGhS96/tmS4EDMHW5MSY8zgKf6WrGhV5dbr8c=; b=lYq4uWTynBZgJvkLZj2vdFFAW9QXXLrIMhE3RTjpYSEs0r/tn+OBt03XJc67jeYmdr ZccLjZaE3umwIyPpI09Amlid2c78Dx03dxqna/OR3WE0hHeguH784Qtypp4KvIuokBDe Emdj38Xkex9Up0mzF/r83aOA9xJOwccfdWWInvAJ8suwaM2ZwYREFXq3k2awlpkj9tjy g7o5nlNjuEtpq3TpDAlxkMx2iKZpBaC5Prfdna6/f3st4uhs+ain3f9FO28iafOAM7dz kO6/AP4uGEYAxR8/uwyYyVajVIPVUaQgDwsy1j//NldRXlO94PL0pc8Jg3dLGxSpT43c Gh4A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=AgixdZLd; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::62c as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762786108; x=1763390908; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :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=ItqB0XMLnrjWpxsj/2K+MF+UaiRKAuSb6KxphXfvcSA=; b=uY1f+VFHNs3pfZIJskOUHShaGMsZgiGQIU1/rAaAiAhQp+JkrCoTH48F7yGRwlWoXR cX7vgXklto+AFF/OxaVItbZB/rFU+yx845Z96YqyJrxXXtxddAbcSa1WvlWnrZwtMhdo 5kB6bf9QYHosK1WGNAiFs4lxiXGYpkORoyMVtqBtyUEN8/qun09wceMtAJYphlC7fz9n OdBV3qn3jNMKTEeLfrSepTYqx2RcgBjPro02tP+yyj7A2NrwRiEb5aZo+TtQ4gJ/FA+k bNAzTLBq8dFVZmYKfAu6dgOcV+1MpJZHYbXa2m1bDq5vaTCgTquK+3YzM0Pqs/82oKZu jE4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762786108; x=1763390908; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:x-gm-gg :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ItqB0XMLnrjWpxsj/2K+MF+UaiRKAuSb6KxphXfvcSA=; b=l3DQompis2TR3LZL8V9t99XHgn4gvwZ9e2okYSt7RNUD6KEFPwdfarnZhZPMq/ke/L zJNseLAmED6FdXsQnTleoSWyiknNAHD63e5cnkD2OSuuVds0rWlr004f/XXJuFqyk1sd 0XqOMnEShZOkx3F0qYn5X3boQiwBvvG7Yg3QRY8kzLTexlhCjunGfndRdDnCx0Gm/ZHO hobydkNr5NkfellASbjzxN91dvLQ5jyALGTg0YZR8R+noohAIDk8rV65TjVfIeFG48/Z Poo0BgOgu83u6qRLAAtc2vwtQB31mpXPdO+3UP4w0sT1LZ9bHuf/lCtrf2MvfZ5QMpgc ykRA== X-Forwarded-Encrypted: i=2; AJvYcCWD+gKvfa9vEY70fDR+j9GpJq2PFfauzrteAcCOSpeAF5D07mXQMFIPbQPbbA8RkX3GRC1SH3Po8GpX@gnusha.org X-Gm-Message-State: AOJu0YwF9HsBtQIfj7eLDdUPpgoTNtycgSfsAsER6u3Tk1NjSbM3XAQI wVgUEhrl5Gom/qVfe1Ai6L+yzwRQgC5PXXw2PvI6n65f7ScFbmJ5o+ZI X-Google-Smtp-Source: AGHT+IFWK342mLA8XM3MpPrxZmkiu88b6URW+tzhsDLJeiRhKutOscA5ZV7An5+4NbvkUXlEHMknIg== X-Received: by 2002:a05:6870:b14d:b0:3d6:211f:fa5b with SMTP id 586e51a60fabf-3e7c254a466mr4832887fac.21.1762786107586; Mon, 10 Nov 2025 06:48:27 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+aRhgoOgsFsq4Nf2Czqjh0ODNgS2iS0qWLbnEOJZiQqTQ==" Received: by 2002:a05:6871:bd11:b0:3d3:6b50:4f3a with SMTP id 586e51a60fabf-3e2f1df6ddels2090053fac.0.-pod-prod-07-us; Mon, 10 Nov 2025 06:48:22 -0800 (PST) X-Received: by 2002:a05:6808:4442:b0:43f:1c66:bb94 with SMTP id 5614622812f47-4502a3bc08amr5993249b6e.47.1762786102904; Mon, 10 Nov 2025 06:48:22 -0800 (PST) Received: by 2002:a05:6808:1ddd:b0:450:1552:6123 with SMTP id 5614622812f47-450155265femsb6e; Mon, 10 Nov 2025 06:46:45 -0800 (PST) X-Received: by 2002:a17:903:1b08:b0:298:2878:ec4f with SMTP id d9443c01a7336-2982878eca0mr31475355ad.58.1762786004284; Mon, 10 Nov 2025 06:46:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762786004; cv=none; d=google.com; s=arc-20240605; b=N60aHFTt7sE+IK5mX572MBls9nv/gAGZJudS4efqKEsQXOkEzPyXmoJNu/AVOBWA9V NZtPdfMYbHGXEx1++S50V9/c5tiUP4nklOv2vXBLdlzLxk16nrutq0HrWKOz9M2opa63 hsay/ZlKLBzJNf9l4fh0nPCVKbOfs/C6iB35RCSkS95lsQ/3rUdlOcbuNfL/TCSCNAnc J5iuwkJLbm7vfRW+5mjSc0Lk4OZdNQ7YT30x9+z6t44+yDltMS84zWjxQFCu4rHF0Djn TpZnYnvqV0yLr+evc0AYzGr0xBtwIyiS6cGObS6CwrGQOZRhtYdH0ECxrO5iAyTY+Nbj NoUQ== 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=jLWDLR/Tk1phiQg8T8kRVu6FI6YP0UrysS5ocrJae1Q=; fh=3YzYoYv3M9y574U02ozCGoBnGYQmerdHaMmp3jvyG5o=; b=S+Ai+gsu/U7yqIeQq28OsxMgFjEtJ5Y0pF1IxZkS4nmVq5nawB9AVukqzX1XCb5F+p M6xYV1XL+/hvya3NFknMBIY0x9WwtcYFN4r9Y4JjcK27BjUQE3wjRTe0Pbz5WH68Tp67 psUtjG9EGJL+hMsn434WIWAqcpuj0L8cHT5bkJDBQthJfs4X+6RLE/l3GqybrEFg+Qdx LMgjoPi6PcSdVn6E+vPM8K0gKyHbaEih9aq42PW2w9Ms9wKz0ABYi6hIpC74CZTDlLOB 5/htdflAxf1Mutl9CKmvpjOLfs/rcvuNVzEttthrdMLGopfpkKGPPCh8/+WwKijCY4CV Pnxg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=AgixdZLd; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::62c as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com. [2607:f8b0:4864:20::62c]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-34346de6124si303612a91.2.2025.11.10.06.46.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Nov 2025 06:46:44 -0800 (PST) Received-SPF: pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::62c as permitted sender) client-ip=2607:f8b0:4864:20::62c; Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-297dc3e299bso20932945ad.1 for ; Mon, 10 Nov 2025 06:46:44 -0800 (PST) X-Gm-Gg: ASbGncuJMX98/etlJE6GgiteycU5qv4cpkJxF9Asx1cL2/o2iwela6ZewrwnSc2ZyXy 98/N89heE5oweq/vOzFZAwugbTeKJKK7Ht4omqFJAKCfC+HQl+NzdBW8kDHsFLJdpP+OWxq7UXj 2b19B16lFAF+nHIWww48jzHlmoiBVV8YDV8Wi4q0+O2i3EGasVa41urlpbndPTi474bfU/VT5cZ 52o1xynYhaIvJKT9JjLxpfmKLd0m10VdJSYNC5xPcRKUHP3hKJYw3ZKG9WgvF6w+aDRRw+D X-Received: by 2002:a17:903:2987:b0:278:704:d6d0 with SMTP id d9443c01a7336-297e565d96emr102578855ad.19.1762786003362; Mon, 10 Nov 2025 06:46:43 -0800 (PST) MIME-Version: 1.0 References: <19fde638-aa4f-4a02-9aad-ea437c73b3c1n@googlegroups.com> In-Reply-To: <19fde638-aa4f-4a02-9aad-ea437c73b3c1n@googlegroups.com> From: "'Russell O'Connor' via Bitcoin Development Mailing List" Date: Mon, 10 Nov 2025 09:46:29 -0500 X-Gm-Features: AWmQ_blAekeXccNZ3ESQjsd2VfZwRIBeXIj24kzL7FhIQJbJ1KDqC3BKC-kdfYM Message-ID: Subject: Re: [bitcoindev] Benchmarking Bitcoin Script Evaluation for the Varops Budget (GSR) To: Bitcoin Development Mailing List Cc: Julian Content-Type: multipart/alternative; boundary="0000000000008bb92e06433e99fb" X-Original-Sender: roconnor@blockstream.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=AgixdZLd; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::62c as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com X-Original-From: "Russell O'Connor" Reply-To: "Russell O'Connor" 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 (-) --0000000000008bb92e06433e99fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My understanding is that in order to avoid block assembly becoming an NP-hard packing problem, there must be only one dimension of constraint solving. However, AFAICT, in your tarscript V2 code you have both the new varops constraint and the original sigops constraint. FWIW, in Simplicity we reuse the same budget mechanism introduced in tapscript (V1) with our cost calculations (though our costs are computed 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 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 wer= e > denial-of-service attacks through excessive computational 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 any computationally > expensive operations or lifting any other script limits. > > Similar to the sigops budget (which is applied to each input > individually), the varops budget is based on transaction weight, a larger > transaction has proportionally more compute units available. Currently, t= he > 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: bi= ps/bip-unknown-varops-budget.mediawiki > at guilt/varops =C2=B7 rustyrussell/bips =C2=B7 GitHub > > > To validate that this approach is working and that the free parameters ar= e > reasonable, we need to understand how it constrains script execution and > 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 > 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 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 wou= ld > 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 varops 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 lo= op like: > OP_SHA256 OP_DROP OP_DUP (repeated) > > Other operations have 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 onto the stack =E2=80=9Cfor free=E2=80=9D for simplic= ity and to make > the budget more conservative. In reality, these elements would need to be > 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 > 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 validation time, we need to collect > benchmarks from various machines and architectures. This is especially > important for hashing operations, where computational time does not scale > linearly and depends on the implementation, which varies between chips an= d > architectures. > > =3D=3D=3D How to Help =3D=3D=3D > > To collect more data, we would like to run benchmarks on various machines= . > 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 > varops budget specifically for your machine depending 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 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/19fde638-aa4f-4a02-9aad-ea43= 7c73b3c1n%40googlegroups.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/= CAMZUoK%3D1B%3DLQxkhPsbx22wAFkgsKT20J-6%2Br-Pa0AAh9AMgo4g%40mail.gmail.com. --0000000000008bb92e06433e99fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My understanding is that in order to avoid block asse= mbly becoming an NP-hard packing problem, there must be only one dimension= =C2=A0of constraint solving.=C2=A0 However, AFAICT, in your tarscript V2 co= de you have both the new varops constraint and the original=C2=A0sigops con= straint.

FWIW, in Simplicity we reuse the same bud= get mechanism introduced in tapscript (V1) with our cost calculations (thou= gh our costs are computed 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 Mailing List <bitcoindev@googlegroups.com= > wrote:

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

The main concerns that led to the disabling of many opc= odes in v0.3.1 were denial-of-service attacks through excessive computation= al time and memory usage in Bitcoin script execution. To mitigate these ris= ks, we propose to generalize the sigops budget in a new Tapscript leaf vers= ion and apply it to all operations before attempting to restore any computa= tionally expensive operations or lifting any other script limits.

Simi= lar to the sigops budget (which is applied to each input individually), the= varops budget is based on transaction weight, a larger transaction has pro= portionally more compute units 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 e= tc. More details can be found in the BIP:=C2=A0bips/bip-unknown-varops-budget.mediawiki at guilt/varops =C2=B7 rustyrus= sell/bips =C2=B7 GitHub

To validate that this approach is working = and that the free parameters are reasonable, we need to understand how it c= onstrains script execution and what the worst-case scripts are.

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

For simplicity, we benchmark the s= cript evaluation of block sized scripts with the goal of finding the slowes= t possible script to validate. This 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 lo= oped until one of the two limits is exhausted. For example, a loop of OP_DU= P 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 varops budget, while faster opera= tions like stack manipulation or arithmetic on small numbers are bound by t= he block size limit.

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

OP_SHA= 256 OP_DROP OP_DUP (repeated)

Other operations have different restoration patterns. For b= it 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 size= s. The initial elements are placed onto the stack =E2=80=9Cfor free=E2=80= =9D for simplicity and to make the budget more conservative. In reality, th= ese elements would need to be pushed onto the stack first, consuming additi= onal space and varops budget.

=3D=3D=3D Baseline: Signature Validation= =3D=3D=3D

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

<= div style=3D"display:flex">
4M weight units / 50 weight units per s= ig =3D 80,000 signature checks per block

Using nanobench, we measure how long it takes to execute pu= bkey.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 scr= ipt execution time to be no slower than the worst case signature validation= time, we need to collect benchmarks from various machines and architecture= s. This is especially important for hashing operations, where computational= time does not scale linearly and depends on the implementation, which vari= es between chips and architectures.

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

To collect more data, we would like to run benchmarks on various mac= hines. You can run the benchmark by:

1. Checking out the GSR prototype= implementation branch:

GitHub - jmoik/bitcoin at gsr

2. Compiling with benchm= arks enabled (-DBUILD_BENCH=3DON)

3. Running the benchmark:

./bui= ld/bin/bench_varops --file bench_varops_data.csv

This will store the r= esults in a csv and predict a maximum value for the varops budget specifica= lly for your machine depending on your Schnorr checksig times and the slowe= st varops limited script. It would be very helpful if you shared your resul= ts so we can analyze the data across different systems and verify if the bu= dget is working well or has to 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/19fde638-aa4f-4a02-9aad-ea437c73b3c1n%40googlegrou= ps.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.co= m/d/msgid/bitcoindev/CAMZUoK%3D1B%3DLQxkhPsbx22wAFkgsKT20J-6%2Br-Pa0AAh9AMg= o4g%40mail.gmail.com.
--0000000000008bb92e06433e99fb--