Transaction expiration should be based on the most recent transaction in a group

[Sufix3]

Disclaimer: Peter Todd 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 BTCitcoin 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();
   }

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?

Ref _ Peter Todd

[stwenhao]

This post was copy-pasted from the mailing list: https://groups.google.com/g/bitcoindev/c/OWxX-o4FffU

[Sufix3]

This post was copy-pasted from the mailing list: https://groups.google.com/g/bitcoindev/c/OWxX-o4FffU

well dipshit, im not trying to know how it came about. i want to know other peoples opinion about the code 

[DannyHamilton]

This post was copy-pasted from the mailing list: https://groups.google.com/g/bitcoindev/c/OWxX-o4FffU

- snip -
im not trying to know how it came about. i want to know other peoples opinion about the code 

Perhaps consider editing your initial post on this thread to indicate that this was something that Peter Todd brought up 2 days ago elsewhere (even better, also link to that source) and not an original thought of your own?

Plagiarism isn't a good look, but stating sources goes a long way toward establishing genuine curiosity.

[ABCbits]

I won't comment about the code, but i have opinion about problem mentioned by Peter Todd.

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.

Unless the old transaction is about to be dropped (either because lower fee rate compared with other TX on mempool or almost 2 weeks since broadcasted), doing proper CPFP allows all involved TX confirmed within next few blocks.

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.

This is definitely concerning, but it assume major mining pool use default behavior (such as 300MB mempool and drop TX on mempool after 2 weeks). There's possibility attacker lose small amount of money if one or more mining pool modify the behavior (to >300MB and >2 week limit.

This post was copy-pasted from the mailing list: https://groups.google.com/g/bitcoindev/c/OWxX-o4FffU

And looking at https://ninjastic.space/post/65006434, he also forget to copy last part of Peter Todd's post.

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