From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 17 Mar 2025 06:35:36 -0700 Received: from mail-yw1-f192.google.com ([209.85.128.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tuAcw-0003oh-Vx for bitcoindev@gnusha.org; Mon, 17 Mar 2025 06:35:36 -0700 Received: by mail-yw1-f192.google.com with SMTP id 00721157ae682-6fedcc61536sf72673277b3.0 for ; Mon, 17 Mar 2025 06:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1742218529; x=1742823329; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=HuUxeFY2TYIMCMb8HQIUf2EEh3PjN1Fnrr3CH/CuE0E=; b=sEHqM/Ba5S2saiKeWjwdmlaIzUeOxw8D3S1hfmPYVcLq6IRcJNyWr4KudcQq0kerFM qmvYsMYbbTLxfU3Dae3WKZPACprefT1KypspVLvbHtzKaRbN6DsIJpr1iqmKvzupozl+ otKrGpl/uRFwItnqlgHKZd3dDeO4LaT2jFZPH7CCcLUyYEBt4Jhrt9mnpTr1hh3Csy4l BSMGo6Kl5wwM8iOkfd24m11Sg2Z78mtQ5XqX9Z5Y8+luUvGVXXCek1F5/o8SLS5WYrw4 +5Nz7IeMOt/5imslCpdr2xsexd72VzVbEw/gaN2uPY1Usb0xBHcyMPDYHEvNrqxWuz9I LfWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742218529; x=1742823329; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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=HuUxeFY2TYIMCMb8HQIUf2EEh3PjN1Fnrr3CH/CuE0E=; b=nVucYPCimu0lwiTQok+rvqkcPC802mxorpVp14F/LzrdHkAxYRHWkqscF8CRHJ6QOq sbbAWWd0/sk+dAUl0R7QudAHltLzbGJSMf5Pca/tqyROaR+sUBvq32Y+dZrAlUAcGB1j QVdpPNwYa06c14BJxiUSOhf4rzur1YPfbgzsZK/q1RQrkNegKQE4nrd+hHTW1S/heci+ cAjEmIdE3nraU4wg8yYj0cyCrdf2QYrLx2QVxeexiEaiekEdgsQFOJXoqCiG0x0vBn+n h8WSrTBSxNuLNdSi9r/6tQ+GviEKCVSGnk2ctdduPVuZ3GGaFMBa9gLCREBlDkdrA+kk bWuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742218529; x=1742823329; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=HuUxeFY2TYIMCMb8HQIUf2EEh3PjN1Fnrr3CH/CuE0E=; b=tK1FcZI7LFd6ZN1hlTKhlhRm7Hb6eq9C9el9hPjknBdjgphZGu431ZBLJcq5/L1QHj CKHpNIor5kD+UtGdQFFRA0Sn9bBZejBHF3rkhw+KW0igszwXI6qUxubOHlw8GAUdI1l3 /R3OzIwgXHp3y+Uh5WRTDJ/Zg8b+He82Av4J5VZUKRXN6kLoh73Ookx1OfipZ+uMYvpr ysouy9rzVMA9XPs7Y88m1DP8R40leN+Wo+Bn7bDbeKQNUYxisGZbOlgekWMHD9bT7mGz Ap2g4iaXLSqX0B2xCIncDQbMHZIFWDPpfWbHjKYVmYxv/5Cx7Oq65Ts8FM3ONIvoov7v vBlA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUKSpj5GrfrFkKrIxNApcp8BX65Ezo+s6oxy0go+1P9sxPTJKh79z30mMtaQ2t792kJYVE7czadbSaG@gnusha.org X-Gm-Message-State: AOJu0YyY2a4d67IzVBFMXFf65IKid012Nvmo6UKWBiLbQs9JsGWaTm84 IHBfpYz7rilXp1OFImiiLQsMg9pQV7jDJIASGwX7WaMUycDWT2m3 X-Google-Smtp-Source: AGHT+IGfVhRcTiOcagNnqNgD6nGlXI8Nn8k+BSpq4ihpgegycC6vXB+qx0ls8mVxhqJ+s6HM6W72LQ== X-Received: by 2002:a05:6902:e12:b0:e5d:c1b9:4a7 with SMTP id 3f1490d57ef6-e63e3d27592mr21996753276.23.1742218529120; Mon, 17 Mar 2025 06:35:29 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJRS4v3Y6qZFoiYwcujROfCIzLg8wzfYcwWfGxamDAv0A== Received: by 2002:a25:3d84:0:b0:e60:8883:5aa4 with SMTP id 3f1490d57ef6-e63dc2be29bls409260276.2.-pod-prod-03-us; Mon, 17 Mar 2025 06:35:25 -0700 (PDT) X-Received: by 2002:a05:690c:700d:b0:6fe:bff2:3a6d with SMTP id 00721157ae682-6ff45f1564dmr162998417b3.1.1742218525531; Mon, 17 Mar 2025 06:35:25 -0700 (PDT) Received: by 2002:a05:690c:3388:b0:6ef:590d:3213 with SMTP id 00721157ae682-6fda287d366ms7b3; Mon, 10 Mar 2025 18:06:42 -0700 (PDT) X-Received: by 2002:a05:690c:3806:b0:6f9:7a3c:1fe with SMTP id 00721157ae682-6ff0925ecb0mr27588317b3.23.1741655200953; Mon, 10 Mar 2025 18:06:40 -0700 (PDT) Date: Mon, 10 Mar 2025 18:06:40 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <5610731e-b4a3-448d-bf4b-508739d51198n@googlegroups.com> In-Reply-To: <45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n@googlegroups.com> References: <45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n@googlegroups.com> Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11544_460570634.1741655200612" X-Original-Sender: antoine.riard@gmail.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 (/) ------=_Part_11544_460570634.1741655200612 Content-Type: multipart/alternative; boundary="----=_Part_11545_1992028623.1741655200612" ------=_Part_11545_1992028623.1741655200612 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi James, > As with everything in bitcoin, the chain is insulated from stupidity like= =20 that > by fees, the UTXO model, and block cadence, so what's the problem? See my novel answer to AJ that by extending bitcoin script, I think you=20 might *actually* diluting the UTXO model as you can now on cross-inspect the status of an=20 outpoint. This might amplify tx-withhold style risk for bitcoin contracting=20 protocols, e.g vaults. > Probably worth noting that CSFS and many advanced introspection opcodes= =20 (which allow synthesizing > CTV) have been live for almost *four years now* on Liquid=20 (https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opco= des.md#new-opcodes-for-additional-functionality). Live !=3D Deployed use-cases built on top of those advanced introspection= =20 opcodes. I've not verified this by myself, though from what is available from public= =20 data L-BTC is <=3D to LN today in terms of locked coins. In terms of=20 decentralization, a federated side-chain is not even like a network of payment channels, wher= e everyone can join by confirming a 2-of-2 in the chain. So have skilled dev= =20 really try do "wrong things" with L-BTC and all those shiny introspection opcodes= =20 ? I'm not sure, and please accept my skepticism here. > Sorry to tell you, but given that changing consensus requires soliciting= =20 buy-in from a > wide variety of people across the Bitcoin ecosystem with varying levels= =20 of technical > ability, it is inherently a political process. No -- Apologies to tell you that science / engineering !=3D politics. Somehow, if one has taste and familiarity with all postmodernism sociology, there is well one domain where it completely failed to demonstrate that=20 things are following a "political process", this is indeed the domain of science.= =20 In science, mathematical or physical truth always prevails, no matter what. Don't get me wrong -- This doesn't mean I cannot share the opinion that=20 current consensus changes process is a complete conoundrum. Sadly it might have=20 devolved in the view of numerous segments of the Bitcoin ecosystem that what matters= =20 w.r.t consensus build-up is who is sitting on a bunch of surreanous github=20 repository permissions, and not necessarily if the consensus change is benefitful in a= n objective fashion for bitcoin, not even if such _consensus change_ might be required for the long-term flourishing of bitcoin (at least fixing the=20 technical debt). There is difference in saying what makes you socially popular to be vetted= =20 with empty github permissions and let you vegetate on them by a weak social=20 consensus and there is a difference in saying unpopular truth to nurture real changes= =20 on the long-term. I won't open the conversation more on that subject. Now, back to the more technical analysis of covenant, personally my positio= n is still the same than it was discussed on Bitcoin Core #28550. The=20 communication tone was rude, for sure, though I still share the same belief we shouldn't= =20 be careful in designing contracting primitives and be completely $YOLO if said primitives works well for a second-layer. On concerning CheckTemplateVerify itself, which is itself simpler than any other proposed soft-forks due to the non-malleable templating, as I said 18 months ago I'm still open in my free time to review/test a CTV-based vault (https://github.com/jamesob/simple-ctv-vault), the same way I did for=20 Eltoo-based LN channels in the past. This is one thing to come with a proof-of-concept working on a single workstation, this is another thing to have tested it under real operational guidelines, where dynamic fees and keys ceremonies have to be deal with. I don't think CTV is altering the UTXO model significantly, though pleasure to be proven wrong here. On the other hand CTV is bringing this idea of immutability in a chain of transactions, that we cannot do currently with sigs-based covenant. That immutability in theory has consequential value for anyone building cold wallet or vault, that is clear as once the funding utxo is confirmed, the UTXO signing keys leaks are void. Now, I might be the last guy in the ecosystem to think that CTV is not the promised silver-bullet by its author all over the world to design and deploy vaults. Fine. > Beyond that, "Overton window" is an appropriate device in the sense that= =20 roasbeef > is using it because the more substantial a proposed change is, the more= =20 time is > needed by the technical ecosystem to digest it, both in terms of tooling= =20 and safety > analysis. Introducing an entirely new script interpreter on the basis of= =20 a Lisp (or > combinator calculus, or whatever Simplicity's claim is) is indeed far=20 outside of > that "Overton" window - much farther than tacking on what is essentially= =20 just a > new SIGHASH mode to the existing interpreter. I do not wish to be overly pessimitic, though I think whatever=20 "just-drop-a-new script-interpreter" approach is just the wrong design approach, if we do=20 not go to fix first all the dynamic fees issues grieving all the contracting=20 protocols and bitcoin second-layers. Side-note: if you're used with playing with your compiler to target exotic ISAs, one could build the equivalent for any Lisp interpreter where there i= s an IR and in function of the target you compile to current supported bitcoi= n opcodes, disabling interpreter syntax that are not (currently) supported or that cannot be translated. I think this would be already a formal=20 verification gain for any smart-contract toolchain using it, even if it's a subset. > Let's not be petty here - it's clear he's talking about LoC within the=20 script >interpreter, which is a different context than the codebase as a whole.=20 Within > the context of the interpreter, LoC is indeed a decent heuristic for=20 marginal risk. Of course, nobody's saying it's perfect. I agree that LoC is a decent heuristic for marginal risk. Best, Antoine OTS hash: 7f00760799b4defd9fe551673a7926c01704274e522d44f3dc8e701b320243de Le samedi 8 mars 2025 =C3=A0 16:39:34 UTC, James O'Beirne a =C3=A9crit : > On Friday, March 7, 2025 at 4:26:36=E2=80=AFPM UTC-5 Anthony Towns wrote: > > If you instead did not delete the CSFS private key would allow you to=20 > swap in another hash H or signature S in future. That would perhaps=20 > allow designing an unbounded state machine where a master key can add=20 > new states in future. > > > I'm not sure what your point here is - that we can do stupid things with= =20 > CTV + CSFS? That's universally true in bitcoin; I can have an "unbounded= =20 > state machine" by sending myself the same UTXO back and forth indefinitel= y=20 > with CHECKSIG. > > As with everything in bitcoin, the chain is insulated from stupidity like= =20 > that by fees, the UTXO model, and block cadence, so what's the problem? > =20 > > https://github.com/ElementsProject/elements/pull/1427 suggests=20 > Simplicity's potentially going live on Liquid any day now. > > > Probably worth noting that CSFS and many advanced introspection opcodes= =20 > (which allow synthesizing CTV) have been live for almost *four years now*= =20 > on Liquid ( > https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opc= odes.md#new-opcodes-for-additional-functionality > ). > =20 > > The concept of an "Overton window" is a political one, used for when=20 > there has been successful political pressure to exclude some subjects=20 > from discussion for reasons other than their underlying merits. That's=20 > not a good idea if you want to maintain high quality, and it's probably= =20 > not compatible at all with a project that aims to be decentralised in=20 > any meaningful way. > > > Sorry to tell you, but given that changing consensus requires soliciting= =20 > buy-in from a wide variety of people across the Bitcoin ecosystem with=20 > varying levels of technical ability, it is inherently a political process= . > > Beyond that, "Overton window" is an appropriate device in the sense that= =20 > roasbeef is using it because the more substantial a proposed change is, t= he=20 > more time is needed by the technical ecosystem to digest it, both in term= s=20 > of tooling and safety analysis. Introducing an entirely new script=20 > interpreter on the basis of a Lisp (or combinator calculus, or whatever= =20 > Simplicity's claim is) is indeed far outside of that "Overton" window -= =20 > much farther than tacking on what is essentially just a new SIGHASH mode = to=20 > the existing interpreter. > =20 > > Certainly a small change (though LoC is a bad measure of that -- how=20 > many LoC does it take to drop the 21M limit, or to drop the subsidy from= =20 > 3.125 BTC to 0 BTC?) is better than a large change all else being equal;= =20 > but all else isn't equal: different changes enable different feature=20 > sets. The question you should be asking is whether we're getting useful= =20 > feature sets from the small changes being proposed. > > > Let's not be petty here - it's clear he's talking about LoC within the=20 > script interpreter, which is a different context than the codebase as a= =20 > whole. Within the context of the interpreter, LoC is indeed a decent=20 > heuristic for marginal risk. Of course, nobody's saying it's perfect. > > James > --=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/= 5610731e-b4a3-448d-bf4b-508739d51198n%40googlegroups.com. ------=_Part_11545_1992028623.1741655200612 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi James,

> As with everything in bitcoin, the chain is insul= ated from stupidity like that
> by fees, the UTXO model, and block = cadence, so what's the problem?

See my novel answer to AJ that b= y extending bitcoin script, I think you might *actually*
diluting the = UTXO model as you can now on cross-inspect the status of an outpoint.
= This might amplify tx-withhold style risk for bitcoin contracting protocols= , e.g vaults.

> Probably worth noting that CSFS and many adva= nced introspection opcodes (which allow synthesizing
> CTV) have be= en live for almost *four years now* on Liquid (https://github.com/ElementsP= roject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additi= onal-functionality).

Live !=3D Deployed use-cases built on top o= f those advanced introspection opcodes.

I've not verified this b= y myself, though from what is available from public data
L-BTC is <= =3D to LN today in terms of locked coins. In terms of decentralization,
a federated side-chain is not even like a network of payment channels, wh= ere
everyone can join by confirming a 2-of-2 in the chain. So have ski= lled dev really
try do "wrong things" with L-BTC and all those shiny i= ntrospection opcodes ? I'm
not sure, and please accept my skepticism h= ere.

> Sorry to tell you, but given that changing consensus r= equires soliciting buy-in from a
> wide variety of people across th= e Bitcoin ecosystem with varying levels of technical
> ability, it = is inherently a political process.

No -- Apologies to tell you t= hat science / engineering !=3D politics.

Somehow, if one has tas= te and familiarity with all postmodernism sociology,
there is well one= domain where it completely failed to demonstrate that things
are foll= owing a "political process", this is indeed the domain of science. In
= science, mathematical or physical truth always prevails, no matter what.
Don't get me wrong -- This doesn't mean I cannot share the opinion= that current
consensus changes process is a complete conoundrum. Sadl= y it might have devolved
in the view of numerous segments of the Bitco= in ecosystem that what matters w.r.t
consensus build-up is who is sitt= ing on a bunch of surreanous github repository
permissions, and not ne= cessarily if the consensus change is benefitful in an
objective fashio= n for bitcoin, not even if such _consensus change_ might be
required f= or the long-term flourishing of bitcoin (at least fixing the technical
debt).

There is difference in saying what makes you socially po= pular to be vetted with
empty github permissions and let you vegetate = on them by a weak social consensus
and there is a difference in saying= unpopular truth to nurture real changes on
the long-term. I won't ope= n the conversation more on that subject.

Now, back to the more t= echnical analysis of covenant, personally my position
is still the sam= e than it was discussed on Bitcoin Core #28550. The communication
tone= was rude, for sure, though I still share the same belief we shouldn't becareful in designing contracting primitives and be completely $YOLO if = said
primitives works well for a second-layer.

On concernin= g CheckTemplateVerify itself, which is itself simpler than any
other p= roposed soft-forks due to the non-malleable templating, as I said 18
m= onths ago I'm still open in my free time to review/test a CTV-based vault(https://github.com/jamesob/simple-ctv-vault), the same way I did for E= ltoo-based
LN channels in the past. This is one thing to come with a p= roof-of-concept
working on a single workstation, this is another thing= to have tested it
under real operational guidelines, where dynamic fe= es and keys ceremonies
have to be deal with.

I don't think = CTV is altering the UTXO model significantly, though pleasure
to be pr= oven wrong here. On the other hand CTV is bringing this idea of
immuta= bility in a chain of transactions, that we cannot do currently with
si= gs-based covenant. That immutability in theory has consequential value
for anyone building cold wallet or vault, that is clear as once the fundin= g
utxo is confirmed, the UTXO signing keys leaks are void.

= Now, I might be the last guy in the ecosystem to think that CTV is not
the promised silver-bullet by its author all over the world to design
and deploy vaults. Fine.

> Beyond that, "Overton window" is = an appropriate device in the sense that roasbeef
> is using it beca= use the more substantial a proposed change is, the more time is
> n= eeded by the technical ecosystem to digest it, both in terms of tooling and= safety
> analysis. Introducing an entirely new script interpreter = on the basis of a Lisp (or
> combinator calculus, or whatever Simpl= icity's claim is) is indeed far outside of
> that "Overton" window = - much farther than tacking on what is essentially just a
> new SIG= HASH mode to the existing interpreter.

I do not wish to be overl= y pessimitic, though I think whatever "just-drop-a-new
script-interpre= ter" approach is just the wrong design approach, if we do not go
to fi= x first all the dynamic fees issues grieving all the contracting protocols<= br />and bitcoin second-layers.

Side-note: if you're used with p= laying with your compiler to target exotic
ISAs, one could build the e= quivalent for any Lisp interpreter where there is
an IR and in functio= n of the target you compile to current supported bitcoin
opcodes, disa= bling interpreter syntax that are not (currently) supported or
that ca= nnot be translated. I think this would be already a formal verification
gain for any smart-contract toolchain using it, even if it's a subset.
> Let's not be petty here - it's clear he's talking about LoC w= ithin the script
>interpreter, which is a different context than th= e codebase as a whole. Within
> the context of the interpreter, LoC= is indeed a decent heuristic for marginal risk. Of course, nobody's saying= it's perfect.

I agree that LoC is a decent heuristic for margin= al risk.

Best,
Antoine
OTS hash: 7f00760799b4defd9fe55= 1673a7926c01704274e522d44f3dc8e701b320243de
Le samedi 8 mars 2025 =C3=A0 16:39:= 34 UTC, James O'Beirne a =C3=A9crit=C2=A0:
On Friday, March = 7, 2025 at 4:26:36=E2=80=AFPM UTC-5 Anthony Towns wrote:
If you instead did not delete the CSFS private key would all= ow you to
swap in another hash H or signature S in future. That would perhaps
allow designing an unbounded state machine where a master key can add
new states in future.

I'= m not sure what your point here is - that we can do stupid things with CTV = + CSFS? That's universally true in bitcoin; I can have an "unbound= ed state machine" by sending myself the same UTXO back and forth indef= initely with CHECKSIG.

As with everything in bitco= in, the chain is insulated from stupidity like that by fees, the UTXO model= , and block cadence, so what's the problem?
=C2=A0=
https://github.com/ElementsProjec= t/elements/pull/1427 suggests
Simplicity's potentially going live on Liquid any day now.

Probably worth noting that CSFS and = many advanced introspection opcodes (which allow synthesizing CTV) have bee= n live for almost *four years now* on Liquid (https://github.com/ElementsProjec= t/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-= functionality).
=C2=A0
The concept of an "Overton window" is a political one, used= for when
there has been successful political pressure to exclude some subjects
from discussion for reasons other than their underlying merits. That= 9;s
not a good idea if you want to maintain high quality, and it's prob= ably
not compatible at all with a project that aims to be decentralised in
any meaningful way.

Sorry to= tell you, but given that changing consensus requires soliciting buy-in fro= m a wide variety of people across the Bitcoin ecosystem with varying levels= of technical ability, it is inherently a political process.

=
Beyond that, "Overton window" is an appropriate device= in the sense that roasbeef is using it because the more substantial a prop= osed change is, the more time is needed by the technical ecosystem to diges= t it, both in terms of tooling and safety analysis. Introducing an entirely= new=C2=A0script interpreter on the basis of a Lisp (or combinator calculus= , or whatever Simplicity's claim is) is indeed far outside of that &quo= t;Overton" window - much farther than tacking on what is essentially j= ust a new SIGHASH mode to the existing interpreter.
= =C2=A0
Certainly a small change (though Lo= C is a bad measure of that -- how
many LoC does it take to drop the 21M limit, or to drop the subsidy fro= m
3.125 BTC to 0 BTC?) is better than a large change all else being equal= ;
but all else isn't equal: different changes enable different featur= e
sets. The question you should be asking is whether we're getting us= eful
feature sets from the small changes being proposed.
Let's not be petty here - it's clear he'= ;s talking about LoC within the script interpreter, which is a different co= ntext than the codebase as a whole. Within the context of the interpreter, = LoC is indeed a decent heuristic for marginal risk. Of course, nobody's= saying it's perfect.

James

--
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/5610731e-b4a3-448d-bf4b-508739d51198n%40googlegroups.com.
------=_Part_11545_1992028623.1741655200612-- ------=_Part_11544_460570634.1741655200612--