I feel like a lot of this will be driven by implementation, and costs of
changing the implementation.  Additional look-backs are of course doable,
but they incur some disk I/O costs.  The fields available in memory for
each mempool TX are

    uint256 tx_hash; // hash of next field
    CTransaction tx;
    int64_t nFee; // Cached to avoid expensive parent-transaction lookups
    size_t nTxSize; // ... and avoid recomputing tx size
    int64_t nTime; // Local time when entering the mempool
    double dPriority; // Priority when entering the mempool
    unsigned int nHeight; // Chain height when entering the mempool

As a first pass, we may prune the mempool without additional db lookups
quite easily based on time criteria.  Or, additional in-memory indexes may
be constructed to maintain hashes ordered by priority/fees.

Those techniques seem likely to be attempted before resorting to looking
back two or three TXs deep at coin age -- which I admit is an interesting

Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
Bitcoin-development mailing list

Reply via email to