Mempool transaction expiration should depend on the latest transaction in a group

Just a heads up: Peter Todd actually tried this out. So, I might be getting the code all wrong. If that's the case, go ahead and roast me for not bothering to test it myself. In Bitcoin Core, the way they handle mempool expiration is through this function: 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 piece of code expires transactions based on when they entered the mempool, and that timestamp is set once and never updated. So, when a transaction expires, it gets booted out without considering if it has any child transactions. This means if you send out transaction A, wait until it’s about to expire, and then send B, which spends from A, B gets kicked out right when A’s expiration hits. There are at least three issues with this: 1) It’s pretty dumb. If I'm doing CPFP on an old transaction, I want it to get mined and I'm willing to pay for it. It’s just ridiculous to make me resend it when it expires. 2) It opens the door for a free-relay DoS attack: right before A expires, I could send B, a huge transaction...

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

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.

I won't comment about the code, but i have opinion about problem mentioned by Peter Todd. 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. 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. And looking at https://ninjastic.space/post/65006434, he also forget to copy last part of Peter Todd's post.