You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

txmempool.h 5.1KB

estimatefee / estimatepriority RPC methods New RPC methods: return an estimate of the fee (or priority) a transaction needs to be likely to confirm in a given number of blocks. Mike Hearn created the first version of this method for estimating fees. It works as follows: For transactions that took 1 to N (I picked N=25) blocks to confirm, keep N buckets with at most 100 entries in each recording the fees-per-kilobyte paid by those transactions. (separate buckets are kept for transactions that confirmed because they are high-priority) The buckets are filled as blocks are found, and are saved/restored in a new fee_estiamtes.dat file in the data directory. A few variations on Mike's initial scheme: To estimate the fee needed for a transaction to confirm in X buckets, all of the samples in all of the buckets are used and a median of all of the data is used to make the estimate. For example, imagine 25 buckets each containing the full 100 entries. Those 2,500 samples are sorted, and the estimate of the fee needed to confirm in the very next block is the 50'th-highest-fee-entry in that sorted list; the estimate of the fee needed to confirm in the next two blocks is the 150'th-highest-fee-entry, etc. That algorithm has the nice property that estimates of how much fee you need to pay to get confirmed in block N will always be greater than or equal to the estimate for block N+1. It would clearly be wrong to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay 12 uBTC and it will take LONGER". A single block will not contribute more than 10 entries to any one bucket, so a single miner and a large block cannot overwhelm the estimates.
7 years ago
estimatefee / estimatepriority RPC methods New RPC methods: return an estimate of the fee (or priority) a transaction needs to be likely to confirm in a given number of blocks. Mike Hearn created the first version of this method for estimating fees. It works as follows: For transactions that took 1 to N (I picked N=25) blocks to confirm, keep N buckets with at most 100 entries in each recording the fees-per-kilobyte paid by those transactions. (separate buckets are kept for transactions that confirmed because they are high-priority) The buckets are filled as blocks are found, and are saved/restored in a new fee_estiamtes.dat file in the data directory. A few variations on Mike's initial scheme: To estimate the fee needed for a transaction to confirm in X buckets, all of the samples in all of the buckets are used and a median of all of the data is used to make the estimate. For example, imagine 25 buckets each containing the full 100 entries. Those 2,500 samples are sorted, and the estimate of the fee needed to confirm in the very next block is the 50'th-highest-fee-entry in that sorted list; the estimate of the fee needed to confirm in the next two blocks is the 150'th-highest-fee-entry, etc. That algorithm has the nice property that estimates of how much fee you need to pay to get confirmed in block N will always be greater than or equal to the estimate for block N+1. It would clearly be wrong to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay 12 uBTC and it will take LONGER". A single block will not contribute more than 10 entries to any one bucket, so a single miner and a large block cannot overwhelm the estimates.
7 years ago
estimatefee / estimatepriority RPC methods New RPC methods: return an estimate of the fee (or priority) a transaction needs to be likely to confirm in a given number of blocks. Mike Hearn created the first version of this method for estimating fees. It works as follows: For transactions that took 1 to N (I picked N=25) blocks to confirm, keep N buckets with at most 100 entries in each recording the fees-per-kilobyte paid by those transactions. (separate buckets are kept for transactions that confirmed because they are high-priority) The buckets are filled as blocks are found, and are saved/restored in a new fee_estiamtes.dat file in the data directory. A few variations on Mike's initial scheme: To estimate the fee needed for a transaction to confirm in X buckets, all of the samples in all of the buckets are used and a median of all of the data is used to make the estimate. For example, imagine 25 buckets each containing the full 100 entries. Those 2,500 samples are sorted, and the estimate of the fee needed to confirm in the very next block is the 50'th-highest-fee-entry in that sorted list; the estimate of the fee needed to confirm in the next two blocks is the 150'th-highest-fee-entry, etc. That algorithm has the nice property that estimates of how much fee you need to pay to get confirmed in block N will always be greater than or equal to the estimate for block N+1. It would clearly be wrong to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay 12 uBTC and it will take LONGER". A single block will not contribute more than 10 entries to any one bucket, so a single miner and a large block cannot overwhelm the estimates.
7 years ago
estimatefee / estimatepriority RPC methods New RPC methods: return an estimate of the fee (or priority) a transaction needs to be likely to confirm in a given number of blocks. Mike Hearn created the first version of this method for estimating fees. It works as follows: For transactions that took 1 to N (I picked N=25) blocks to confirm, keep N buckets with at most 100 entries in each recording the fees-per-kilobyte paid by those transactions. (separate buckets are kept for transactions that confirmed because they are high-priority) The buckets are filled as blocks are found, and are saved/restored in a new fee_estiamtes.dat file in the data directory. A few variations on Mike's initial scheme: To estimate the fee needed for a transaction to confirm in X buckets, all of the samples in all of the buckets are used and a median of all of the data is used to make the estimate. For example, imagine 25 buckets each containing the full 100 entries. Those 2,500 samples are sorted, and the estimate of the fee needed to confirm in the very next block is the 50'th-highest-fee-entry in that sorted list; the estimate of the fee needed to confirm in the next two blocks is the 150'th-highest-fee-entry, etc. That algorithm has the nice property that estimates of how much fee you need to pay to get confirmed in block N will always be greater than or equal to the estimate for block N+1. It would clearly be wrong to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay 12 uBTC and it will take LONGER". A single block will not contribute more than 10 entries to any one bucket, so a single miner and a large block cannot overwhelm the estimates.
7 years ago
estimatefee / estimatepriority RPC methods New RPC methods: return an estimate of the fee (or priority) a transaction needs to be likely to confirm in a given number of blocks. Mike Hearn created the first version of this method for estimating fees. It works as follows: For transactions that took 1 to N (I picked N=25) blocks to confirm, keep N buckets with at most 100 entries in each recording the fees-per-kilobyte paid by those transactions. (separate buckets are kept for transactions that confirmed because they are high-priority) The buckets are filled as blocks are found, and are saved/restored in a new fee_estiamtes.dat file in the data directory. A few variations on Mike's initial scheme: To estimate the fee needed for a transaction to confirm in X buckets, all of the samples in all of the buckets are used and a median of all of the data is used to make the estimate. For example, imagine 25 buckets each containing the full 100 entries. Those 2,500 samples are sorted, and the estimate of the fee needed to confirm in the very next block is the 50'th-highest-fee-entry in that sorted list; the estimate of the fee needed to confirm in the next two blocks is the 150'th-highest-fee-entry, etc. That algorithm has the nice property that estimates of how much fee you need to pay to get confirmed in block N will always be greater than or equal to the estimate for block N+1. It would clearly be wrong to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay 12 uBTC and it will take LONGER". A single block will not contribute more than 10 entries to any one bucket, so a single miner and a large block cannot overwhelm the estimates.
7 years ago
estimatefee / estimatepriority RPC methods New RPC methods: return an estimate of the fee (or priority) a transaction needs to be likely to confirm in a given number of blocks. Mike Hearn created the first version of this method for estimating fees. It works as follows: For transactions that took 1 to N (I picked N=25) blocks to confirm, keep N buckets with at most 100 entries in each recording the fees-per-kilobyte paid by those transactions. (separate buckets are kept for transactions that confirmed because they are high-priority) The buckets are filled as blocks are found, and are saved/restored in a new fee_estiamtes.dat file in the data directory. A few variations on Mike's initial scheme: To estimate the fee needed for a transaction to confirm in X buckets, all of the samples in all of the buckets are used and a median of all of the data is used to make the estimate. For example, imagine 25 buckets each containing the full 100 entries. Those 2,500 samples are sorted, and the estimate of the fee needed to confirm in the very next block is the 50'th-highest-fee-entry in that sorted list; the estimate of the fee needed to confirm in the next two blocks is the 150'th-highest-fee-entry, etc. That algorithm has the nice property that estimates of how much fee you need to pay to get confirmed in block N will always be greater than or equal to the estimate for block N+1. It would clearly be wrong to say "pay 11 uBTC and you'll get confirmed in 3 blocks, but pay 12 uBTC and it will take LONGER". A single block will not contribute more than 10 entries to any one bucket, so a single miner and a large block cannot overwhelm the estimates.
7 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150
  1. // Copyright (c) 2009-2010 Satoshi Nakamoto
  2. // Copyright (c) 2009-2013 The Bitcoin developers
  3. // Distributed under the MIT/X11 software license, see the accompanying
  4. // file COPYING or http://www.opensource.org/licenses/mit-license.php.
  5. #ifndef BITCOIN_TXMEMPOOL_H
  6. #define BITCOIN_TXMEMPOOL_H
  7. #include <list>
  8. #include "coins.h"
  9. #include "core.h"
  10. #include "sync.h"
  11. inline bool AllowFree(double dPriority)
  12. {
  13. // Large (in bytes) low-priority (new, small-coin) transactions
  14. // need a fee.
  15. return dPriority > COIN * 144 / 250;
  16. }
  17. /** Fake height value used in CCoins to signify they are only in the memory pool (since 0.8) */
  18. static const unsigned int MEMPOOL_HEIGHT = 0x7FFFFFFF;
  19. /*
  20. * CTxMemPool stores these:
  21. */
  22. class CTxMemPoolEntry
  23. {
  24. private:
  25. CTransaction tx;
  26. int64_t nFee; // Cached to avoid expensive parent-transaction lookups
  27. size_t nTxSize; // ... and avoid recomputing tx size
  28. int64_t nTime; // Local time when entering the mempool
  29. double dPriority; // Priority when entering the mempool
  30. unsigned int nHeight; // Chain height when entering the mempool
  31. public:
  32. CTxMemPoolEntry(const CTransaction& _tx, int64_t _nFee,
  33. int64_t _nTime, double _dPriority, unsigned int _nHeight);
  34. CTxMemPoolEntry();
  35. CTxMemPoolEntry(const CTxMemPoolEntry& other);
  36. const CTransaction& GetTx() const { return this->tx; }
  37. double GetPriority(unsigned int currentHeight) const;
  38. int64_t GetFee() const { return nFee; }
  39. size_t GetTxSize() const { return nTxSize; }
  40. int64_t GetTime() const { return nTime; }
  41. unsigned int GetHeight() const { return nHeight; }
  42. };
  43. class CMinerPolicyEstimator;
  44. /*
  45. * CTxMemPool stores valid-according-to-the-current-best-chain
  46. * transactions that may be included in the next block.
  47. *
  48. * Transactions are added when they are seen on the network
  49. * (or created by the local node), but not all transactions seen
  50. * are added to the pool: if a new transaction double-spends
  51. * an input of a transaction in the pool, it is dropped,
  52. * as are non-standard transactions.
  53. */
  54. class CTxMemPool
  55. {
  56. private:
  57. bool fSanityCheck; // Normally false, true if -checkmempool or -regtest
  58. unsigned int nTransactionsUpdated;
  59. CMinerPolicyEstimator* minerPolicyEstimator;
  60. CFeeRate minRelayFee; // Passed to constructor to avoid dependency on main
  61. uint64_t totalTxSize; // sum of all mempool tx' byte sizes
  62. public:
  63. mutable CCriticalSection cs;
  64. std::map<uint256, CTxMemPoolEntry> mapTx;
  65. std::map<COutPoint, CInPoint> mapNextTx;
  66. std::map<uint256, std::pair<double, int64_t> > mapDeltas;
  67. CTxMemPool(const CFeeRate& _minRelayFee);
  68. ~CTxMemPool();
  69. /*
  70. * If sanity-checking is turned on, check makes sure the pool is
  71. * consistent (does not contain two transactions that spend the same inputs,
  72. * all inputs are in the mapNextTx array). If sanity-checking is turned off,
  73. * check does nothing.
  74. */
  75. void check(CCoinsViewCache *pcoins) const;
  76. void setSanityCheck(bool _fSanityCheck) { fSanityCheck = _fSanityCheck; }
  77. bool addUnchecked(const uint256& hash, const CTxMemPoolEntry &entry);
  78. void remove(const CTransaction &tx, std::list<CTransaction>& removed, bool fRecursive = false);
  79. void removeConflicts(const CTransaction &tx, std::list<CTransaction>& removed);
  80. void removeForBlock(const std::vector<CTransaction>& vtx, unsigned int nBlockHeight,
  81. std::list<CTransaction>& conflicts);
  82. void clear();
  83. void queryHashes(std::vector<uint256>& vtxid);
  84. void pruneSpent(const uint256& hash, CCoins &coins);
  85. unsigned int GetTransactionsUpdated() const;
  86. void AddTransactionsUpdated(unsigned int n);
  87. /** Affect CreateNewBlock prioritisation of transactions */
  88. void PrioritiseTransaction(const uint256 hash, const std::string strHash, double dPriorityDelta, int64_t nFeeDelta);
  89. void ApplyDeltas(const uint256 hash, double &dPriorityDelta, int64_t &nFeeDelta);
  90. void ClearPrioritisation(const uint256 hash);
  91. unsigned long size()
  92. {
  93. LOCK(cs);
  94. return mapTx.size();
  95. }
  96. uint64_t GetTotalTxSize()
  97. {
  98. LOCK(cs);
  99. return totalTxSize;
  100. }
  101. bool exists(uint256 hash)
  102. {
  103. LOCK(cs);
  104. return (mapTx.count(hash) != 0);
  105. }
  106. bool lookup(uint256 hash, CTransaction& result) const;
  107. // Estimate fee rate needed to get into the next
  108. // nBlocks
  109. CFeeRate estimateFee(int nBlocks) const;
  110. // Estimate priority needed to get into the next
  111. // nBlocks
  112. double estimatePriority(int nBlocks) const;
  113. // Write/Read estimates to disk
  114. bool WriteFeeEstimates(CAutoFile& fileout) const;
  115. bool ReadFeeEstimates(CAutoFile& filein);
  116. };
  117. /** CCoinsView that brings transactions from a memorypool into view.
  118. It does not check for spendings by memory pool transactions. */
  119. class CCoinsViewMemPool : public CCoinsViewBacked
  120. {
  121. protected:
  122. CTxMemPool &mempool;
  123. public:
  124. CCoinsViewMemPool(CCoinsView &baseIn, CTxMemPool &mempoolIn);
  125. bool GetCoins(const uint256 &txid, CCoins &coins) const;
  126. bool HaveCoins(const uint256 &txid) const;
  127. };
  128. #endif /* BITCOIN_TXMEMPOOL_H */