Delivery-date: Thu, 25 Sep 2025 14:27:24 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of gagglehoof@gmail.com designates 209.85.218.43 as permitted sender) client-ip=209.85.218.43;
MIME-Version: 1.0
References: <cbdab6fa-93bc-44c9-80f0-6c68c6554f56n@googlegroups.com>
 <CAAS2fgRFP+BJUZR7h01=7=qamD5qEW6OYJikTMR=5RkxTCEMZg@mail.gmail.com>
 <de4dae19-86f4-4d7a-a895-b48664babbfcn@googlegroups.com> <CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA@mail.gmail.com>
 <CAPDT2SRyVY4rh=HegG+kk5nnDf6qzYuRkUyxCC8iE-ydsh63ew@mail.gmail.com> <CAAS2fgSmiKhmQGAEo2eSQJmen-4kT1vD7dY8UESV4dQrjXau7w@mail.gmail.com>
In-Reply-To: <CAAS2fgSmiKhmQGAEo2eSQJmen-4kT1vD7dY8UESV4dQrjXau7w@mail.gmail.com>
From: Aiden McClelland <me@drbonez.dev>
Date: Thu, 25 Sep 2025 14:51:19 -0600
Message-ID: <CAOSz24TJU-4Q76MtzL+oYYFpXQvrOay5XtdrR0DxVBUAFz=5og@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: yes_please <caucasianjazz12@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000007d7e8a063fa655b5"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--0000000000007d7e8a063fa655b5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Greg,

