On mempool policy consistency



Summary:

The discussion in the Bitcoin-dev mailing list revolves around the use of full replace-by-fee (RBF) and its impact on zero confirmation transactions. Greg Sanders suggests that potential thieves are willing to out-bid themselves to have funds come back to themselves, which is a rational use-case. However, Anthony Towns counters this argument by stating that not all rational use-cases should be supported by developers or node operators. He believes that miners would not want the patch to be available since it would reduce their fee income if zeroconf services went away. Additionally, including the option in core would make other miners adopting fullrbf more likely. Towns also argues that gains from high feerate replacement transactions from people exploiting zeroconf services for a few months before all those services shutdown doesn't make up for the lost fee income over the months or years it might have otherwise taken people to naturally switch to some better alternative. Even if fullrbf worked for preventing pinning that likely doesn't directly result in much additional fee income: once you know that pinning doesn't work, you just don't try it, which means there's no opportunity for miners to profit from a bidding war from the pinners counterparties repeatedly RBFing their preferred tx to get it mined.Sanders responds by suggesting that removing a quite-likely-incentive-compatible option from the software just encourages miners to adopt an additional patch. Towns counters by asking why miners shouldn't adopt an additional patch if they want some unusual functionality. He also questions whether there is any evidence that miners even want this option. Ultimately, the debate centers around whether full RBF should be enabled for zero confirmation transactions and the potential consequences of such a decision.


Updated on: 2023-06-16T02:27:25.642849+00:00