path: root/c7/b71e1a287e25a483735ec6c46cf4fe5522e860

Delivery-date: Sun, 25 May 2025 08:57:55 -0700
Received: from mail-yw1-f190.google.com ([209.85.128.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDI23FE35EIBB6H3ZTAQMGQEICPANRQ@googlegroups.com>)
	id 1uJDjW-0002oD-0b
	for bitcoindev@gnusha.org; Sun, 25 May 2025 08:57:55 -0700
Received: by mail-yw1-f190.google.com with SMTP id 00721157ae682-708b13627absf23763377b3.2
        for <bitcoindev@gnusha.org>; Sun, 25 May 2025 08:57:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1748188668; x=1748793468; 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=VjkoCmRUKQShFm44ZatHlNE3zacidOsAaDwuAAkJKew=;
        b=rYr/J5SGrnpJmkRwgw/3+LT2+DVjZLeqkvccFkVMeJj/C5MkUqwC41V+6NjWbK1ccm
         JuIwe/o31mrN1vUIQQCi2XULkW6hkggfuThzj1TiNkKAVs2Ke6610OI7CdFVZRl+LSkK
         +iNgPcDgv9L3RcTL34+pFvhKRlYLOeTdCvEKK7j1sucx6B5nzdGAcC96QLlCREND5p9N
         Bhaa+B8b59g7yeH3dNgBAqsFAfqSipxlEHgGPeRmw2G+OCKUCzYOf4rY+uqFu0zzYvZt
         e8hKsjuotnf4D151o06pqZVsBsl+iBeu6epeGS6lX5g4e5cvbn0qAzFark5irBNOpfj1
         LG8w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748188668; x=1748793468; 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=VjkoCmRUKQShFm44ZatHlNE3zacidOsAaDwuAAkJKew=;
        b=Kd2i0NTuoFBzesauqKme4ya47JS8EUqUwNZT5ep7CY/ZzcKUL5tEo0hHf4PqHLmkBA
         tHuJQffb+UzZeTXhYZQBCQR3LQOOezyIngA27yhbnLMfkUEuSw7DH0cfTHTkbZjCXIeO
         SGDnyq0czk9160fV7Zf/bM7KrPbejJKIxTLKc1Wbm9ju3ZQ+jcrRQ1NUDHwCLIPHlagN
         JeovfL4MUrRKrD0chPtr8/LLZ7UP7G9H0NYdz5T7YHgUECMt0MMlqEQ1hzMJU5EaQGMc
         36+yLjj0ZcdOFvssZCCl4wVL5yPCVrdiFk8bPrrqO/iKRyWMEOxyib9PvWFKXc4LoYzt
         RDTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748188668; x=1748793468;
        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=VjkoCmRUKQShFm44ZatHlNE3zacidOsAaDwuAAkJKew=;
        b=QDhgMVI9Ll5il2GjQwdfFrLyIqmLkY6H+DDzoJjpL+YU4wil7pEHQuDwky7nwJ0Vo3
         pwCFsYcD9URMJMA+d4SrII14TaZwC1cJzpgx3dYrI6puFaaKwLwLZcmCudWmNf5B2HAZ
         Fm7LvSaxKj2Sm8fxv/3uJ+u0VBlH3b6o7/u/2LwMK0mbvP2gj24lJfynx1Jv5zq+UbQc
         T1mLAX/cTGMGGrjS0/38viqSedbBGhpfVfg/mWPz/elVxzLg4ZPICnm8xVrtZTOMXSBY
         mr7udqvsaclg/1RvR1ausSo94eoQlLAOB+8n3r9WSOwtp4Djcm42c4z5JzA7jV3VvENB
         ClxA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWA6d9TAVOlfkXmw/bzr9Ei5aEuvAqMF7bG83vRpht8QBlMSu2xZiaG90vEsXED2xmsZ1QrXy0spA1Z@gnusha.org
X-Gm-Message-State: AOJu0YwsU25IA9mlad8SLRSdVg+8J8mIcaNhk7PN7/EmThOxq0J11EvP
	Au6c3l1deiS2bW2/R5U9hpqQFmBGkIf1FXgehYc8Bec+7Ecjo0/nHdEm
X-Google-Smtp-Source: AGHT+IERCQ8DS8CSfa3S3TymNCqw0r4hEJAhdNKIuzurqVYR+EnV/5o+EeoAGgqfvmnja5SC8C4gDw==
X-Received: by 2002:a05:6902:c10:b0:e7d:6a8e:dc5a with SMTP id 3f1490d57ef6-e7d91d60db0mr5640875276.36.1748188668107;
        Sun, 25 May 2025 08:57:48 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFUB5TClt0RXVz/AwAJ0SUjsL63sJzv/oyPlEujD6304A==
Received: by 2002:a25:dc81:0:b0:e7d:804c:d381 with SMTP id 3f1490d57ef6-e7d92192110ls1322013276.2.-pod-prod-00-us;
 Sun, 25 May 2025 08:57:44 -0700 (PDT)
X-Received: by 2002:a05:690c:6210:b0:70d:8e1f:ec2b with SMTP id 00721157ae682-70e18510e19mr111313607b3.6.1748188663931;
        Sun, 25 May 2025 08:57:43 -0700 (PDT)
Received: by 2002:a0d:de45:0:b0:70e:3f3a:2c12 with SMTP id 00721157ae682-70e3f3a344dms7b3;
        Sun, 25 May 2025 08:53:27 -0700 (PDT)
X-Received: by 2002:a05:690c:45c5:b0:70c:9a57:699e with SMTP id 00721157ae682-70e18524589mr113212717b3.7.1748188406576;
        Sun, 25 May 2025 08:53:26 -0700 (PDT)
Date: Sun, 25 May 2025 08:53:26 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <bd2c8cd1-69bc-4ffc-9ff4-fa12e929c2afn@googlegroups.com>
In-Reply-To: <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
 <aBUlEOBqqrOIGHWC@petertodd.org>
 <16f3af30-985f-40b7-afc3-9faae892d824n@googlegroups.com>
Subject: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_29330_1618525221.1748188406236"
X-Original-Sender: ekaggata@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_29330_1618525221.1748188406236
Content-Type: multipart/alternative; 
	boundary="----=_Part_29331_1777088072.1748188406236"

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

Hi Greg, list,

re:

> A point of clarification,  that's really a scheme to keep arbitrary data=
=20
out of unprunable data.  The proofs that the values in question are what=20
they're supposed to be are themselves arbitrary data channels.  But these=
=20
proofs are prunable.

Could you expand on the "arbitrary data channels" here?

I was thinking through specifically the case of (pre-taproot) raw pubkey=20
outputs and thinking about what it would mean to prove that it's not data;=
=20
here, the obvious approach is "ECDSA-sign using the key" which trivially=20
fails to prove it's not data if the message for the signature is=20
unconstrained. But obviously, it would be constrained to be e.g. the hash=
=20
of the pubkey, fixing it and preventing data storage in the (s) component=
=20
of ECDSA's (r, s). (i.e. if you wanted to bypass this scheme to still store=
=20
32 bytes of data, you'd just choose s as that data and then use the=20
standard pubkey recovery algorithm; except you can't if P is in the=20
message).

