Author: Anthony Towns 2022-02-08 04:58:50
Published on: 2022-02-08T04:58:50+00:00
The conversation is about outbound tx relay size-based rate-limiting and prioritizing tx relay by feerate to prevent spammers from wasting bandwidth network-wide. The scheme would slow down low feerate spam, preventing a huge network-wide bandwidth spike while allowing high feerate transactions to propagate regardless of how busy traffic is. The inbound tx request rate-limiting could also prevent DoS regardless of the fee-based replacement policies. One point that needs clarification is whether it is okay to prioritize transactions by ancestor feerate in this scheme since it can be quite different from the actual feerate considered for a transaction in a block. The transaction could have a high feerate sibling bumping its ancestor, which makes it ugly. It's something of a special case, but it could be resolved by tracking the "effective fee rate" smarter than the ancestor fee rate manages. This same work could also make it possible to come up with a better answer to "do I care that this replacement would invalidate these descendents? "Regarding wallets, it is best to have the mempool acceptance rule only consider economic incentives, and the spam prevention only be about "shall I tell my peers about this?" If there is no split, then the anti-spam rules can prevent getting the tx in the mempool at all. However, if there is a split, even if the bitcoind anti-spam rules are blocking you at every turn, it is still possible to send your tx to miners through other routes, and they can add it to their mempool directly without hassle.
Updated on: 2023-05-22T16:59:53.430093+00:00