Published on: 2012-09-25T17:52:10+00:00
In a discussion between Jorge Timón, Jeff Garzik, and Gregory Maxwell, the focus is on transactions that have not yet been included in the blockchain. Garzik suggests implementing a deterministic lifetime for transactions to initiate recovery procedures and prevent "zombie" transactions from wasting resources without confirmation. However, Timón questions whether the chain can enforce this and why clients cannot delete these transactions.Maxwell explains that there are bursts of unusual transactions flooding the network, which some miners intentionally exclude. He also mentions that double-spending transactions are not stored, resulting in large chains. These transactions rely on their parent, which is dropped due to rule violations. The software keeps them as orphans until their parent arrives. Maxwell proposes maintaining a cache of rejected transaction IDs to consult for orphan transactions' parents, but it would need to be dropped during reorganizations.Garzik and Maxwell further discuss the issue of mempool size and the disconnect between what miners mine and what relayers relay. Garzik's public nodes currently have over 2200 pending transactions in their mempool, leading to clutter over time. Burst of weird transactions, double-spends, and sustained loads are intentionally excluded by many miners. They agree that a patch and a consensus on a specific number are needed to address this issue.In a mailing list, Mike Hearn expresses his concern about the increasing number of pending transactions that do not get cleared into blocks. He asks if anyone has long-term logs containing the pool size and timestamps to track this trend. Hearn realizes that they forgot to enable timestamps in their own nodes' logs, making it difficult to analyze the situation. They report having one node with 4000 transactions in the mempool, while only a few hundred are being cleared in blocks despite current transaction rates.Jeff Garzik also acknowledges the high number of pending transactions in his public nodes, suggesting that all mempool implementations should limit the lifetime of a transaction to a specific number of blocks. He provides reasons for this, including retransmission by bitcoin clients, the need for a deterministic lifetime for recovery procedures, and preventing zombie transactions from occupying memory without confirmation. Garzik believes that there is no strong opposition to these points and proposes writing a patch and establishing a consensus on an appropriate number for the network.Overall, the discussion revolves around the challenges posed by unconfirmed transactions, bursts of unusual transactions, mempool size, and the need for implementing measures to prevent resource wastage and improve transaction confirmation efficiency.
Updated on: 2023-08-01T03:55:35.411086+00:00