Let me assume for a minute, for the sake of argument, that I agree that
transaction censorship due to widespread use of transaction filters is a
bad thing (I'm not really taking a stance on that right now). It is an
irrefutable fact that a very large portion of the user base wants to filter
transactions. So many so, that you yourself are worried they will reach the
80% needed to prevent certain types of transactions from propogating.
Wouldn't it then be *worse* if these 80% of users went and ran an
alternative implementation, most likely written by it's most radical
supporters? Or even worse still, felt compelled to coordinate a UASF to
block these transactions entirely?

I at no point intended to insinuate that you or any other core contributer
be compelled to implement a proposal like this. It's up to its supporters
to do so. The real question is, are you willing to work with and compromise
with people who are looking for a solution like this? Or are you going to
force them to abandon the Core project entirely?

Best,
*Aiden McClelland*

On Thu, Sep 25, 2025, 2:03=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> wro=
te:

> > 1) Allowing node
>
> Who said anything about allowing?  Everyone is allowed to do whatever the=
y
> want.  Drill a hole in your head if you like, not my concern.  None of th=
is
> thread is about what people are allowed to do-- that's off the table.  Th=
e
> design and licensing of Bitcoin is such that no one gets to stop anyone
> else from what they want to do anyways (which is, in fact, a big part of
> the issue here).   To think otherwise is to be stuck in a kind of serf
> thinking where you can only do what other people allow you to do.  That h=
as
> never been what Bitcoin was about.
>
> Rather, the question is should people who care about Bitcoin spend their
> time and money developing infrastructure that would be useful, even
> primarily useful, for censorship.  I say no.  Especially because any time
> spent on it is time away from anti-censorship pro-privacy tools and becau=
se
> the effort spent doing so would undermine anti-censorship and pro-privacy
> efforts because they would inevitably moot the efforts expected getting
> into peoples business and filtering their transactions.
>
> You don't have to agree, and you're free to do your own thing just as I'm
> free to say that I think it's a bad direction.  From the very beginning
> Bitcoin has stood against the freedom to transact being overridden by
> some admin based on their judgment call weighing principles against other
> concerns, or at the behest of their superiors.  So many Bitcoiner will
> stand against, route around, and do what they can do to make ineffectual
> the blocking of consensual transactions.  It might not seem as many at th=
e
> moment, but the pro-privacy and anti-censorship 'side' doesn't have a pai=
d
> PR and influence campaign,  but it also doesn't matter so much because
> Bitcoin takes advantage of the nature of information being easy to spread
> and hard to stifel and it doesn't that that huge an effort to route aroun=
d
> censorship efforts.
>
> There are elements of anti-censorship in Bitcoin that have been so far
> underdeveloped.  It's unfortunate that their further development might be
> forced at a time when efforts are needed on other areas.  But perhaps the=
y
> wouldn't get done without a concrete motivation. Such is life.
>
>
>
>
>
> On Thu, Sep 25, 2025 at 9:21=E2=80=AFAM yes_please <caucasianjazz12@gmail=
.com>
> wrote:
>
>> Sorry Greg, could you please elaborate further on your ideas? Some are
>> not exactly clear:
>>
>> 1) Allowing node runners to configure their node as they please and
>> refuse to relay some txs is considered authoritarian, censorship, and an
>> attempt to regulate third parties conduct. On the other hand, forcing no=
des
>> to merge towards a single shared configuration (by preventing them to bl=
ock
>> txs) is not considered authoritarian because this imposition does not
>> discriminate towards any txs and is thus non-authoritarian? Did I get th=
e
>> reasoning correctly here?
>>
>> 2) If the aim is to have a homogenous mempool state and to model what
>> will get mined, shouldn=E2=80=99t we reach this state through distribute=
d
>> independent nodes who decide independently on what they prefer this
>> homogenous state to be? If we don=E2=80=99t reach this state through thi=
s
>> distributed/independent mechanism, then how are we to reach this state? =
Who
>> gets to decide and steer the direction so that we all converge towards t=
his
>> homogenous state?  One of the strongest aspects of bitcoin is the fact t=
hat
>> no single party can force a change/direction, and the network has to
>> somehow reach a shared agreement through independent decision makers who
>> act in what manner they think is best. The proposed BIP seems to be alig=
ned
>> with such a principle, I fail to see any authoritarian aspect here.
>>
>> 3) I share your sentiment and the aim to have a homogenous mempool
>> state, but I am skeptical of the manner in which we are to achieve this
>> according to the ideas you have here expressed (namely not through a
>> distributed independent organic manner)
>>
>>
>> Respectfully, yes_please
>>
>> On Thu, Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell <gmaxwell@gmail.co=
m> wrote:
>>
>>> So that when the "consistent state" changes as a result of some issue
>>> you can update configs instead of having to update software-- which has
>>> considerable more costs and risks, especially if you're carrying local
>>> customizations as many miners do.
>>>
>>>
>>> On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClelland <me@drbonez.de=
v> wrote:
>>>
>>>> If mempool consistency across the network is all that is important, wh=
y
>>>> allow any configuration of mempool relay policies at all?
>>>>
>>>> On Wednesday, September 24, 2025 at 12:47:28=E2=80=AFPM UTC-6 Greg Max=
well
>>>> wrote:
>>>>
>>>>> This appears to substantially misunderstands the purpose of the
>>>>> mempool broadly in the network-- it's purpose is to model what will g=
et
>>>>> mined.  If you're not doing that you might as well set blocks only.
>>>>> Significant discrepancies are harmful to the system and promote
>>>>> centralization and fail to achieve a useful purpose in any case.  Wha=
t
>>>>> marginal benefits might be provided do not justify building and deplo=
ying
>>>>> the technological infrastructure for massive censorship.
>>>>>
>>>>> If you think this is important, I advise you to select another
>>>>> cryptocurrency which is compatible with such authoritarian leanings. =
 --
>>>>> though I am unsure if any exist since it is such a transparently poin=
tless
>>>>> direction.
>>>>>
>>>>>
>>>>> On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClelland <m...@drbone=
z.dev>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'd like to share for discussion a draft BIP to allow for a modular
>>>>>> mempool/relay policy: https://github.com/bitcoin/bips/pull/1985
>>>>>>
>>>>>> I think it could potentially reduce conflict within the community
>>>>>> around relay policy, as an alternative to running lots of different =
node
>>>>>> implementations/forks when there are disagreements.
>>>>>>
>>>>>> I am working on a reference implementation using Bellard's QuickJS,
>>>>>> but it has been almost a decade since I've written C++, so it's slow=
 going
