Delivery-date: Sat, 27 Sep 2025 08:22:23 -0700
Received-SPF: pass (google.com: domain of oj.webtc0@proton.me designates 109.224.244.17 as permitted sender) client-ip=109.224.244.17;
Date: Sat, 27 Sep 2025 14:44:12 +0000
To: "garlonicon@gmail.com" <garlonicon@gmail.com>
From: "'OJ' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: "apoelstra@wpsoftware.net" <apoelstra@wpsoftware.net>, "bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
Message-ID: <Rr9InzRLdLOAtNdtSzmgBmCX634eSgDHEPS4fW-0WCCA31XHfbTSWQ1tweH0GeNhH9BhCREn_2sU5AR2SmXXgOm8SpkkVwciq7ql8K7yBiE=@proton.me>
In-Reply-To: <CAN7kyNgxnKoX7OBLOiHZWLg+9rvisbpmEMrs9RsSMDfeT-sw3w@mail.gmail.com>
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> <CAAANnUxBTRzE1PLe9oJU_ukmp3a_y799W_7Ez4rOUOYPhdu26A@mail.gmail.com> <aNXRSd7ygh6NqE1V@mail.wpsoftware.net> <CAN7kyNgxnKoX7OBLOiHZWLg+9rvisbpmEMrs9RsSMDfeT-sw3w@mail.gmail.com>
Feedback-ID: 155733714:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_cCigssFrm44rP8i3LxII1amzbsHUZR0D1L9d9itfq8"
Reply-To: OJ <oj.webtc0@proton.me>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

I fail to understand how we come from "filters do not work" to "filters ado=
pted by a majority is censorship". There seems to be a confusion too regard=
ing filtering arbitrary data and censorship of consensus valid tx, like OFA=
C compliant block. Those two are different. Chris G has pointed out many ti=
mes as well that spam cannot be stopped with consensus rules change, only v=
ia policy it can be filtered to make the spammers attempt more difficult.
Invoking Satoshi by Greg Maxwell is also disingenuous when he was the first=
 to have policy in place to prevent specific script into blocks.

Also the thinking that miners control the network is also bad as its imposi=
ng behaviour on nodes runners such that the relay network mempool should al=
ways be consistent with what gets mined.
Each node is a free agent that determine what its mempool should be and con=
versely miners are the one that should take notice of what the relay networ=
k homogeneous mempool is.
This BIP proposal move in the right direction in regards to finding a compr=
omise while not disparaging anyones right as a free agent node runner.

Best regards,

-------- Original Message --------
On 9/26/25 2:03 PM, Garlo Nicon  wrote:

>> You cannot pick and choose which parts of a block you like and which par=
ts are "abusive".
>
> In the current implementation, yes. But if you accept a proof, that a blo=
ck is valid, instead of accepting a block in plaintext, then you can land o=
n the same chain. Because after all, pruned nodes care only about the last =
288 blocks, or something like that. If they can update their UTXO set, and =
always land on a valid chain, then they don't need transaction data in plai=
ntext. They just need to update their UTXO database in a way, where attacki=
ng it would require breaking ECDSA, SHA-256, or similar things (a proof-bas=
ed system, which would not weaken existing cryptographic assumptions, would=
 be sufficient).
>
> And the same is true about Initial Blockchain Download. Only today, you h=
ave to download hundreds of GBs, to synchronize the new node from scratch. =
But it can be changed, and as the size of the whole chain will grow, people=
 will be pushed, to start deploying some optimizations. Otherwise, there wi=
