public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: bitcoindev@googlegroups.com
Subject: [bitcoindev] Transaction expiration should be based on the most recent transaction in a group, not the first
Date: Tue, 28 Jan 2025 22:25:55 +0000	[thread overview]
Message-ID: <Z5lZc28t9-tCxdHN@petertodd.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2798 bytes --]

Disclaimer: I haven't actually tested this. So there is a chance I'm
understanding the code entirely wrong. If so, feel free to make fun of
me for being too lazy to actually test this.


In Bitcoin Core, mempool expiration is done by:

	int CTxMemPool::Expire(std::chrono::seconds time)
	{
	    AssertLockHeld(cs);
	    indexed_transaction_set::index<entry_time>::type::iterator it = mapTx.get<entry_time>().begin();
	    setEntries toremove;
	    while (it != mapTx.get<entry_time>().end() && it->GetTime() < time) {
		toremove.insert(mapTx.project<0>(it));
		it++;
	    }    
	    setEntries stage;
	    for (txiter removeit : toremove) {
		CalculateDescendants(removeit, stage);
	    }    
	    RemoveStaged(stage, false, MemPoolRemovalReason::EXPIRY);
	    return stage.size();
	}

	https://github.com/bitcoin/bitcoin/blob/b432e367427f1f9fe0f0a5800e31e496f00cd38d/src/txmempool.cpp#L1086

This function is expiring transactions based on their entry time into
the mempool, a value that is set once and never changed. Transactions
are removed unconditionally on expiration, whether or not they have
descendents. That means that if you broadcast A, wait just prior to A's
expiration, and broadcast B, a transaction spending an output of A, B
will be evicted immediately when A's expiration time is reached.

There's at least three problems with this:

1) It's dumb. If I do a CPFP on an old transaction, I want that
   transaction to get mined and am willing to pay money. It's silly to make
   me jump through the hoop of rebroadcasting it again when it expires.

2) It's a free-relay DoS attack: just prior to A expiring, I could
   broadcast B, a very large transaction, and use up bandwidth for "free".
   Frankly, I'm not very concerned about this. But if you care, you
   should fix this.

3) Expiration could maybe be leveraged in transaction cycling attacks:
   https://stacker.news/items/866680

Personally, I'm not convinced that transaction expiration is actually a
good idea. The best argument for it IMO is in the case of some
soft-fork-style screwup where you're allowing stuff into your mempool
that will never get mined. But that means something is seriously wrong
to begin with - you probably should fix that. Otherwise, it's not
uncommon for transactions that are months old to eventually get mined.
Do we really need to waste bandwidth re-relaying them in the meantime?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
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/Z5lZc28t9-tCxdHN%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

             reply	other threads:[~2025-01-28 23:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 22:25 Peter Todd [this message]
2025-01-31 12:02 ` [bitcoindev] Transaction expiration should be based on the most recent transaction in a group, not the first 'ArmchairCryptologist' via Bitcoin Development Mailing List

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=Z5lZc28t9-tCxdHN@petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoindev@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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