All of that seems spectacularly irrelevant, not only because trivially you=
=20
avoid it with using Hash(P) in the sig message, but even more, since this=
=20
would be a new piece of consensus, you could just use BIP340 or any similar=
=20
Schnorr with key-prefixing anyway, no matter what style of scriptPubKey is=
=20
involved.

The question is, what is the arbitrary data channel that you refer to, that=
=20
remains, when doing this? The R-value is ofc arbitrary but it's still a=20
"image" not "preimage" (x-coord for the nonce secret * G). As I write this,=
=20
one answer occurs to me, that if you used the same R value twice you leak=
=20
the nonce and the secret key, which in this weird setup means you are=20
"broadcasting" 2 32 byte values that are random, in 2 outputs, which I=20
guess is the same embedding ratio? A horrible idea in practice given you=20
lose control of the outputs; I know that at least some schemes that embed=
=20
data in utxos deliberately do so to keep them in the utxo set permanently.=
=20
So I somehow feel that that's not what you meant ...

Cheers,
AdamISZ/waxwing

On Friday, May 2, 2025 at 9:00:25=E2=80=AFPM UTC-3 Greg Maxwell wrote:

> On Friday, May 2, 2025 at 10:23:45=E2=80=AFPM UTC Peter Todd wrote:
>
> # _Uninterrupted_ Illicit Data=20
>
>
> To refine that, _illicit data_ is a problem and encryption at rest does=
=20
> not address particularly in so far as possession of some data is a strict=
=20
> liability crime.
>
> Uninterrupted however means that it's more likely to get caught by random=
=20
> scanning tools and whatnot -- and the encryption does that and probably=
=20
> eliminates most of difference between interrupted and not, which is Peter=
=20
> Todd's point.
>
> But I heard someone last night say that encryption solves the illicit dat=
a=20
> issue and it absolutely doesn't. It solves a particular unexciting but mo=
re=20
> immediate sub part of the problem which is stuff like AV scanners.  But I=
=20
> think that issue is orthogonal to this proposed change.
>
> Aside, I'd been thinking there was a consensus limit on output sizes of=
=20
> 10kb but now I'm remembering that it's just at spend time and so obviousl=
y=20
> wouldn't be relevant here.
> =20
>
> to make data publication somewhat more expensive with consensus changes.=
=20
> Gregory Maxwell outlined how to do so on this mailing list years ago=20
>
>
> A point of clarification,  that's really a scheme to keep arbitrary data=
=20
> out of unprunable data.  The proofs that the values in question are what=
=20
> they're supposed to be are themselves arbitrary data channels.  But these=
=20
> proofs are prunable.
>
> It's true that they they only need to be carried near the tip, so you=20
> could even consider them *super prunable*.   And while perhaps you can ge=
t=20
> many existing transaction patterns into that model, I'm pretty confident=
=20
> you can't eliminate high bandwidth channels in script without massively=
=20
> hobbling Bitcoin overall.  (Though hey, there are a lot of people out the=
re=20
> these days who would like to hobble bitcoin, so ::shrugs::) =20
>
> Even if the functionality reduction were worth it, I dunno that the gain=
=20
> between prunable (where most data storage stuff is) and super-prunable is=
=20
> that interesting, particularly since you're looking at on the order of a=
=20
> 20%-30% increase of bandwidth for transactions and blocks to carry those=
=20
> proofs.  Though for context I then eventually most nodes will sync throug=
h=20
> some kind of utxo fast forward, just due to practical considerations, and=
=20
> w/ that the difference in prunability degree is diminished further.
>
> It might make sense for just *outputs* if data stuffing into the UTXO set=
=20
> continues to be a problem as I think it can be done for just outputs=20
> without huge functionality loss... though even so the disruption and=20
> overheads yuck.  But before even considering such a disruptive change you=
'd=20
> want to be really user everything was done to get the storage out of the=
=20
> unprunable data first, e.g. by getting rid of limits on op_return size.
>
> have an overhead of about 6.6x. Existing data encoders have been happy=20
> to pay even more money than that in terms of increased fees during fee=20
> spikes; the difference in cost between witness space and txout space is=
=20
> already 4x, and some are happy to publish data that way anyway.=20
>
>
> A point I raised on bitcointalk: If you work out how much it costs to=20
> store data on S3 (by far not the cheapest internet data storage) for=20
> *forever* you end up with a rate that is less than a hundred thousandth t=
he=20
> current Bitcoin minimum fee rate-- maybe way less if you also factor in t=
he=20
> cost of storage decreasing, but I didn't.  Data stuffers are not=20
> particularly price sensitive, if they were they wouldn't be using Bitcoin=
=20
> at all.  Schemes to discourage them by causing them increased costs (e.g.=
=20
> by forcing them to encode in ways that use more block capacity) shouldn't=
=20
> be expected to work.
>
> And to the extent that what many of these things have been doing is tryin=
g=20
> to profit off seigniorage-- creating a rare 'asset' to sell to some great=
er=20
> fool and profit off the difference-- further restricting them could=20
> increase their volume because the resource they need has been made more=
=20
> rare.  For the vast majority of users the ire comes about this stuff from=
=20
> the fact that they've driven up fees at times, but that is dependent on=
=20
> what they're willing to spend, which is likely not particularly related t=
o=20
> the marginal data rates. (And one could always embed smaller jpegs,=20
> compress them better, or not use raw json instead of an efficient encodin=
g=20
> if they cared.. which they clearly don't.)
>
>

--=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/=
bd2c8cd1-69bc-4ffc-9ff4-fa12e929c2afn%40googlegroups.com.

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

<div>Hi Greg, list,</div><div><br /></div><div>re:</div><div><br /></div><d=
iv>&gt; A point of clarification,=C2=A0 that's really a scheme to keep arbi=
trary data
 out of unprunable data.=C2=A0 The proofs that the values in question are=
=20
what they're supposed to be are themselves arbitrary data channels.=C2=A0 B=
ut
 these proofs are prunable.</div><div><br /></div><div>Could you expand on =
the "arbitrary data channels" here?</div><div><br /></div><div>I was thinki=
ng through specifically the case of (pre-taproot) raw pubkey outputs and th=
inking about what it would mean to prove that it's not data; here, the obvi=
ous approach is "ECDSA-sign using the key" which trivially fails to prove i=
t's not data if the message for the signature is unconstrained. But obvious=
ly, it would be constrained to be e.g. the hash of the pubkey, fixing it an=
d preventing data storage in the (s) component of ECDSA's (r, s). (i.e. if =
you wanted to bypass this scheme to still store 32 bytes of data, you'd jus=
t choose s as that data and then use the standard pubkey recovery algorithm=
; except you can't if P is in the message).</div><div><br /></div><div>All =
of that seems spectacularly irrelevant, not only because trivially you avoi=
d it with using Hash(P) in the sig message, but even more, since this would=
 be a new piece of consensus, you could just use BIP340 or any similar Schn=
orr with key-prefixing anyway, no matter what style of scriptPubKey is invo=
lved.</div><div><br /></div><div>The question is, what is the arbitrary dat=
a channel that you refer to, that remains, when doing this? The R-value is =
ofc arbitrary but it's still a "image" not "preimage" (x-coord for the nonc=
e secret * G). As I write this, one answer occurs to me, that if you used t=
he same R value twice you leak the nonce and the secret key, which in this =
weird setup means you are "broadcasting" 2 32 byte values that are random, =
in 2 outputs, which I guess is the same embedding ratio? A horrible idea in=
 practice given you lose control of the outputs; I know that at least some =
schemes that embed data in utxos deliberately do so to keep them in the utx=
o set permanently. So I somehow feel that that's not what you meant ...</di=
v><div><br /></div><div>Cheers,</div><div>AdamISZ/waxwing</div><br /><div c=
lass=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Friday, May =
2, 2025 at 9:00:25=E2=80=AFPM UTC-3 Greg Maxwell wrote:<br/></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px sol=
id rgb(204, 204, 204); padding-left: 1ex;"><div><div dir=3D"auto">On Friday=
, May 2, 2025 at 10:23:45=E2=80=AFPM UTC Peter Todd wrote:<br></div><blockq=
uote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"># _Uninterrupted_ Illicit Data
<br></blockquote><div><br></div><div>To refine that, _illicit data_ is a pr=
oblem and encryption at rest does not address particularly in so far as pos=
session of some data is a strict liability crime.</div><div><br></div><div>=
Uninterrupted however means that it&#39;s more likely to get caught by rand=
om scanning tools and whatnot -- and the encryption does that and probably =
eliminates most of difference between interrupted and not, which is Peter T=
odd&#39;s point.</div><div><br></div><div>But I heard someone last night sa=
y that encryption solves the illicit data issue and it absolutely doesn&#39=
;t. It solves a particular unexciting but more immediate sub part of the pr=
oblem which is stuff like AV scanners.=C2=A0 But I think that issue is orth=
ogonal to this proposed change.</div><div><br></div><div>Aside, I&#39;d bee=
n thinking there was a consensus limit on output sizes of 10kb but now I&#3=
9;m remembering that it&#39;s just at spend time and so obviously wouldn&#3=
9;t be relevant here.</div></div><div><div>=C2=A0</div><blockquote style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">to make data publication somewhat more expensive with consensus cha=
nges.
<br>Gregory Maxwell outlined how to do so on this mailing list years ago
<br></blockquote><div><br></div></div><div><div>A point of clarification,=
=C2=A0 that&#39;s really a scheme to keep arbitrary data out of unprunable =
data.=C2=A0 The proofs that the values in question are what they&#39;re sup=
posed to be are themselves arbitrary data channels.=C2=A0 But these proofs =
are prunable.</div><div><br></div><div>It&#39;s true that they they only ne=
ed to be carried near the tip, so you could even consider them *super pruna=
ble*.=C2=A0=C2=A0 And while perhaps you can get many existing transaction p=
atterns into that model, I&#39;m pretty confident you can&#39;t eliminate h=
igh bandwidth channels in script without massively hobbling Bitcoin overall=
.=C2=A0 (Though hey, there are a lot of people out there these days who wou=
ld like to hobble bitcoin, so ::shrugs::)=C2=A0 <br></div><div><br></div><d=
iv>Even if the functionality reduction were worth it, I dunno that the gain=
 between prunable (where most data storage stuff is) and super-prunable is =
