Author: Gloria Zhao 2022-03-14 10:29:16
Published on: 2022-03-14T10:29:16+00:00
The bitcoin-dev mailing list has been discussing ways to protect against denial of service (DOS) attacks, particularly in relation to replace-by-fee (RBF) transactions. One idea was to add DoS protection at the p2p level, rather than the policy level, by rate-limiting transaction relay and prioritizing transactions by ancestor feerate. Another suggestion was staggered broadcast of replacement transactions, accepting multiple replacements for the same prevout within a time interval, but only relaying the original transaction. Participants discussed whether these ideas were good solutions or if they created new problems.For example, rate limiting could potentially allow an attacker to censor someone's transaction from ever being announced by a node if they send enough transactions to fill up the rate limit. Another solution proposed was adding a user-elected descendant limit on transactions. This would solve the pinning problem with package RBF where the attacker's package contains a very large and high-fee descendant. It was suggested that this policy could be deployed with package RBF/package relay so that Lightning Network can use it by setting the user-elected descendant limit flag on commitment transactions. However, it adds complexity for wallets that use it since it limits their use of UTXOs from transactions with this bit set.Participants disagreed on whether DOS concerns were overblown or not. Some felt that the economics of the fee-rate rule already sufficiently mitigate the issue of spam. Others thought that sufficient DoS protection could eliminate the risk of actual service denial via replacement transactions. Feedback was sought on the proposed solutions and the concept in general.Gloria proposes a solution to accurately determine a transaction's mining score by building mini-block templates with all related transactions in the mempool. She also addresses the DoS concerns with recycling fees, referencing the current RBF policy and proposing a transaction replacement broadcast cooldown. Billy provides his own ideas on how to limit unnecessary data transmission, including rate-limiting and a staggered broadcast of replacement transactions, but ultimately agrees with Gloria's proposal for a broadcast cooldown. He notes that spam will always exist, and the goal should be to design a system where it is manageable, suggesting a 2:1 ratio as acceptable.In this conversation, Gloria discusses the complexity of miners determining which blocks to work on and suggests that non-mining full nodes should not be held to the same standard. She believes that the default mempool policy should be as close to the mining code as possible to ensure accurate fee estimation and allow for compact block relay. The discussion on the bitcoin-dev mailing list revolves around keeping high-feerate evicted transactions for some time to improve compact block relay. The replaced transactions are already added to vExtraTxnForCompact, which is a 100 tx LRU cache. However, it may not be good enough, and a rate limit may apply only to replacement transactions. AJ's statement that all you need is for there to be *a* path that follows the new relay rules and gets from your node/wallet to perhaps 10% of hash power makes sense, indicating that it is better to have the mempool acceptance rule only consider economic incentives and spam prevention about "shall I tell my peers about this?". The anti-spam rules can prevent getting the transaction in the mempool if there is no split. Still, with the split, even if the bitcoind anti-spam rules are blocking, it is possible to send the transaction to miners by another route, and they can add it to their mempool directly without any hassle.
Updated on: 2023-06-15T16:04:49.399434+00:00