From: "/dev /fd0" <alicexbtong@gmail•com>
To: Andrew Poelstra <apoelstra@wpsoftware•net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
Date: Mon, 29 Sep 2025 19:11:34 +0530 [thread overview]
Message-ID: <CALiT-ZqxbLmRDuWMqubYDeSvawSg0xgQ8khet+w6YTJKy7aqeQ@mail.gmail.com> (raw)
In-Reply-To: <aNnIvR5Naea8pXCe@mail.wpsoftware.net>
[-- Attachment #1: Type: text/plain, Size: 6610 bytes --]
Hi Andrew,
> User experience is bad when every 10 minutes a block comes in and your
> laptop fan spins up and your software freezes because your computer is
> suddenly processing a whole block of transactions at once. It's bad when
> Netflix needs to pause and re-cache every 10 minutes because your
> network connection is saturated by a whole block.
> Both of these things happened to me constantly before compact blocks.
Have you tested compact blocks relay with default
`blockreconstructionextratxn` in knots v29.1?
/dev/fd0
floppy disk guy
On Mon, Sep 29, 2025, 5:37 AM Andrew Poelstra <apoelstra@wpsoftware•net>
wrote:
> On Fri, Sep 26, 2025 at 03:50:09PM -0600, Chris Guida wrote:
> >
> > >Yes, it is a "new purpose" introduced almost a decade ago to allow
> Bitcoin
> > to scale without unnecessarily causing load on nodes
> >
> > Yes, and my point here is that you seem to be implying that the *only*
> > purpose of the mempool is to make blocks propagate faster, and if that
> were
> > true, then I would agree with you that spam filters are harmful. But
> since
> > the mempool predates CBR by several years, your claim cannot be true.
> >
>
> I certainly didn't mean to imply that the only purpose of the mempool
> was to improve block propagation -- it is also useful for nodes to
> validate transactions and cache signature validity and UTXO set updates,
> something which filters are also harmful for.
>
> <snip>
>
> >
> > Your point about node decentralization being paramount is also why core
> > devs should listen to their users when they report UX difficulties. If
> the
> > experience of running a node is bad, very few will do it. (I can assure
> you
> > that the experience of running a useful merchant node is bad).
> >
>
> User experience is bad when every 10 minutes a block comes in and your
> laptop fan spins up and your software freezes because your computer is
> suddenly processing a whole block of transactions at once. It's bad when
> Netflix needs to pause and re-cache every 10 minutes because your
> network connection is saturated by a whole block.
>
> Both of these things happened to me constantly before compact blocks.
>
> <snip>
>
> > >If the dust filter, transaction size filters, standardness limits, etc.,
> > were being ignored by miners then they should be removed, yes.
> >
> > Really? This should be trivial to achieve simply by launching a shitcoin
> > metaprotocol on top of one of these filtered tx formats. At that point
> node
> > DoS attacks would become more commonplace, no?
> >
> > >Some of these exist for historical reasons and others for performance
> > reasons, and in the latter case there might be a movement to enforce the
> > old rules in consensus.
> >
> > Interesting, so you're saying if someone launches a shitcoin metaprotocol
> > on top of txs that are DoS vectors, then that might generate support for
> > the Great Consensus Cleanup? Hmm...
> >
>
> Yes, you could try something like this, though this plan has a movie-plot
> level of complexity and you are likely to fail at the first step where
> you try to meme something into existence based on some obscure technical
> thing :).
>
> > >But if it came to "mempool policy vs miner policy" then it is in the
> > interest of both node operators and the network's health to change the
> > mempool policy.
> >
> > Again, this seems like a slippery slope toward stuffing blocks full of
> data
> > garbage rather than payments. You're basically saying miners should be in
> > charge of bitcoin, and that non-mining nodes should have no mechanism by
> > which to push back on miners. Am I misunderstanding?
> >
>
> Non-mining nodes push back on miners by validating transactions (and
> their ability to do so is constrained by resource usage, which filtering
> increases). This prevents miners from processing tranasctions that
> violate the rules of the network.
>
> But nodes have no ability to constrain miners' behavior if that behavior
> is within the rules of the network -- except by coordinating to execute
> a fork to change the consensus rules.
>
> <snip>
>
> > That is not what the data show. First, the opreturn filter results in a
> 99%
> > reduction in confirmed nonstandard opreturns. Second, the dust filter
> > itself was implemented as a result of spam attacks, and it has been
> > perfectly effective since the moment it was implemented. Again, the
> purpose
> > of spam filtration is not to eliminate 100% of spam. The purpose is to
> > raise costs on spammers. Your email spam filter likely leaks a few spam
> > emails once in a while, but I guarantee your reaction is not "it doesn't
> > work; let's get rid of it".
> >
>
> Your "99%" number is silly. I could produce a hundred billion
> transactions that violate some policy rule, send them to my local node
> which will reject them, and then claim that the policy rule was
> 99.9999999% effective at filtering out such transactions. My point is
> that there's no meaningful way to count "transactions that exist but are
> neither propagated nor in blocks".
>
> Mempool policy makes it inconvenient for people to use transactions that
> violate the mempool policy. It may discourage them from building
> protocols that require such transactions. But this discouragement has no
> monetary value, which means that as soon as there is any economic
> interest in producing such transactions, they will be produced and they
> will wind up in blocks. This is what we see -- and it's why we are
> talking about eliminating the data carrier filters and not about
> eliminating, say, the MINIMALIF rule on pre-segwit transactions.
>
> <snip>
>
> --
> 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 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/aNnIvR5Naea8pXCe%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/bitcoindev/CALiT-ZqxbLmRDuWMqubYDeSvawSg0xgQ8khet%2Bw6YTJKy7aqeQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8543 bytes --]
next prev parent reply other threads:[~2025-09-29 15:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 13:26 Andrew Poelstra
2025-09-26 21:50 ` Chris Guida
2025-09-28 23:46 ` Andrew Poelstra
2025-09-29 13:11 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-09-29 13:41 ` /dev /fd0 [this message]
[not found] ` <CALL0pNF4b+rNYrgws0QY_LQP6QeVMEhLiOrFL4f-H3Ahf2ePDw@mail.gmail.com>
2025-09-29 15:24 ` Lőrinc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALiT-ZqxbLmRDuWMqubYDeSvawSg0xgQ8khet+w6YTJKy7aqeQ@mail.gmail.com \
--to=alicexbtong@gmail$(echo .)com \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox