📅 Original date posted:2014-08-05
📝 Original message: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
metric.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140805/aeb32c14/attachment.html>;
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 15:24:41
in reply to nevent1q…yund
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 15:24:41Event JSON
{
"id": "15f6de8254b0683dd2d1c209a2259b7083919f5fe030a840d2766020dc55d1c0",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686151481,
"kind": 1,
"tags": [
[
"e",
"862ea3dc96b72bff70fc377e79d0d6efd56d14bf0babb9aa995ab55fc1b92d18",
"",
"root"
],
[
"e",
"0863d1f6179fea9a8f6b126577994f2a1a7735a5ff930d714da0b0d0ed93c737",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-08-05\n📝 Original message:I feel like a lot of this will be driven by implementation, and costs of\nchanging the implementation. Additional look-backs are of course doable,\nbut they incur some disk I/O costs. The fields available in memory for\neach mempool TX are\n\n uint256 tx_hash; // hash of next field\n CTransaction tx;\n int64_t nFee; // Cached to avoid expensive parent-transaction lookups\n size_t nTxSize; // ... and avoid recomputing tx size\n int64_t nTime; // Local time when entering the mempool\n double dPriority; // Priority when entering the mempool\n unsigned int nHeight; // Chain height when entering the mempool\n\nAs a first pass, we may prune the mempool without additional db lookups\nquite easily based on time criteria. Or, additional in-memory indexes may\nbe constructed to maintain hashes ordered by priority/fees.\n\nThose techniques seem likely to be attempted before resorting to looking\nback two or three TXs deep at coin age -- which I admit is an interesting\nmetric.\n\n-- \nJeff Garzik\nBitcoin core developer and open source evangelist\nBitPay, Inc. https://bitpay.com/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140805/aeb32c14/attachment.html\u003e",
"sig": "c82a11e91177aa32e95abdf2fab9c56cd86035d4c77ffa806f592b15acaf65334cd01f4d59fc86ae3f74016b2b371b56ec28d9ad5957f87f51881eaf4eecc743"
}