Published on: 2014-02-28T11:18:26+00:00
The discussion revolves around the risk associated with opening a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. There is no expiration policy currently in place, which poses a DoS problem. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources, but it is annoying to do this by hand.The mempool superblock design is suggested as a solution, which keeps getting suggested. It orders the mempool with highest fee/KB first and transactions that paid less than the lowest fee/KB in a max-size mempool would not get relayed at all. However, this makes zero-conf transactions even less safe as attackers can broadcast enough transactions paying X+e fee/KB to push out the unconfirmed tx from mepools around the network and then broadcast a double-spend.In an email thread, Peter Todd raised concerns about the potential for a low-risk DDoS exploit with the implementation of a fee drop. He suggested that a memory-limited mempool prior to release could mitigate this issue. The clearance rate of new low-fee transactions is likely to be small, and in periods of high demand, there have been issues with mempool growth. Additionally, it would be easy to create large groups of low-fee transactions and cheaply double-spend them to consume network bandwidth.Todd also noted that releasing software with known and obvious DoS attack vulnerabilities that did not exist in the previous version is irresponsible. In response, Troy Benjegerdes suggested that including the change would be a good idea and asked for more information on what the DOS attack would look like so that he could trade in anticipation of the market crash. Finally, Benjegerdes commented on the advantage of Bitcoin being that people can learn from its mistakes and that it is not a one-size-fits-all fiat.A mempool janitor change has been pushed out to the Github repository of Bitcoin. The aim was to create a simple, bolt-on change without rewriting the mempool code. Metrics will be run for 48 hours on what does and does not get into the public nodes' mempools, ending Friday midnight EST.Peter Todd raised concerns about whether a memory-limited mempool would be added prior to release in order to avoid an obvious low-risk DDoS exploit. Todd believed that the network bandwidth DoS attack mitigation strategy relies on transactions that are accepted to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small. He suggested that it should be obvious to people how one can create large groups of low-fee transactions and then cheaply double-spend them with higher fee transactions to suck up network bandwidth. He also stated that releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels.Jeff Garzik, a Bitcoin core developer and open-source evangelist, signed off by providing his contact details and BitPay Inc.'s website.The context suggests a possible mitigation for flooding through discussion and process BIP, which needs further thought and analysis before being acted upon. The author presents two possibilities regarding the value of transactions with lower fees, stating that if orphan costs outweigh the value, miners may refuse to include them en-masse. Alternatively, if the total value of transactions is not outweighed by orphan costs, miners may stop including useful transactions and face pressure to change their policies. The author notes that the possibility of a DoS attack through flooding small transactions is only an issue in the first situation and is not the easiest or cheapest method of DoS attack on Bitcoin. However, the author acknowledges the need for more DoS resistance, which requires significant time spent on resource scheduling and code audits. Overall, the context highlights the importance of careful consideration and analysis before implementing any changes to mitigate potential issues.In this discussion, the concern is raised that there may be a large discrepancy between MIN_RELAY and the expected minimum fee needed for a transaction to be included in a block. The relay network uses MIN_RELAY and MIN_DUST to prevent spam, but only transactions that are added to the blockchain actually pay a fee. This creates an opportunity for lower-cost spam. The issue revolves around how close the boundary is between staying above MIN_RELAY and staying out of the blockchain.To address this issue, nodes encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. There is also a suggestion to align mempool selection with the expected block inclusion to optimize resource allocation. For example, a miner would push out cheaper transactions to make room for higher fee transactions based on max block size or orphan rate projections.
Updated on: 2023-08-01T07:44:29.688066+00:00