that interesting, particularly since you&#39;re looking at on the order of =
a 20%-30% increase of bandwidth for transactions and blocks to carry those =
proofs.=C2=A0 Though for context I then eventually most nodes will sync thr=
ough some kind of utxo fast forward, just due to practical considerations, =
and w/ that the difference in prunability degree is diminished further.</di=
v><div><br></div><div>It might make sense for just *outputs* if data stuffi=
ng into the UTXO set continues to be a problem as I think it can be done fo=
r just outputs without huge functionality loss... though even so the disrup=
tion and overheads yuck.=C2=A0 But before even considering such a disruptiv=
e change you&#39;d want to be really user everything was done to get the st=
orage out of the unprunable data first, e.g. by getting rid of limits on op=
_return size.</div></div><div><div><br></div><blockquote style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">ha=
ve an overhead of about 6.6x. Existing data encoders have been happy
<br>to pay even more money than that in terms of increased fees during fee
<br>spikes; the difference in cost between witness space and txout space is
<br>already 4x, and some are happy to publish data that way anyway.
<br></blockquote><div><br></div></div><div><div>A point I raised on bitcoin=
talk: If you work out how much it costs to store data on S3 (by far not the=
 cheapest internet data storage) for *forever* you end up with a rate that =
is less than a hundred thousandth the current Bitcoin minimum fee rate-- ma=
ybe way less if you also factor in the cost of storage decreasing, but I di=
dn&#39;t.=C2=A0 Data stuffers are not particularly price sensitive, if they=
 were they wouldn&#39;t be using Bitcoin at all.=C2=A0 Schemes to discourag=
e them by causing them increased costs (e.g. by forcing them to encode in w=
ays that use more block capacity) shouldn&#39;t be expected to work.</div><=
div><br></div><div>And to the extent that what many of these things have be=
en doing is trying to profit off seigniorage-- creating a rare &#39;asset&#=
39; to sell to some greater fool and profit off the difference-- further re=
stricting them could increase their volume because the resource they need h=
as been made more rare.=C2=A0 For the vast majority of users the ire comes =
about this stuff from the fact that they&#39;ve driven up fees at times, bu=
t that is dependent on what they&#39;re willing to spend, which is likely n=
ot particularly related to the marginal data rates. (And one could always e=
mbed smaller jpegs, compress them better, or not use raw json instead of an=
 efficient encoding if they cared.. which they clearly don&#39;t.)</div><di=
v><br></div></div></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/bd2c8cd1-69bc-4ffc-9ff4-fa12e929c2afn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/bd2c8cd1-69bc-4ffc-9ff4-fa12e929c2afn%40googlegroups.com</a>.<br />

------=_Part_29331_1777088072.1748188406236--

------=_Part_29330_1618525221.1748188406236--