On Fri, Jan 31, 2025 at 12:02:56PM +0000, 'ArmchairCryptologist' via Bitcoin Development Mailing List wrote: > Is expiration-based mempool eviction necessary or even desirable anymore? I'm > consistently seeing unconfirmed transactions from months ago being > rebroadcast and (now that the mempool is draining) eventually confirming, > without anyone even trying to exploit anything. So from what I can tell, the > only thing this really accomplishes is wasting CPU cycles and bandwidth > evicting and later re-accepting the transactions in question.
All it would take is one person running a rebroadcasting service to make mempool eviction useless except in the rare case that a soft-fork of standard transactions has happened. Although even then, arguably you are better off not wasting bandwidth re-accepting those transactions over and over again. > You were never able to rely on unconfirmed transactions ever going away > without double-spending one of the inputs in the first place, and full-RBF is > even a thing now, so this will always be possible. Agreed. > The mempool is capped by size anyway, so while I may be missing something, I > cannot honestly see any good reasons to keep this mechanism at all, > especially if it can be used as a vector for attacks. > > The only drawback I can think of is that abandontransaction currently does > not work if a transaction is in the mempool, but it would probably be better > to improve it so it actually evicts the transaction from the mempool of the > local node if necessary. Agreed. I've run into this problem before myself. -- 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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z6KJFvikr27e7Igk%40petertodd.org.
signature.asc
Description: PGP signature
