Mempool "Expected Byte Stay" policy [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-07-16T16:50:58+00:00


Summary:

In a discussion on the bitcoin-dev mailing list, there was a debate about whether a block or time-based system should be used to determine when transactions and their dependents should be evicted from the mempool. Thomas Zander suggested using a number of blocks, while Tom Harding argued that a time-based system would be more beneficial for users and wallets.Zander's proposal was based on the idea that using blocks would allow users to know when they should rebroadcast their transaction and consider increasing the fee. However, Harding pointed out that block mining times are not guaranteed in the future, and a sudden change could cause issues for the mempool. This led to a disagreement about which method would be best for managing the mempool.The discussion then turned to Rule 2, which currently states that a transaction and its dependents will be evicted on its 2-hour anniversary, regardless of whether space is required or not. Harding suggested using a number of blocks instead of two hours, as this would provide clearer guidance for users and wallets. Zander did some calculations and found that using 12 blocks would result in a 5% chance of having to wait three hours, while using 120 minutes would only have a .23% chance of fewer than four blocks occurring.The author of the context is facing a problem with spammers using up their fullnode resources. To address this issue, they have made changes to the mempool management. They have set a maximum size for the mempool and are allocating space based on a simple rule. The cost of holding a transaction in the mempool is measured by "expected byte stay," which takes into account the size of the transaction and the expected number of blocks needed for confirmation.When there is not enough space for a new transaction, the author tries to make space by evicting transactions with a higher expected byte stay than the new transaction. However, the author is not concerned about fees except for their impact on confirmation time, coin age, CPFP, and replacement. Currently, a transaction and its dependents are evicted on its two-hour anniversary, regardless of whether space is required or not.The author has implemented a new fee estimation system and periodically applies the latest expectedBlocksToConfirm(feeRate) table to the entire mempool. They have faith in this new system, particularly its size independence. However, there is a possibility of clog-ups caused by transactions that appear to be confirmed in the next block but end up being delayed due to factors other than fees.The author plans to provide updates on how the new system works out in addressing the spamming issue and managing the mempool effectively.


Updated on: 2023-08-01T14:20:25.858587+00:00