[BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts

In a recent discussion on the flexibility and purpose of mempool configurations within individual nodes, several key points were emphasized about how users can tailor their node's mempool to suit specific needs and preferences. One user highlighted their unique approach by adjusting their mempool's expiry time to two years, diverging from the default seven days. This adjustment was made with the aim of observing whether low-fee transactions would eventually be processed during periods of high transaction fees. This example underscores the broader concept that the function of a mempool on a user's PC is highly customizable and can serve various purposes beyond its traditional role.

In essence, configuring a mempool to closely approximate the transactions that an economically rational miner would include in the next block offers several advantages. For miners, this strategy enhances revenue potential for blocks they successfully mine by prioritizing transactions with optimal fees. Transaction senders benefit from improved predictions regarding the inclusion and necessary fee rates for their transactions. Additionally, such configurations aid in faster block reconstruction and relaying, which in turn facilitates quicker updates across the network. This aspect is particularly crucial for applications that share utxo information, such as lightning networks or other decentralized ledger contracts, where timely updates can be critical.

However, it was also noted that despite the benefits of approximating future blocks, the inherent unpredictability of transaction propagation and miner behavior means that absolute precision is unattainable. Factors such as double spending, inconsistent propagation speeds, new features, irrational miner behavior, and software bugs introduce variability. Consequently, the argument posits that software should ideally degrade gracefully in response to inaccurate predictions, advocating for a tolerant approach towards diverse transaction types and software configurations, even if they deviate from perceived optimal efficiency or economic rationale.

A particular case where approximating the next block is deemed less valuable revolves around transaction propagation with privacy considerations. The practice of receiving, relaying, and anonymizing transactions without logging their origins or destinations is highlighted as a method to enhance Bitcoin's utility as surveillance-resistant money. This approach not only assists in protecting user privacy from various threats but also supports the principle of freedom in transaction processing, especially for nodes not primarily focused on mining, fee estimation, or immediate network status updates.

Finally, the discussion touches upon the technical evolution of Bitcoin's block relay performance, contrasting pre-2016 conditions with current capabilities. Improvements such as compact blocks, high-bandwidth optimizations, and forwarding mechanisms before full validation are credited with significantly reducing orphan rates and overall network latency. Despite this progress, challenges related to filtering and inconsistent mempools persist, albeit with a relatively minor impact on network efficiency, estimated at a 0.17% cost increase. This figure contrasts with the larger improvements made over time, suggesting that while not perfect, the advancements in Bitcoin's protocol have markedly enhanced its resilience and efficiency.