>>>>>> and I'm sure doesn't follow best-practices. Once it's working, it ca=
n be
>>>>>> cleaned up.
>>>>>>
>>>>>> Thanks,
>>>>>> Aiden McClelland
>>>>>>
>>>>>> --
>>>>>> 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+...@googlegroups.com.
>>>>>> To view this discussion visit
>>>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0=
-6c68c6554f56n%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f=
0-6c68c6554f56n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>>>>> .
>>>>>>
>>>>> --
>>>> 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/de4dae19-86f4-4d7a-a895-b=
48664babbfcn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895-=
b48664babbfcn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>> --
>>> 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/CAAS2fgRABqRe1j6xzW0uhVrDi=
QnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrD=
iQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.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/=
CAOSz24TJU-4Q76MtzL%2BoYYFpXQvrOay5XtdrR0DxVBUAFz%3D5og%40mail.gmail.com.

--0000000000007d7e8a063fa655b5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Greg,=C2=A0</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Let me assume for a minute, for the sake of argument, that I agr=
ee that transaction censorship due to widespread use of transaction filters=
 is a bad thing (I&#39;m not really taking a stance on that right now). It =
is an irrefutable fact that a very large portion of the user base wants to =
filter transactions. So many so, that you yourself are worried they will re=
ach the 80% needed to prevent certain types of transactions from propogatin=
g. Wouldn&#39;t it then be <i>worse</i> if these 80% of users went and ran =
an alternative implementation, most likely written by it&#39;s most radical=
 supporters? Or even worse still, felt compelled to coordinate a UASF to bl=
ock these transactions entirely?</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I at no point intended to insinuate that you or any other core co=
ntributer be compelled to implement a proposal like this. It&#39;s up to it=
s supporters to do so. The real question is, are you willing to work with a=
nd compromise with people who are looking for a solution like this? Or are =
you going to force them to abandon the Core project entirely?</div><div><br=
></div><div dir=3D"auto">Best,</div><div data-smartmail=3D"gmail_signature"=
><font face=3D"courier new, monospace"><b>Aiden McClelland</b></font></div>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Thu, Sep 25, 2025, 2:03=E2=80=AFPM Greg Maxwell &lt;<a href=3D"mailto:gm=
axwell@gmail.com" target=3D"_blank" rel=3D"noreferrer">gmaxwell@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div>&gt;=C2=A0<span lang=3D"EN-US">1)=C2=A0</span><span lan=
g=3D"EN-US">Allowing node</span></div><div><span lang=3D"EN-US"><br></span>=
</div><div><span lang=3D"EN-US">Who said anything about allowing?=C2=A0 Eve=
ryone is allowed to do whatever they want.=C2=A0 Drill a hole in your head =
if you like, not my concern.=C2=A0 None of this thread is about what people=
 are allowed to do-- that&#39;s off the table.=C2=A0 The design and licensi=
ng of Bitcoin is such that no one gets to stop anyone else from what they=
=C2=A0want to do anyways (which is, in fact, a big part of the issue here).=
=C2=A0 =C2=A0To think otherwise is to be stuck in a kind of serf thinking w=
here you can only do what other people allow you to do.=C2=A0 That has neve=
r been what Bitcoin was about.</span></div><div><span lang=3D"EN-US"><br></=
span></div><div><span lang=3D"EN-US">Rather, the question is should people =
who care about Bitcoin spend their time and money developing infrastructure=
 that would be useful, even primarily useful, for censorship.=C2=A0 I say n=
o.=C2=A0 Especially because any time spent on it is time away from anti-cen=
sorship pro-privacy tools and because the effort spent doing so would under=
mine anti-censorship and pro-privacy efforts because they would inevitably=
=C2=A0moot the efforts=C2=A0expected getting into peoples business and filt=
ering their transactions.</span></div><div><span lang=3D"EN-US"><br></span>=
</div><div><span lang=3D"EN-US">You don&#39;t have to agree, and you&#39;re=
 free to do your own thing just as I&#39;m free to say that I think it&#39;=
s a bad=C2=A0direction.=C2=A0 From the very beginning Bitcoin has stood aga=
inst the freedom to transact being=C2=A0</span>overridden by some admin bas=
ed on their judgment call weighing principles against other concerns, or at=
 the behest of their superiors.=C2=A0 So many Bitcoiner will stand against,=
 route around, and do what they can do to make ineffectual the blocking of =
consensual=C2=A0transactions.=C2=A0 It might not seem as many at the moment=
, but the pro-privacy and anti-censorship &#39;side&#39; doesn&#39;t have a=
 paid PR and influence campaign,=C2=A0 but it also doesn&#39;t matter so mu=
ch because Bitcoin takes advantage of the nature of information being easy =
to spread and hard to stifel and it doesn&#39;t that that huge an effort to=
 route around censorship efforts.</div><div><br></div><div>There are elemen=
ts of anti-censorship in Bitcoin that have been so far underdeveloped.=C2=
=A0 It&#39;s unfortunate that their further development might be forced at =
a time when efforts are needed on other areas.=C2=A0 But perhaps they would=
n&#39;t get done without a concrete motivation. Such is life.</div><div><br=
></div><div><span lang=3D"EN-US"><br></span></div><div><span lang=3D"EN-US"=
><br></span></div><div><span lang=3D"EN-US"><br></span></div></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 25=
, 2025 at 9:21=E2=80=AFAM yes_please &lt;<a href=3D"mailto:caucasianjazz12@=
gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">caucasianjazz12@=
gmail.com</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 dir=3D"ltr"><p style=3D"color:rgba(232,230,227,0.87);font-f=
amily:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span l=
ang=3D"EN-US">Sorry Greg, could you please elaborate further on your ideas?=
 Some are not exactly clear:</span></p><p style=3D"color:rgba(232,230,227,0=
.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14=
px"><span lang=3D"EN-US">1)=C2=A0</span><span lang=3D"EN-US">Allowing node =
runners to configure their node as they please and refuse to relay some txs=
 is considered authoritarian, censorship, and an attempt to regulate third =
parties conduct. On the other hand, forcing nodes to merge towards a single=
 shared configuration (by preventing them to block txs) is not considered a=
uthoritarian because this imposition does not discriminate towards any txs =
and is thus non-authoritarian? Did I get the reasoning correctly here?</spa=
n></p><p style=3D"color:rgba(232,230,227,0.87);font-family:Roboto,RobotoDra=
ft,Helvetica,Arial,sans-serif;font-size:14px"><span lang=3D"EN-US">2) I</sp=
an><span>f the aim is to have a homogenous mempool state and to model what =
will get mined, shouldn=E2=80=99t we reach this state through distributed i=
ndependent nodes who decide=C2=A0independently on what they prefer this hom=
ogenous state to be? If we don=E2=80=99t reach this state through this dist=
ributed/independent mechanism, then how are we to reach this state? Who get=
s to decide and steer the direction so that we all converge towards this ho=
mogenous state?=C2=A0 One of the strongest aspects of bitcoin is the fact t=
hat no single party can force a change/direction, and the network has to so=
mehow reach a shared agreement through independent decision makers who act =
in what manner they think is best. The proposed BIP seems to be aligned wit=
h such a principle, I fail to see any authoritarian aspect here.=C2=A0</spa=
n></p><p style=3D"color:rgba(232,230,227,0.87);font-family:Roboto,RobotoDra=
ft,Helvetica,Arial,sans-serif;font-size:14px"><span>3)=C2=A0</span><span>I =
share your sentiment and the aim to have a homogenous mempool state, but I =
am skeptical of the manner in which we are to achieve this according to the=
 ideas you have here expressed (namely not through a distributed independen=
t organic manner)</span></p><p style=3D"color:rgba(232,230,227,0.87);font-f=
amily:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span l=
ang=3D"EN-US"><br></span></p><p style=3D"color:rgba(232,230,227,0.87);font-=
family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span =
lang=3D"EN-US">Respectfully, yes_please=C2=A0=C2=A0=C2=A0</span></p></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu,=
 Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell &lt;<a href=3D"mailto:gmaxwe=
ll@gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">gmaxwell@gmai=
l.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div>So that when the &quot;consistent state&quot; ch=
anges as a result of some issue you can update configs instead of having to=
 update software-- which has considerable more costs and risks, especially =
if you&#39;re carrying local customizations as many miners do.</div><div><b=
r></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClelland &lt;<a hre=
f=3D"mailto:me@drbonez.dev" rel=3D"noreferrer noreferrer" target=3D"_blank"=
>me@drbonez.dev</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">If mempool consistency across the network is all that is imp=
ortant, why allow any configuration of mempool relay policies at all?<br><b=
r><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Wedn=
esday, September 24, 2025 at 12:47:28=E2=80=AFPM UTC-6 Greg Maxwell wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>This appears to substantially=C2=A0misunderstands the purpose of the =
mempool broadly in the network-- it&#39;s purpose is to model what will get=
 mined.=C2=A0 If you&#39;re not doing that you might as well set blocks onl=
y.=C2=A0 Significant=C2=A0discrepancies=C2=A0are harmful to the system and =
promote centralization=C2=A0and fail to achieve a useful purpose in any cas=
e.=C2=A0 What marginal benefits might be provided do not justify=C2=A0build=
ing and deploying the technological=C2=A0infrastructure=C2=A0for massive ce=
nsorship.</div><div><br></div><div>If you think this is important, I advise=
 you to select another cryptocurrency which is compatible with such authori=
tarian=C2=A0leanings.=C2=A0 -- though I am unsure if any exist since it is =
such a transparently pointless direction.</div><div><br></div></div><br><di=
v class=3D"gmail_quote"></div><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClellan=
d &lt;<a rel=3D"nofollow noreferrer noreferrer">m...@drbonez.dev</a>&gt; wr=
ote:<br></div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div>Hi all,</div><div><br></div><div>I&#39;d like to=
 share for discussion a draft BIP to allow for a modular mempool/relay poli=
cy: <a href=3D"https://github.com/bitcoin/bips/pull/1985" rel=3D"nofollow n=
oreferrer noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/pul=
l/1985</a><br><br></div><div>I think it could potentially reduce conflict w=
ithin the community around relay policy, as an alternative to running lots =
of different node implementations/forks when there are disagreements.</div>=
<div><br></div><div>I am working on a reference implementation using Bellar=
d&#39;s QuickJS, but it has been almost a decade since 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>Tha=
nks,</div><div>Aiden McClelland<br></div>

<p></p></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">

-- <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 noreferrer noreferrer">bitcoindev+...@googlegrou=
ps.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 noreferrer noreferrer"=
 target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93=
bc-44c9-80f0-6c68c6554f56n%40googlegroups.com</a>.<br>
</blockquote></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" rel=3D"n=
oreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups=
.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/de4dae19-86f4-4d7a-a895-b48664babbfcn%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a=
-a895-b48664babbfcn%40googlegroups.com</a>.<br>
</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" rel=3D"n=
oreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups=
.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail=
.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferr=
er" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/CAAS2fgR=
ABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com</a>.<br>
</blockquote></div>
</blockquote></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/CAOSz24TJU-4Q76MtzL%2BoYYFpXQvrOay5XtdrR0DxVBUAFz%3D5og%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAOSz24TJU-4Q76MtzL%2BoYYFpXQvrOay5XtdrR0DxVBUAFz%3D5og%=
40mail.gmail.com</a>.<br />

--0000000000007d7e8a063fa655b5--