Author: Jeff Garzik 2012-09-23 20:30:20
Published on: 2012-09-23T20:30:20+00:00
In a mailing list, Mike Hearn asked if anyone had long term longs that contained the pool size and timestamps. He forgot to enable timestamps in the logs for his own nodes, which made it difficult to track the increasing number of pending transactions that don't get cleared into blocks. One of his nodes now routinely has 4000 transactions in the mempool. Blocks typically clear only a few hundred at most, which is what you'd expect given current transaction rates (around 300 per ten minute interval). Similarly, Jeff Garzik stated that his public nodes currently have 2200+ pending transactions. He argued that all mempool implementations should limit the lifetime of any transaction to a specific number of blocks. He provided several reasons for this. Firstly, bitcoin clients retransmit until the transaction is confirmed. Secondly, it provides a deterministic lifetime for a transaction; if one knows that a transaction will disappear after a specific number of blocks (24 hours), then it is probably safe to initiate recovery procedures and perhaps revise the transaction. Finally, it prevents zombie transactions from littering memory as they hang around, wasting resources but never getting confirmed. Jeff believes that no one has strenuously argued against these points. Consequently, he suggests writing a patch and coming up with a good number that the network can agree upon.
Updated on: 2023-06-06T07:20:59.681609+00:00