Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts

From: Anthony Towns <[email-masked]>
Date: Mon, 6 Oct 2025 17:18:39 +1000

On Thu, Sep 25, 2025 at 11:33:29PM +0000, Andrew Poelstra wrote:
> 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...]

I think that's too strong a claim. The purpose of your mempool on your
node on your PC is whatever you want it to be -- eg, I have a node that
has a mempool with an expiry time of 2 years instead of the default 7
days, because I wanted to see if low fee txs eventually got resolved in
some way after long high fee periods.

For many things, approximating the transactions that an economically
rational miner would put in the next block is great:

 * if you're a miner yourself, you maximise your revenue if you happen
   to get the next block (since that's how "economically rational"
   is usually defined)

 * if you're sending transactions, it helps you predict if/when your
   tx will be included in a block, and helps you figure out what fee
   rate you should use

 * it helps you reconstruct and relay blocks more quickly (and relaying
   blocks more quickly helps others reconstruct blocks more quickly)

 * if you're sharing utxos with someone (lightning, or potentially ark
   or DLC bets), it helps give you advance warning if they're initiating
   a spend of that utxo in case you need to react to it

Even so, "approximate" is doing a chunk of work here: given the
possibility of (a) broadcasting double spends, (b) inconsistent
propagation, (c) new relay features, (d) some miners not being perfectly
economically rational, and (e) software not being bug free, the next block
can only be approximated, and we should (and largely do!) still perform
these tasks well even when we can't accurately predict the next block.

But if our software does degrade gracefully in the face of bad
predictions, it seems to me there's plenty of room for a "live and let
live" attitude here, not only with respect to accepting whatever silly
transactions people are willing to spend fees on, but also allowing
people to configure the software they run to match their preferences,
even if that's not optimal behaviour when measured by either efficiency
or economic metrics.

> [...and] to help the
> network (which would otherwise have poor propagation properties).

One case where approximating the next block doesn't actually add very
much value is related to transaction propagation:

 * if you want to help Bitcoin be good surveillance-free money, then
   receiving other people's transactions and relaying them without
   keeping logs of where/when the tx arrived can help improve other
   Bitcoin users' privacy.

   That might be to help users avoid miners charging personalised
   transaction fees, criminals figuring out who to attack/extort, or
   authoritarian governments attempting to restrict trade or confiscate
   funds from political opponents, eg. That can benefit both senders,
   recipients and miners, all of whom might otherwise be subject to
   unwanted attempts at coercion, if their financial activities couldn't
   be kept private.

For nodes that aren't mining, aren't used for fee estimation, don't need
extremely quick tip updates, and don't need advance notice of updates to
shared utxos, then exercising some discretion in which transactions they
help anonymise doesn't seem very harmful, and running a node that helps
to anonymise some transactions seems superior to running a blocks-only
node and not doing that for any transactions.

As far as "degrade gracefully" goes, as far as I can tell, there are
historical reasons to be concerned there, because the difference between
Bitcoin's block relay performance pre-2016 and today is significant;
with historical relay latency resulting in orphan rates on the order of
10 times higher than today (ie ~1% rather than ~0.1%). However a variety
of factors contribute to that difference, including:

 * compact blocks only relaying a short id for txs that are already present
 * high-bandwidth compact blocks avoiding a network round-trip if all
   txs are already present
 * compact block forwarding prior to full validation of the block
 * better validation performance
 * general performance improvements (CPU, memory, disk, networking)

Filtering and inconsistent mempools only stops us from avoiding the
network round-trip, which as far as I can see gives something on the
order of a 0.17% overall cost increase [0], rather than the ~0.9%
increase you'd expect from undoing all those improvements.

[0] https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3318779164
    is how I arrived at that figure

Cheers,
aj

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aONtT7Jh0M3IXhHd%40erisian.com.au.