From: "'Russell O'Connor' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: 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 09:11:04 -0400 [thread overview]
Message-ID: <CAMZUoKkU+YnA_HorhGCwQqmLsnPZ8cqf1MJ_U3CE8j1+NgJV4w@mail.gmail.com> (raw)
In-Reply-To: <aNnIvR5Naea8pXCe@mail.wpsoftware.net>
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
On Sun, Sep 28, 2025 at 8:07 PM Andrew Poelstra <apoelstra@wpsoftware•net>
wrote:
>
> 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.
I fully agree that this discouragement has little monetary value. As we
can see today, folks are bypassing the existing default mempool minfree
rate of 1sat/vbyte and still managing to fill up blocks with these sorts of
sub-1sat/vbyte transactions. This lets us measure the monetary cost of
bypassing default mempool filters. The cost is less than the cost savings
that such folks are achieving by their sub-1sat/vbyte transaction.
Eyeballing it, I see that the cost of bypassing default filters is
something less than 0.3sat/vbyte or so. Probably there was initially some
upfront cost, which is now being amortized.
I'm glad to hear that the default minfree rate is being lowered. I'd even
support eliminating the minfee entirely and instead relying on the max
mempool size alone.
Also, as Andrew touched on, one valuable role of filters is to try and
filter out third-party malleable transactions to the extent reasonably
possible, or at least filter out their non-canonical / non-min-cost forms.
That is valuable because those sorts of transactions are at great risk of
never appearing in blocks.
--
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/CAMZUoKkU%2BYnA_HorhGCwQqmLsnPZ8cqf1MJ_U3CE8j1%2BNgJV4w%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2860 bytes --]
next prev parent reply other threads:[~2025-09-29 13:12 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 [this message]
2025-09-29 13:41 ` /dev /fd0
[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=CAMZUoKkU+YnA_HorhGCwQqmLsnPZ8cqf1MJ_U3CE8j1+NgJV4w@mail.gmail.com \
--to=bitcoindev@googlegroups.com \
--cc=roconnor@blockstream$(echo .)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