Stats on compact block reconstructions

Over a period of approximately six weeks, an in-depth analysis was conducted on transactions rejected by a mempool, specifically from block 918234 to block 924597. This study was aimed at understanding the dynamics of transaction rejections during the process of block reconstruction. A notable change was implemented to ensure all transactions requested for block reconstruction were logged, diverging from the default setting that only logs these requests if less than five transactions are missing. The node in question operates on a clearnet environment and is based on a forked version of the master branch, reflecting commit "084fd68fda2c604a873f0f54c0c3723850509019". This particular commit is significant as it had already introduced a new minimum fee rate policy.

Throughout this logging period, several key findings emerged regarding the reasons behind transaction rejections. The data revealed a total of 1376 instances where transactions were rejected due to bad transactions inputs being either missing or spent. Another common reason for rejection was insufficient fees, accounting for 1130 rejections; it's important to note that in this context, 'insufficient fee' primarily refers to the inadequacy of the fee for a transaction replacement. Other reasons for rejection included 54 instances of transactions with the same non-witness data already present in the mempool, 49 instances failing to comply with BIP68 finality requirements, and 20 cases where the minimum relay fee was not met. Lesser factors contributing to rejections involved too-long-mempool-chain (12 cases), replacement-adds-unconfirmed (9 cases), too many potential replacements (9 cases), transactions identified as dust due to their dust output requiring a zero fee (3 cases), and transactions already known to the mempool (2 cases).

The comprehensive logging and analysis of these rejections underscore the intricate balance between transaction fees, mempool policies, and the technical requirements that transactions must meet in order to be successfully included in a block. This detailed examination not only highlights the challenges faced by transactions during the block reconstruction process but also sheds light on the operational intricacies of managing a mempool within the evolving landscape of blockchain technology and its governing policies.