Subject: [bitcoindev] Transaction expiration should be based on the most recent transaction in a group, not the first

From: Peter Todd <[email-masked]>
Date: Tue, 28 Jan 2025 22:25:55 +0000

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