path: root/d6/bc4e47018085072f9daf32def0ba17d040cc69

Delivery-date: Fri, 18 Apr 2025 05:58:09 -0700
Received: from mail-yw1-f186.google.com ([209.85.128.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDRIFMNQZANRBVUYRHAAMGQEEUJMHHI@googlegroups.com>)
	id 1u5lIF-0001BX-V1
	for bitcoindev@gnusha.org; Fri, 18 Apr 2025 05:58:09 -0700
Received: by mail-yw1-f186.google.com with SMTP id 00721157ae682-7075bbaa916sf6533147b3.1
        for <bitcoindev@gnusha.org>; Fri, 18 Apr 2025 05:58:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1744981082; x=1745585882; 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=clS9jaxTSvuwkasTtMe+DMv0V7ALb/2Xje7qQsE7ws8=;
        b=GkMAOtze3WyE+f8kv6QvzHzrgZR2ybd0MBYnWhH1oMPEFRBNM++pCEij7QwK0gNz5s
         ThatGW+u6kYWlf90dYQcRODKQfZqgxDCT0170FnOPofx21Rp5ZbtfUw6cTabw2RyDbl8
         dnjeg44Gckl7T2Lsmr27Nnky2ZE+amlb5dYWPk4Qbgyev/1H7FquPDbMa+jkTcUEdTth
         X2+8jMJVoxXmW0TR6aHy3psiVJ/0Rwnrx0YBm6k/FCgE8sQ9GuPQDCAkpheOmubcrJY+
         KX0u28y/dF6gmMNLQCHsjIfhL4p/aebkt5SdwftoRcSakpAKrhcvDp3bDRjVAtGXDgUg
         2vWA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1744981082; x=1745585882; 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=clS9jaxTSvuwkasTtMe+DMv0V7ALb/2Xje7qQsE7ws8=;
        b=fStXzfFxF1BRqTweTUIuv+gNqzInwstxTNX8Vw7btugat1j9c5iggAjPkBLLOjD8V5
         D5gXftZXt5pTXzBAtK/ZrzRVU+TYT1Ffh/oY/XWDYlEbI0y3XJQsSTXIA0rs+ZMYntyJ
         fhpj1cVU+vEtHG7v+eQhWwHsVYaE7ibz/9P7tcGENhyIxbNEhk40s0vflRKSvcWlw8t8
         Slzh1Z9nIWVf/wbeat1CJIXex/DKcBl8yo8Gj3meG+g2oZHqE61DbKVBNh6UPdgZpKiF
         qTFsmiI7W9eNIueRYbnjoQ7lrax1JS+L3sQkOLMBBt7nhh/jte4z9fubA91oOQqEiALi
         6rqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1744981082; x=1745585882;
        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=clS9jaxTSvuwkasTtMe+DMv0V7ALb/2Xje7qQsE7ws8=;
        b=OdwstaALyP7oKjzMAY2X+DX4WXV0kGvaY4gdNnBfPuYz5T+riWXXPYVxJ+R9LJVDSG
         5n5xCwlEyyRYxhZhNucMWW/1NbrNJdkigxbHjbbsTzj6yjWD2RLQflcEO1SbSmYH2ZqG
         qcO2mFXgaXmp5HzB5PetS029qmAVsHD2cHlTNLn2z/Uguf6zszqxtz+vuNmcVNitZtzs
         eVjzP6XHIlvwldqHvw/5+zhia6kTPTfkAQ3/rsm4uCYBCVEDGIKnkkqj//Rklsxgc/Vv
         aeB0YppPiSBaejg05Z8hKCWVapDWIsJYIyzH2YZ/xi+0Zs4y/WV4e28BOw8yRaD051TC
         5onw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUqEamTD2ASA9xB36EZUv8vG0z4LfUke7tc0zBwIHhE/ejO5m2yQtR/O1d2uYEmonm9ZZo4Qb+/X4sF@gnusha.org
X-Gm-Message-State: AOJu0YyKc2rJSKxph5Y9s7eY9KMpM1d2CjTfrEDAYkT2t38gz4aHQb6d
	ZJdT81dI+5DsnXCxW7UyId1XinLGubkos2vto3dhs5PvbaE+8tCm
X-Google-Smtp-Source: AGHT+IF21SCBsI+USW9D/R0IRGxqL3DiLNudYClLxr8n9yYEjUKBfEUYpLLd75XKaMD3NuYriNkC2g==
X-Received: by 2002:a05:6902:992:b0:e6d:fb0f:fcbf with SMTP id 3f1490d57ef6-e7297e64d5emr3287989276.39.1744981081755;
        Fri, 18 Apr 2025 05:58:01 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPALOmI1B7dHyHAYguIy1HdbAdUYr5YAWvi25Na5BvtI5dQ==
Received: by 2002:a25:6c87:0:b0:e6d:f2c2:ec75 with SMTP id 3f1490d57ef6-e72804b4d20ls1148059276.1.-pod-prod-07-us;
 Fri, 18 Apr 2025 05:57:58 -0700 (PDT)
X-Received: by 2002:a05:690c:3613:b0:6f4:8207:c68d with SMTP id 00721157ae682-706ccc8e812mr35111427b3.3.1744981077997;
        Fri, 18 Apr 2025 05:57:57 -0700 (PDT)
Received: by 2002:a05:690c:6e82:b0:6ef:590d:3213 with SMTP id 00721157ae682-706cad98cfbms7b3;
        Fri, 18 Apr 2025 05:54:49 -0700 (PDT)
X-Received: by 2002:a05:690c:9c01:b0:6ef:7f89:d906 with SMTP id 00721157ae682-706cce06c78mr33197257b3.33.1744980888727;
        Fri, 18 Apr 2025 05:54:48 -0700 (PDT)
Date: Fri, 18 Apr 2025 05:54:48 -0700 (PDT)
From: Greg Sanders <gsanders87@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <b51b952c-b8ba-4f13-a216-c29095c39d00n@googlegroups.com>
In-Reply-To: <C7E2D805-E70A-455C-BDA1-224024BE93B3@sprovoost.nl>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <C7E2D805-E70A-455C-BDA1-224024BE93B3@sprovoost.nl>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_76168_520530924.1744980888418"
X-Original-Sender: gsanders87@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_76168_520530924.1744980888418
Content-Type: multipart/alternative; 
	boundary="----=_Part_76169_47774300.1744980888418"

------=_Part_76169_47774300.1744980888418
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> From perusing the Citrea paper (page 18) it seems a single output is=20
enough, and they only need 144 bytes.

From discussion in person it seems as though they could adapt their use to=
=20
batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with=
=20
each output being a 144-byte OP_RETURN. It's a less pressing issue perhaps,=
=20
but if we can derive additional efficiency and don't want to revisit this=
=20
conversation again later, may be worth doing.

The only drawback I can see to the second step would be that we *could=20
have* reserved multi-output as some sort of signaling mechanism since it's=
=20
previously not relayable on Bitcoin Core, even with knob fiddling, though I=
=20
can't imagine what that would be. Additional OP_RETURNs would be an=20
expensive signal.

Greg

On Friday, April 18, 2025 at 8:16:00=E2=80=AFAM UTC-4 Sjors Provoost wrote:

>
> > Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Developmen=
t=20
> Mailing List <bitco...@googlegroups.com> het volgende geschreven:
>
> > Developers are now designing constructions that work around these=20
> limitations. An example is Clementine, the recently-announced Citrea=20
> bridge, which uses unspendable Taproot outputs to store data in its=20
> "WatchtowerChallenge" transaction due to the standardness restrictions on=
=20
> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years=
=20
> that the nudge is ineffective to deter storing data onchain.
> >=20
> > Since the restrictions on the usage of OP_RETURN outputs encourage=20
> harmful practices while being ineffective in deterring unwanted usage, i=
=20
> propose to drop them. I suggest to start by lifting the restriction on th=
e=20
> size of the scriptPubKey for OP_RETURN outputs, as a first minimal step t=
o=20
> stop encouraging harmful behaviour, and to then proceed to lift the=20
> restriction on the number of OP_RETURN outputs per transactions.
>
> It might be better to do both, if only to avoid repeating the discussion=
=20
> in a year.
>
> From perusing the Citrea paper (page 18) it seems a single output is=20
> enough, and they only need 144 bytes.
>
> 1. Regarding size
>
> The current ~80 byte limit was based on Counterparty needing it [0], and=
=20
> otherwise using bare multisig. A similar argument would apply here. At th=
e=20
> time there was discussion about how much space Counterparty really needed=
=20
> if their protocol was well implemented.
>
> The 144 bytes consist of a Groth16 proof and the total chain work. Along=
=20
> similar lines we could pick a number based on various cryptographic=20
> commitment schemes, and then only raise the limit by that much.
>
> But that just guarantees repeating the argument in a year when some=20
> protocol needs a slightly higher limit. In a post-inscription world that=
=20
> seems pointless. My preference is to drop the size limit entirely.
>
> 2. Regarding count
>
> IIUC there's no consensus limit on the size of an OP_RETURN [1] and=20
> there's also no standardness rule on the size of a scriptPubKey. The size=
=20
> of a single OP_RETURN is limited only by the maximum transaction size, i.=
e.=20
> 100 kvB.
>
> Without a size restriction on individual OP_RETURN outputs, there's no=20
> point in limiting their number.
>
> That said, it would be interesting to know if any protocols are thinking=
=20
> of using multiple OP_RETURN outputs.
>
> 3. Reminder why we didn't do this earlier
>
> In the August 2023 discussion [2] Murch wrote, in response to John Light:
>
> >> is there ever a case where using OP_RETURN to embed data actually=20
> results in fewer bytes onchain than embedding the same data using the=20
> segwit/taproot witness space
> >=20
> > Yes, a back-of-the-envelope calculation has me thinking that only=20
> payloads of 135 bytes would be cheaper with transcriptions than with=20
> nulldata outputs. In detail:
> [...]
> > we learn that nulldata outputs are cheaper up to a payload size of 134=
=20
> bytes, only above that inscriptions become a more blockspace efficient da=
ta=20
> carrier.
>
> Since we're discussing raising the limit to at least 144 bytes, the above=
=20
> argument would no longer be relevant.
>
> And from what I recall at the time that was the only remaining reason to=
=20
> keep the OP_RETURN restrictions around a bit longer, despite heavy use of=
=20
> inscriptions.
>
> 4. PS - on liveliness assumptions
>
> The paper [3] states the following assumption:
>
> > We consider a secure ledger, i.e., a ledger that is safe and live.=20
> Safety and liveness are defined as follows:
> >=20
> > ...
> >=20
> > Definition 2 (Liveness). A distributed ledger protocol is live with=20
> liveness parameter u if all transactions written by any correct party at=
=20
> round r, appear in the ledgers of all correct parties by round r + u.
>
> For standard transactions this already not trivially true. See all of=20
> Lightning pinning discussions.
>
> For non-standard transactions, does BitVM2 keep all its transactions unde=
r=20
> 100 kvB?
>
> Otherwise your liveness assumption requires a direct connection to at=20
> least one miner / pool that is trusted to not censor (though you can shop=
=20
> around until the deadline).
>
> Conversely, having actively used protocols that frequently require going=
=20
> over some standardises limit puts pressure on that limit for the reasons=
=20
> Antoine outlined. So for anyone working on such protocols, please let thi=
s=20
> list know, since these discussions can take a while.
>
> - Sjors
>
> [0]=20
> https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_count=
erparty_developers/?rdt=3D53592
> [1] https://bitcoin.stackexchange.com/a/117595/4948
> [2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t=
=20
> <https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@mu=
rch.one/#t>=20
> (click on the html attachment)
> [3] https://citrea.xyz/clementine_whitepaper.pdf

--=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/=
b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com.

------=_Part_76169_47774300.1744980888418
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

&gt; From perusing the Citrea paper (page 18) it seems a single output is e=
nough, and they only need 144 bytes.<div><br /></div><div>From discussion i=
n person it seems as though they could adapt their use to batch publish the=
se transactions as SIGHASH_SINGLE|ACP transactions, with each output being =
a 144-byte OP_RETURN. It's a less pressing issue perhaps, but if we can der=
ive additional efficiency and don't want to revisit this conversation again=
 later, may be worth doing.</div><div><br /></div><div>The only drawback I =
can see to the second step would be that we *could have* reserved multi-out=
put as some sort of signaling mechanism since it's previously not relayable=
 on Bitcoin Core, even with knob fiddling, though I can't imagine what that=
 would be. Additional OP_RETURNs would be an expensive signal.</div><div><b=
r /></div><div>Greg<br /><br /></div><div class=3D"gmail_quote"><div dir=3D=
"auto" class=3D"gmail_attr">On Friday, April 18, 2025 at 8:16:00=E2=80=AFAM=
 UTC-4 Sjors Provoost wrote:<br/></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padd=
ing-left: 1ex;">
<br>&gt; Op 17 apr 2025, om 20:52 heeft &#39;Antoine Poinsot&#39; via Bitco=
in Development Mailing List &lt;<a href data-email-masked rel=3D"nofollow">=
bitco...@googlegroups.com</a>&gt; het volgende geschreven:
<br>
<br>&gt; Developers are now designing constructions that work around these =
limitations. An example is Clementine, the recently-announced Citrea bridge=
, which uses unspendable Taproot outputs to store data in its &quot;Watchto=
werChallenge&quot; transaction due to the standardness restrictions on the =
size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that t=
he nudge is ineffective to deter storing data onchain.
<br>&gt;=20
<br>&gt; Since the restrictions on the usage of OP_RETURN outputs encourage=
 harmful practices while being ineffective in deterring unwanted usage, i p=
ropose to drop them. I suggest to start by lifting the restriction on the s=
ize of the scriptPubKey for OP_RETURN outputs, as a first minimal step to s=
top encouraging harmful behaviour, and to then proceed to lift the restrict=
ion on the number of OP_RETURN outputs per transactions.
<br>
<br>It might be better to do both, if only to avoid repeating the discussio=
n in a year.
<br>
<br>From perusing the Citrea paper (page 18) it seems a single output is en=
ough, and they only need 144 bytes.
<br>
<br>1. Regarding size
<br>
<br>The current ~80 byte limit was based on Counterparty needing it [0], an=
d otherwise using bare multisig. A similar argument would apply here. At th=
e time there was discussion about how much space Counterparty really needed=
 if their protocol was well implemented.
<br>
<br>The 144 bytes consist of a Groth16 proof and the total chain work. Alon=
g similar lines we could pick a number based on various cryptographic commi=
tment schemes, and then only raise the limit by that much.
<br>
<br>But that just guarantees repeating the argument in a year when some pro=
tocol needs a slightly higher limit. In a post-inscription world that seems=
 pointless. My preference is to drop the size limit entirely.
<br>
<br>2. Regarding count
<br>
<br>IIUC there&#39;s no consensus limit on the size of an OP_RETURN [1] and=
 there&#39;s also no standardness rule on the size of a scriptPubKey. The s=
ize of a single OP_RETURN is limited only by the maximum transaction size, =
i.e. 100 kvB.
<br>
<br>Without a size restriction on individual OP_RETURN outputs, there&#39;s=
 no point in limiting their number.
<br>
<br>That said, it would be interesting to know if any protocols are thinkin=
g of using multiple OP_RETURN outputs.
<br>
<br>3. Reminder why we didn&#39;t do this earlier
<br>
<br>In the August 2023 discussion [2] Murch wrote, in response to John Ligh=
t:
<br>
<br>&gt;&gt; is there ever a case where using OP_RETURN to embed data actua=
lly results in fewer bytes onchain than embedding the same data using the s=
egwit/taproot witness space
<br>&gt;=20
<br>&gt; Yes, a back-of-the-envelope calculation has me thinking that only =
payloads of 135 bytes would be cheaper with transcriptions than with nullda=
ta outputs. In detail:
<br>[...]
<br>&gt; we learn that nulldata outputs are cheaper up to a payload size of=
 134 bytes, only above that inscriptions become a more blockspace efficient=
 data carrier.
<br>
<br>Since we&#39;re discussing raising the limit to at least 144 bytes, the=
 above argument would no longer be relevant.
<br>
<br>And from what I recall at the time that was the only remaining reason t=
o keep the OP_RETURN restrictions around a bit longer, despite heavy use of=
 inscriptions.
<br>
<br>4. PS - on liveliness assumptions
<br>
<br>The paper [3] states the following assumption:
<br>
<br>&gt; We consider a secure ledger, i.e., a ledger that is safe and live.=
 Safety and liveness are defined as follows:
<br>&gt;=20
<br>&gt; ...
<br>&gt;=20
<br>&gt; Definition 2 (Liveness). A distributed ledger protocol is live wit=
h liveness parameter u if all transactions written by any correct party at =
round r, appear in the ledgers of all correct parties by round r + u.
<br>
<br>For standard transactions this already not trivially true. See all of L=
ightning pinning discussions.
<br>
<br>For non-standard transactions, does BitVM2 keep all its transactions un=
der 100 kvB?
<br>
<br>Otherwise your liveness assumption requires a direct connection to at l=
east one miner / pool that is trusted to not censor (though you can shop ar=
ound until the deadline).
<br>
<br>Conversely, having actively used protocols that frequently require goin=
g over some standardises limit puts pressure on that limit for the reasons =
Antoine outlined. So for anyone working on such protocols, please let this =
list know, since these discussions can take a while.
<br>
<br>- Sjors
<br>
<br>[0] <a href=3D"https://www.reddit.com/r/btc/comments/80ycim/a_few_month=
s_after_the_counterparty_developers/?rdt=3D53592" target=3D"_blank" rel=3D"=
nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_coun=
terparty_developers/?rdt%3D53592&amp;source=3Dgmail&amp;ust=3D1745067074218=
000&amp;usg=3DAOvVaw0MM9KbUgUA64--SjzlgQr3">https://www.reddit.com/r/btc/co=
mments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=3D53592</=
a>
<br>[1] <a href=3D"https://bitcoin.stackexchange.com/a/117595/4948" target=
=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com=
/url?hl=3Den&amp;q=3Dhttps://bitcoin.stackexchange.com/a/117595/4948&amp;so=
urce=3Dgmail&amp;ust=3D1745067074218000&amp;usg=3DAOvVaw2wTRloeMwvq964Mmuql=
pS9">https://bitcoin.stackexchange.com/a/117595/4948</a>
<br>[2] <a href=3D"https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a=
-8ec671cbb9f3@murch.one/#t" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gnusha.org/p=
i/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/%23t&amp;source=
=3Dgmail&amp;ust=3D1745067074218000&amp;usg=3DAOvVaw1na06VOwQurnkkZIWQep3O"=
>https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t</a> (c=
lick on the html attachment)
<br>[3] <a href=3D"https://citrea.xyz/clementine_whitepaper.pdf" target=3D"=
_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url=
?hl=3Den&amp;q=3Dhttps://citrea.xyz/clementine_whitepaper.pdf&amp;source=3D=
gmail&amp;ust=3D1745067074218000&amp;usg=3DAOvVaw3AsJFVA9H3QVl_yPci8EBx">ht=
tps://citrea.xyz/clementine_whitepaper.pdf</a></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com</a>.<br />

------=_Part_76169_47774300.1744980888418--

------=_Part_76168_520530924.1744980888418--