ll be even less nodes, if node operators will decide to trust centralized s=
olutions instead, or do things, which already happened in some altcoins, wh=
ere people passed around an already synced node data, and trusted, that it =
is valid (especially in CPU-mined coins, where verifying thousands blocks r=
equired similar effort, than mining a new block).
>
> pt., 26 wrz 2025 o 02:25 Andrew Poelstra <apoelstra@wpsoftware.net> napis=
a=C5=82(a):
>
>> On Thu, Sep 25, 2025 at 11:52:02AM -0600, Chris Guida wrote:
>>>
>>> Anyway, forcing users to relay transactions they consider abusive if th=
ey
>>> want to relay any transactions at all does not seem in keeping with
>>> bitcoin's ethos, not to mention that it obviously would never work.
>>>
>>
>> Once a transaction is in a block, you need to relay the transaction if
>> you want to relay a block. You cannot pick and choose which parts of a
>> block you like and which parts are "abusive". This is what it means for
>> something to be a consensus system.
>>
>> The purpose of the mempool is to approximate the contents of blocks,
>> both to help individual node operators (who would otherwise get large
>> quantities of "surprise transactions" with every block) and to help the
>> network (which would otherwise have poor propagation properties).
>>
>> Any sort of filtering beyond that done by miners is contrary to this
>> purpose of the mempool. This is a technical fact. It has nothing to do
>> with "bitcoin's ethos", except its ethos as a consensus system, which
>> directly contradicts your point.
>>
>> --
>> Andrew Poelstra
>> Director, Blockstream Research
>> Email: apoelstra at wpsoftware.net
>> Web: https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>> -Justin Lewis-Webster
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n email to [bitcoindev+unsubscribe@googlegroups.com](mailto:bitcoindev%2Bun=
subscribe@googlegroups.com).
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoind=
ev/aNXRSd7ygh6NqE1V%40mail.wpsoftware.net.
>
> --
> 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/bitcoind=
ev/CAN7kyNgxnKoX7OBLOiHZWLg%2B9rvisbpmEMrs9RsSMDfeT-sw3w%40mail.gmail.com](=
https://groups.google.com/d/msgid/bitcoindev/CAN7kyNgxnKoX7OBLOiHZWLg%2B9rv=
isbpmEMrs9RsSMDfeT-sw3w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfo=
oter).

--=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/=
Rr9InzRLdLOAtNdtSzmgBmCX634eSgDHEPS4fW-0WCCA31XHfbTSWQ1tweH0GeNhH9BhCREn_2s=
U5AR2SmXXgOm8SpkkVwciq7ql8K7yBiE%3D%40proton.me.

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

<p dir=3D"ltr">I fail to understand how we come from "filters do not work" =
to "filters adopted by a majority is censorship". There seems to be a confu=
sion too regarding filtering arbitrary data and censorship of consensus val=
id tx, like OFAC compliant block. Those two are different. Chris G has poin=
ted out many times as well that spam cannot be stopped with consensus rules=
 change, only via policy it can be filtered to make the spammers attempt mo=
re difficult. <br>
Invoking Satoshi by Greg Maxwell is also disingenuous when he was the first=
 to have policy in place to prevent specific script into blocks. </p>
<p dir=3D"ltr">Also the thinking that miners control the network is also ba=
d as its imposing behaviour on nodes runners such that the relay network me=
mpool should always be consistent with what gets mined.<br>
Each node is a free agent that determine what its mempool should be and con=
versely miners are the one that should take notice of what the relay networ=
k homogeneous mempool is. <br>
This BIP proposal move in the right direction in regards to finding a compr=
omise while not disparaging anyones right as a free agent node runner.</p>
<p dir=3D"ltr">Best regards,</p>
<div class=3D"protonmail_quote"><br><br>-------- Original Message --------<=
br>On 9/26/25 2:03 PM, Garlo Nicon <garlonicon@gmail.com> wrote:<br><blockq=
uote class=3D"protonmail_quote"><div dir=3D"ltr">&gt; You cannot pick and c=
hoose which parts of a block you like and which parts are &quot;abusive&quo=
t;.<br><br>In the current implementation, yes. But if you accept a proof, t=
hat a block is valid, instead of accepting a block in plaintext, then you c=
an land on the same chain. Because after all, pruned nodes care only about =
the last 288 blocks, or something like that. If they can update their UTXO =
set, and always land on a valid chain, then they don&#39;t need transaction=
 data in plaintext. They just need to update their UTXO database in a way, =
where attacking it would require breaking ECDSA, SHA-256, or similar things=
 (a proof-based system, which would not weaken existing cryptographic assum=
ptions, would be sufficient).<br><br>And the same is true about Initial Blo=
ckchain Download. Only today, you have to download hundreds of GBs, to sync=
hronize the new node from scratch. But it can be changed, and as the size o=
f the whole chain will grow, people will be pushed, to start deploying some=
 optimizations. Otherwise, there will be even less nodes, if node operators=
 will decide to trust centralized solutions instead, or do things, which al=
ready happened in some altcoins, where people passed around an already sync=
ed node data, and trusted, that it is valid (especially in CPU-mined coins,=
 where verifying thousands blocks required similar effort, than mining a ne=
w block).</div><br><div class=3D"gmail_quote gmail_quote_container"><div di=
r=3D"ltr" class=3D"gmail_attr">pt., 26 wrz 2025 o 02:25=C2=A0Andrew Poelstr=
a &lt;<a href=3D"mailto:apoelstra@wpsoftware.net">apoelstra@wpsoftware.net<=
/a>&gt; napisa=C5=82(a):<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">On Thu, Sep 25, 2025 at 11:52:02AM -0600, Chris Guida wrote:<br>
&gt; <br>
&gt; Anyway, forcing users to relay transactions they consider abusive if t=
hey<br>
&gt; want to relay any transactions at all does not seem in keeping with<br=
>
&gt; bitcoin&#39;s ethos, not to mention that it obviously would never work=
.<br>
&gt;<br>
<br>
Once a transaction is in a block, you need to relay the transaction if<br>
you want to relay a block. You cannot pick and choose which parts of a<br>
block you like and which parts are &quot;abusive&quot;. This is what it mea=
ns for<br>
something to be a consensus system.<br>
<br>
The purpose of the mempool is to approximate the contents of blocks,<br>
both to help individual node operators (who would otherwise get large<br>
quantities of &quot;surprise transactions&quot; with every block) and to he=
lp the<br>
network (which would otherwise have poor propagation properties).<br>
<br>
Any sort of filtering beyond that done by miners is contrary to this<br>
purpose of the mempool. This is a technical fact. It has nothing to do<br>
with &quot;bitcoin&#39;s ethos&quot;, except its ethos as a consensus syste=
m, which<br>
directly contradicts your point.<br>
<br>
-- <br>
Andrew Poelstra<br>
Director, Blockstream Research<br>
Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferrer" ta=
rget=3D"_blank">wpsoftware.net</a><br>
Web:=C2=A0 =C2=A0<a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noref=
errer" target=3D"_blank">https://www.wpsoftware.net/andrew</a><br>
<br>
The sun is always shining in space<br>
=C2=A0 =C2=A0 -Justin Lewis-Webster<br>
<br>
-- <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%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/aNXRSd7ygh6NqE1V%40mail.wpsoftware.net" rel=3D"noreferrer" targe=
t=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/aNXRSd7ygh6NqE1V%=
40mail.wpsoftware.net</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">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAN7kyNgxnKoX7OBLOiHZWLg%2B9rvisbpmEMrs9RsSMDfeT-sw3w%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAN7kyNgxnKoX7OBLOiHZWLg%2B9rvisbpmEMrs9RsSMDfeT-sw3w%40ma=
il.gmail.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">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/Rr9InzRLdLOAtNdtSzmgBmCX634eSgDHEPS4fW-0WCCA31XHfbTSWQ1tweH0GeNh=
H9BhCREn_2sU5AR2SmXXgOm8SpkkVwciq7ql8K7yBiE%3D%40proton.me?utm_medium=3Dema=
il&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/Rr9Inz=
RLdLOAtNdtSzmgBmCX634eSgDHEPS4fW-0WCCA31XHfbTSWQ1tweH0GeNhH9BhCREn_2sU5AR2S=
mXXgOm8SpkkVwciq7ql8K7yBiE%3D%40proton.me</a>.<br />

--b1=_cCigssFrm44rP8i3LxII1amzbsHUZR0D1L9d9itfq8--