Those are pretty impressive numbers for sync times.

The approach you describe sounds very similar to what we were
thinking. If you do implement it in a v3 release, we will be sure to
switch it on!

If not, we can probably do a better job pruning transactions in our
client (and this would apply to transactions fetched over Stratum as
well). As far as the server goes, this is more of a "nice to have"
than an essential feature.

-William

On Wed, Aug 10, 2016 at 12:41 PM, Eric Voskuil <eric@???> wrote:
> 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