Call for reconfiguration of nodes to relay transactions with fee-rates below 1 sat/vbyte

In a recent exchange on the Bitcoin Development Mailing List, concerns and clarifications were raised regarding the configuration of transaction fees within the Bitcoin network. One notable point of discussion was the suggestion of setting the incrementalrelayfee to zero, which would allow for the replacement of an original transaction without any increase in the total fees in the mempool. This proposal was met with caution as it could potentially enable malicious actors to exploit the system by cycling two conflicting transactions with the same weight and fee, leading to unnecessary consumption of bandwidth and CPU resources across nodes that adopt this setting.

Further dialogue touched upon the practice among miners regarding the setting of -blockmintxfee, with speculation that some miners might opt for a value lower than the default to accommodate transactions with minimal fees. However, skepticism was expressed about this claim due to lack of evidence showing transactions with feerates below the minTxRelayFee being included in blocks in an organic descending feerate order. It was suggested that transactions appearing at the beginning of blocks with lower than minimum feerates might be the result of explicit prioritization by miners, perhaps due to payments made outside the transaction fees or through the influence of high-feerate child transactions pulling along their low-feerate parents, rather than an indication of miners universally lowering their -blockmintxfee.

The conversation also addressed the potential risk of Distributed Denial of Service (DDoS) attacks stemming from the setting of minrelaytxfee to a negligible amount. Despite the argument that existing mechanisms such as the default 300MB size limit for mempools and a 336-hour timeout for unconfirmed transactions could mitigate the impact of such attacks, it was highlighted that the absence of knowledge about an exploit does not necessarily equate to the security of the system against DDoS threats. This discourse underscores the complexity and critical nature of configuring transaction fees and related settings within the Bitcoin network, emphasizing the need for careful consideration to balance operability with security against potential abuses.