Thanks for the feedback William.

I have reports of a 33 minute full mainnet initial block download in v3, with full height history index on a 32mb RAM machine, and we still have a few optimizations left. Excited to see what we get at 128mb and more cores.

We're close to v3 release, so I would put any such policy in there. It would consist of a deadline timer on the tx pool, timeout config setting, per entry time stamp, and thread safe pool scan/update on timeout, with timer reinitialization. Sound about right?

No promises on timing. I'm planning to post notice of a v3 release candidate within a week. I would tackle this after that. You could also prob add this yourself in v2 without much difficulty.

e

> On Aug 10, 2016, at 11:27 AM, William Swanson <swansontec@???> wrote:
>
> Hello,
> Our libbitcoin infrastructure has been humming along quietly in the
> background with no major hiccups for the past several months, so yay!
> Things are pretty awesome, and the new block-download work that's been
> going in looks even more amazing.
>
> One thing we've noticed through our customer support department is
> that old unconfirmed transactions don't get dropped in a predictable
> way. If the network is flooded with activity, unconfirmed transactions
> may be dropped in a few hours, but it the network is slow, it may be
> days. We've had a few cases where we needed to restart our libbitcoin
> servers to clear some large transactions out of the mempool for our
> customers. Is there any way to configure the mempool based on a
> timeout, so any transaction over X hours old will be dropped?
>
> We can obviously implement this sort of logic client-side, but we
> thought we'd check to see if the server already supported that first.
>
> Thanks for all the hard work,
> -William
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin