path: root/52/e940cf0f36ca5f3c5b09b2044060b110a0e79c

Delivery-date: Wed, 01 Oct 2025 00:38:24 -0700
Received: from mail-oa1-f60.google.com ([209.85.160.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDR2FQF7ZUGBBZNU6PDAMGQEGCDQ7MY@googlegroups.com>)
	id 1v3rPr-0000Um-Ul
	for bitcoindev@gnusha.org; Wed, 01 Oct 2025 00:38:24 -0700
Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-30cce8fa3b1sf2458374fac.1
        for <bitcoindev@gnusha.org>; Wed, 01 Oct 2025 00:38:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1759304298; x=1759909098; 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=bppl0CZTQSWeZQNOgsRPwG01hJutSPF78MRxroLH4r0=;
        b=dE0i3o52qhYyCQdHP6zcuSj+KgH1kPn88S4BzU4g7gtHCKP3mBbp33Qeu7ZXR9nTvi
         Cd/amP4HtJFGDJAj/vaWeXf+WnYjhu4xXNJb4TW7dRXHOSBLn5UthwXuVlZWTkMksdAP
         lJpFQxpMCODgux9NbX1DCHH46IoEXUECY/4wgkxxdpAJh//2nNbztsQy0mCyuxxQKM/T
         ZijX3vguqSa1Q/Pgn4AayAUU71mY6yzSe0izn6UhYIhxGRoNWMQBc90a98sp88ZOKrwR
         NInmoUnPcf4H2f43QOA0SVeo99Sbl8hYnTugRwHIrNHBW55IXe1EsxAq2oiVdOfUIGFO
         aA6A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759304298; x=1759909098; 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=bppl0CZTQSWeZQNOgsRPwG01hJutSPF78MRxroLH4r0=;
        b=ifYKWjUYJpfnevRkqenNYPHyeZvEqM9fPPsyl8C/IGGbluAA8wnVtI1cNGhXG7d0St
         a7ECCMx+WCuZXuq/h+PXnUREg5BI2TAceA3ovlbriAp5Gaz/8HtuFCJKDQB0LnUe4rN7
         Go1Cpwz6NWaCee0A/e8JMQemiutiL3poqoW+x6Umiw6kGemqnzZrgRo2oicWufgM3L74
         nzyxgLO0gEmCjBMhhMnFKjySbrykTY6sgyaC/wF13SvyR4oUqqq4vKrbg5Fyw8sbEA5D
         DkzwfScGhg95nWdKp/fLsv6nPHvt9NG44Dra2crdg0wWSxxM6S72fYkBJ+mEtPbNEBSi
         zm2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759304298; x=1759909098;
        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=bppl0CZTQSWeZQNOgsRPwG01hJutSPF78MRxroLH4r0=;
        b=K5a6Xd4Ok6Frz8NK9EQBMKh2QQBFrdrGSlNG2T9ifqu4HO/Gr1c6Vl1H1mSTzuJCTC
         jT03VDNRtntqBhxoYK9Z69NwkkFWY2+BkMVgqxDBiAzioJ1XllFZ0Txd0AOMN9jRucpG
         zOs2bD+kJTwswJdQm2jhOiTvCD8LvYFTiFFiP2hrmIHeLE/wNlTNVvOfKXhdl0ptOEGL
         fFp5aLxx014cNSd4A/GtKz3rSbCSRKP7zfnXlbmZmba/aEJOuwnUfC8uHna/8DDUW5xP
         RIoS+b8Me9Ie4UcRnTQN63LTP5J/XNw1MYZNJZSPgkOsGIm2VBw3dYCh0oOrhnHKPsxh
         q4bA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCW3RtOmlaxWN9nRF2U+BJOjYXhY3qUe1DFZhNwN/M3Ufhb8a8LeAyuTrwxnRnCQ/6OhvZl0o9YBDT5G@gnusha.org
X-Gm-Message-State: AOJu0Yzd55jpFeZ5S3W0zme7rFlz6ccGrL5p1J4n2pxQODF9x16/LpYL
	U6thIlG8gMw4nLML2Y/xfauHVmQqG+YmrLRXOTP6GLbRAvLOY0ZiB3ym
X-Google-Smtp-Source: AGHT+IGCfXS/ZrL0Ke8e63gjlZ/295BufXzyJT9KQesKq9A5SjpPAU+u/qASCxhpvEEhV8mFoz9P+Q==
X-Received: by 2002:a05:6870:6594:b0:314:b6a6:68a1 with SMTP id 586e51a60fabf-39bb6b5e96fmr1463074fac.41.1759304297248;
        Wed, 01 Oct 2025 00:38:17 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4r/UjJ+V/SP+sDHk+YUP/QRkAZO0qNxkEyH85umBWieA=="
Received: by 2002:a05:6870:5486:b0:31d:8e96:6f5e with SMTP id
 586e51a60fabf-35eecc43003ls5263440fac.2.-pod-prod-08-us; Wed, 01 Oct 2025
 00:38:12 -0700 (PDT)
X-Received: by 2002:a05:6808:6909:b0:43f:95b5:66e with SMTP id 5614622812f47-43fa40c00a9mr1369575b6e.14.1759304292733;
        Wed, 01 Oct 2025 00:38:12 -0700 (PDT)
Received: by 2002:a05:690c:4605:b0:725:2535:e36 with SMTP id 00721157ae682-77f6fad2435ms7b3;
        Tue, 30 Sep 2025 20:39:33 -0700 (PDT)
X-Received: by 2002:a05:690c:8bcf:b0:725:5fb2:52a9 with SMTP id 00721157ae682-77f6f3f453bmr22053397b3.44.1759289972782;
        Tue, 30 Sep 2025 20:39:32 -0700 (PDT)
Date: Tue, 30 Sep 2025 20:39:32 -0700 (PDT)
From: Dingocoin <dingocoin.luckydingo@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n@googlegroups.com>
In-Reply-To: <1A33D206-444A-49E7-B1F1-E9FE5F4E32FB@drbonez.dev>
References: <cbdab6fa-93bc-44c9-80f0-6c68c6554f56n@googlegroups.com>
 <CALiT-ZqFhMV8VfgOdNyamG4oLgyCL5E7W8s3F9gB_k0ihyUAgA@mail.gmail.com>
 <E0178F1A-F2D7-4787-BF52-FA75BFC43EE7@drbonez.dev>
 <8c6bb024-437f-4122-8ae0-f8ed9b9c23e4n@googlegroups.com>
 <1A33D206-444A-49E7-B1F1-E9FE5F4E32FB@drbonez.dev>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_55804_515899823.1759289972414"
X-Original-Sender: dingocoin.luckydingo@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_55804_515899823.1759289972414
Content-Type: multipart/alternative; 
	boundary="----=_Part_55805_1632057598.1759289972414"

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


Greg ,=20

Policy divergence already exists through client forks and custom patches,=
=20
so the question isn't whether filtering should exist but whether it should=
=20
be transparent and user-controlled versus opaque and developer-controlled.=
=20
This BIP makes existing policy differences explicit rather than hidden,=20
providing transparency where users may unknowingly participate in filtering=
=20
through different client implementations. Given that miners increasingly=20
bypass relay networks through direct submission channels, mempool policy is=
=20
primarily about local resource management rather than modeling mining=20
behavior, making user-defined policies a tool for node operators to manage=
=20
their own resources. While concerns about censorship infrastructure are=20
valid, transparent policy scripting is more aligned with Bitcoin's=20
anti-censorship principles than the current situation of scattered, opaque=
=20
policy differences across forks .


On Wednesday, October 1, 2025 at 4:32:39=E2=80=AFAM UTC+5:30 Aiden McClella=
nd wrote:

> Jeremy,=20
>
> That's actually really clever. I had wanted the scripts to be able to=20
> manage mempool size, and handle prioritization of higher feerate=20
> transactions (hence the evict() fn and minFeerate part of the api), which=
 I=20
> don't think could be done with script, and I'm not sure we'd want to add=
=20
> opcodes to make that possible, given that it only makes sense in this=20
> context. But maybe that part doesn't need to be part of the dynamic=20
> scripts? Definitely gives me a lot to think about.=20
>
> Thanks,=20
> Aiden McClelland=20
>
>
> On September 30, 2025 3:09:15 PM MDT, jeremy <jeremy....@gmail.com> wrote=
:
>
>> Bitcoin already has a built in user defined script language: Bitcoin=20
>> Script.
>>
>> If you add a couple conditionally verified opcodes (the same ones=20
>> necessary for covenants), you could write whatever filter you like, and=
=20
>> we'd learn more about what the best opcodes are for writing covenants.
>>
>> You would execute the script "pretending" to be input 0.
>>
>> We would then at least learn something about covenants.
>> On Tuesday, September 30, 2025 at 2:22:10=E2=80=AFAM UTC-4 Aiden McClell=
and wrote:
>>
>>> /dev/fd0,
>>>
>>> I appreciate the comments. A txnotify solution could work, although it=
=20
>>> loses a lot of the modularity and sandboxing of what I'm proposing. It=
=20
>>> would probably result in a single external binary, running all of the=
=20
>>> policy validation logic, rather than a bundle of scripts you can mix an=
d=20
>>> match. And it might encourage solutions that involve fetching relay=20
>>> policies over the internet, which is probably not ideal. Ideally, updat=
ing=20
>>> policy should require user action.=20
>>>
>>> Thanks,=20
>>> Aiden McClelland
>>>
>>>
>>>
>>> On September 27, 2025 7:22:28 PM MDT, /dev /fd0 <alice...@gmail.com>=20
>>> wrote:
>>>
>>>> Hi Aiden,
>>>>
>>>> There is an easy solution based on my understanding of [transaction=20
>>>> validation][0] although I have not tested it:
>>>>
>>>> 1. Add a config option `txnotify` similar to `blocknotify` that=20
>>>> executes commands or script when a new transaction is received from a =
peer.
>>>> 2. Add a function `ExecuteTxNotify()` that will run the script provide=
d=20
>>>> by the user in step 1. Script should either return 'accept' for 'rejec=
t'=20
>>>> and function would return true/false accordingly.
>>>> 3. Call `ExecuteTxNotify()` in ` AcceptToMemoryPool()` so that rejecte=
d=20
>>>> transactions do not enter the mempool.
>>>>
>>>> [0]: https://bitcoincore.academy/transaction-validation.html
>>>>
>>>> /dev/fd0
>>>> floppy disk guy
>>>>
>>>> On Thu, Sep 25, 2025 at 12:00=E2=80=AFAM Aiden McClelland <m...@drbone=
z.dev>=20
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'd like to share for discussion a draft BIP to allow for a modular=
=20
>>>>> mempool/relay policy: https://github.com/bitcoin/bips/pull/1985
>>>>>
>>>>> I think it could potentially reduce conflict within the community=20
>>>>> around relay policy, as an alternative to running lots of different n=
ode=20
>>>>> implementations/forks when there are disagreements.
>>>>>
>>>>> I am working on a reference implementation using Bellard's QuickJS,=
=20
>>>>> but it has been almost a decade since I've written C++, so it's slow =
going=20
>>>>> and I'm sure doesn't follow best-practices. Once it's working, it can=
 be=20
>>>>> cleaned up.
>>>>>
>>>>> Thanks,
>>>>> Aiden McClelland
>>>>>
>>>>> --=20
>>>>> You received this message because you are subscribed to the Google=20
>>>>> Groups "Bitcoin Development Mailing List" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, sen=
d=20
>>>>> an email to bitcoindev+...@googlegroups.com.
>>>>> To view this discussion visit=20
>>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-=
6c68c6554f56n%40googlegroups.com=20
>>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0=
-6c68c6554f56n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>>>> .
>>>>>
>>>>

--=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/=
5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n%40googlegroups.com.

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

<br />Greg ,=C2=A0<div><br /></div><div>Policy divergence already exists th=
rough client forks and custom patches, so the question isn't whether filter=
ing should exist but whether it should be transparent and user-controlled v=
ersus opaque and developer-controlled. This BIP makes existing policy diffe=
rences explicit rather than hidden, providing transparency where users may =
unknowingly participate in filtering through different client implementatio=
ns. Given that miners increasingly bypass relay networks through direct sub=
mission channels, mempool policy is primarily about local resource manageme=
nt rather than modeling mining behavior, making user-defined policies a too=
l for node operators to manage their own resources. While concerns about ce=
nsorship infrastructure are valid, transparent policy scripting is more ali=
gned with Bitcoin's anti-censorship principles than the current situation o=
f scattered, opaque policy differences across forks .</div><div><br /></div=
><div><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gma=
il_attr">On Wednesday, October 1, 2025 at 4:32:39=E2=80=AFAM UTC+5:30 Aiden=
 McClelland wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: =
1ex;"><div><div dir=3D"auto">Jeremy, <br><br>That&#39;s actually really cle=
ver. I had wanted the scripts to be able to manage mempool size, and handle=
 prioritization of higher feerate transactions (hence the evict() fn and mi=
nFeerate part of the api), which I don&#39;t think could be done with scrip=
t, and I&#39;m not sure we&#39;d want to add opcodes to make that possible,=
 given that it only makes sense in this context. But maybe that part doesn&=
#39;t need to be part of the dynamic scripts? Definitely gives me a lot to =
think about. <br><br>Thanks, <br>Aiden McClelland </div></div><div><br><br>=
<div class=3D"gmail_quote"><div dir=3D"auto">On September 30, 2025 3:09:15 =
PM MDT, jeremy &lt;<a href data-email-masked rel=3D"nofollow">jeremy....@gm=
ail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
Bitcoin already has a built in user defined script language: Bitcoin Script=
.<div><br></div><div>If you add a couple conditionally verified opcodes (th=
e same ones necessary for covenants), you could write whatever filter you l=
ike, and we&#39;d learn more about what the best opcodes are for writing co=
venants.</div><div><br></div><div>You would execute the script &quot;preten=
ding&quot; to be input 0.</div><div><br></div><div>We would then at least l=
earn something about covenants.</div><div class=3D"gmail_quote"><div dir=3D=
"auto" class=3D"gmail_attr">On Tuesday, September 30, 2025 at 2:22:10=E2=80=
=AFAM UTC-4 Aiden McClelland wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div><div dir=3D"auto">/dev/fd0,<br><br>I appreciate the comm=
ents. A txnotify solution could work, although it loses a lot of the modula=
rity and sandboxing of what I&#39;m proposing. It would probably result in =
a single external binary, running all of the policy validation logic, rathe=
r than a bundle of scripts you can mix and match. And it might encourage so=
lutions that involve fetching relay policies over the internet, which is pr=
obably not ideal. Ideally, updating policy should require user action. <br>=
<br>Thanks, <br>Aiden McClelland<br><br></div></div><div><br><br><div class=
=3D"gmail_quote"><div dir=3D"auto">On September 27, 2025 7:22:28 PM MDT, /d=
ev /fd0 &lt;<a rel=3D"nofollow">alice...@gmail.com</a>&gt; wrote:</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr">Hi Aiden,<div><br></div><div>There is an easy solution bas=
ed on my understanding of [transaction validation][0] although I have not t=
ested it:<br><br>1. Add a config option `txnotify` similar to `blocknotify`=
 that executes commands or script when a new transaction is received from a=
 peer.</div><div>2. Add a function `ExecuteTxNotify()` that will run the sc=
ript provided by the user in step 1. Script should either return &#39;accep=
t&#39; for &#39;reject&#39; and function would return true/false accordingl=
y.</div><div>3. Call `ExecuteTxNotify()` in `

AcceptToMemoryPool()` so that rejected transactions do not enter the mempoo=
l.</div><div><br></div><div>[0]:=C2=A0<a href=3D"https://bitcoincore.academ=
y/transaction-validation.html" rel=3D"nofollow" target=3D"_blank" data-safe=
redirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://bitcoinco=
re.academy/transaction-validation.html&amp;source=3Dgmail&amp;ust=3D1759376=
288786000&amp;usg=3DAOvVaw2XJrlN9fHj4se6NnZcIlX8">https://bitcoincore.acade=
my/transaction-validation.html</a><br><br>/dev/fd0<br>floppy disk guy</div>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Thu, Sep 25, 2025 at 12:00=E2=80=AFAM Aiden McClelland &lt;<a rel=3D"nof=
ollow">m...@drbonez.dev</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div>Hi all,</div><div><br></div><div>I&#39;d like t=
o share for discussion a draft BIP to allow for a modular mempool/relay pol=
icy: <a href=3D"https://github.com/bitcoin/bips/pull/1985" rel=3D"nofollow"=
 target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3D=
en&amp;q=3Dhttps://github.com/bitcoin/bips/pull/1985&amp;source=3Dgmail&amp=
;ust=3D1759376288786000&amp;usg=3DAOvVaw0PPrWzbF7N0CD_wtNIKmil">https://git=
hub.com/bitcoin/bips/pull/1985</a><br><br></div><div>I think it could poten=
tially reduce conflict within the community around relay policy, as an alte=
rnative to running lots of different node implementations/forks when there =
are disagreements.</div><div><br></div><div>I am working on a reference imp=
lementation using Bellard&#39;s QuickJS, but it has been almost a decade si=
nce I&#39;ve written C++, so it&#39;s slow going and I&#39;m sure doesn&#39=
;t follow best-practices. Once it&#39;s working, it can be cleaned up.</div=
><div><br></div><div>Thanks,</div><div>Aiden McClelland<br></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 rel=3D"nofollow">bitcoindev+...@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" target=3D"_blank" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gro=
ups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%254=
0googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter&amp;source=3Dgma=
il&amp;ust=3D1759376288786000&amp;usg=3DAOvVaw2Ba62QsFndu6ISeT4h2MiD">https=
://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f5=
6n%40googlegroups.com</a>.<br>
</blockquote></div>
</blockquote></div></div></blockquote></div>

<p></p></blockquote></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/5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n%40googlegroups.com</a>.<br />

------=_Part_55805_1632057598.1759289972414--

------=_Part_55804_515899823.1759289972414--