Sadeeq raised a potential issue with time-based expiry of mempool transactions whereby a transaction that is likely to be mined in the next block could be evicted. David responded with a great history of time-based mempool expiry. After reading the thread, I’m not particularly convinced we need to index by time, but I would like to know how many transactions are expired due to the default timeout of 2 weeks.
I came across this issue when researching what it would take to remove the boost multi-index from Bitcoin Core dependencies. No matter the approach, removing time as a key would greatly simplify the patch-set.
This is probably derivable from the other data offers, but I thought I would post this for discussion anyway.