From: Anthony Towns <aj@erisian•com.au>
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, 6 Oct 2025 17:18:39 +1000 [thread overview]
Message-ID: <aONtT7Jh0M3IXhHd@erisian.com.au> (raw)
In-Reply-To: <aNXRSd7ygh6NqE1V@mail.wpsoftware.net>
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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aONtT7Jh0M3IXhHd%40erisian.com.au.
next prev parent reply other threads:[~2025-10-06 7:55 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 18:18 Aiden McClelland
2025-09-24 18:46 ` Greg Maxwell
2025-09-24 18:54 ` Aiden McClelland
2025-09-24 22:49 ` Greg Maxwell
2025-09-25 9:21 ` yes_please
2025-09-25 20:03 ` Greg Maxwell
2025-09-25 20:51 ` Aiden McClelland
2025-09-25 21:14 ` Greg Maxwell
2025-09-25 21:25 ` Aiden McClelland
2025-09-25 21:51 ` Greg Maxwell
2025-09-26 2:06 ` Chris Riley
2025-09-26 2:17 ` Aiden McClelland
2025-09-26 2:28 ` Chris Riley
2025-09-27 1:30 ` 'Aiden McClelland' via Bitcoin Development Mailing List
2025-10-01 21:57 ` Greg Maxwell
2025-09-25 17:52 ` Chris Guida
2025-09-25 20:46 ` Greg Maxwell
2025-09-25 21:02 ` Chris Guida
2025-09-25 23:33 ` Andrew Poelstra
2025-09-26 7:58 ` Garlo Nicon
2025-09-27 14:44 ` 'OJ' via Bitcoin Development Mailing List
2025-09-27 16:49 ` Bryan Bishop
2025-10-06 7:18 ` Anthony Towns [this message]
2025-09-24 19:16 ` Chris Guida
2025-09-24 20:01 ` Greg Maxwell
2025-09-25 2:20 ` bigshiny
2025-09-25 14:33 ` Luke Dashjr
2025-09-28 1:22 ` /dev /fd0
2025-09-30 4:21 ` 'Aiden McClelland' via Bitcoin Development Mailing List
2025-09-30 21:09 ` jeremy
2025-09-30 22:44 ` 'Aiden McClelland' via Bitcoin Development Mailing List
2025-10-01 3:39 ` Dingocoin
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=aONtT7Jh0M3IXhHd@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--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