Improving RBF Policy

Summary:

In an email conversation between Billy Tetrud and Gloria Zhao, Tetrud asked for Gloria's thoughts on his ideas about rate limiting and staggered window dos protection in the context of miners' mempools. Gloria responded with her opinion on the assumptions made about miners' implementation of mempool and block template building. She argued that we should try to match default mempool policy (which creates a network-wide transaction relay policy) as closely as possible to mining code. Gloria explained the purpose of building/caching block templates and described her solution for calculating a transaction's mining score.Gloria disagreed with Billy's notion that DOS concerns are overblown and recommended he re-read the current RBF policy. She also offered alternatives to rate-limiting, such as transaction replacement broadcast cooldown. Gloria concluded by pointing out that eliminating all spam is impossible, but we should aim to limit specific types of spam.The discussion on the Bitcoin development mailing list revolves around rate limiting and spam prevention measures. The concern is that if a user sends a transaction with a misplaced trust, their transaction's effective fee rate will drop, and they will lose anyway. Additionally, if spam ends up outside of a node's range, either the rate limiting won't take effect, or the user will miss out on the block.The group notes that the current rate limit via INVENTORY_BROADCAST_MAX / *_INVENTORY_BROADCAST_INTERVAL is not enough. A better approach would be to track the "effective fee rate" smarter than the ancestor fee rate manages. This could fall out of Murch and Clara's candidate set blockbuilding ideas. The discussion also touches on compact block relay, orphan pools, and the need for wallets to follow new relay rules.It is suggested that it's better to have the mempool acceptance rule only consider economic incentives, while spam prevention should only be about "shall I tell my peers about this?" The split allows users to send transactions to miners through other routes, even if the bitcoind anti-spam rules are blocking them at every turn.In discussions about DoS protection in Bitcoin, it has been suggested that transaction relay rate limiting and prioritizing transactions by ancestor feerate could be used to prevent spammers from wasting network bandwidth. The idea of baking DoS protection into the p2p level rather than policy level has also been discussed, with two main ideas proposed: transaction relay rate limiting with a feerate-based priority queue, and staggered broadcast of replacement transactions.However, there are concerns about the potential for censorship attacks and recycling fees without adding new ones. Other proposals include adding a policy rule allowing users to specify descendant limits on their transactions to solve the pinning problem with package RBF, and implementing a “mining score” calculator to help with ancestor-aware funding and fee-bumping in wallets.There is discussion about whether it is okay to prioritize transactions by ancestor feerate, which can be quite different from the actual feerate considered for a transaction in a block. Overall, while there are some concerns and considerations to take into account, there are various potential solutions being explored to prevent DoS attacks in Bitcoin.

Updated on: 2023-06-15T15:57:43.211949+00:00