Author: email at yancy.lol 2022-10-31 17:21:08
Published on: 2022-10-31T17:21:08+00:00
The email thread being discussed is about the possibility of non-RBF nodes relaying full-RBF transactions and vice versa. Although accommodating both types of policy could lead to unforeseen bugs due to code complexity, it is worth it for a section of network participants. However, the benefits of fullrbf seem limited. While BIP 125's RBF rules were designed to evict conflicting transactions, they do not guarantee that all replacements will propagate in a DoS-resistant way. From this perspective, "enabling fullrbf" is taking away user choice to opt a transaction into a non-replacement policy regime.Moving on, the email then discusses the adoption of a zeroconf model. The author argues that using some policies to achieve certain goals doesn't mean others cannot use the same policy for different purposes. Additionally, predicting user behavior is beyond the scope of protocol developers. Instead, the author proposes considering whether it is technically sound to have an opt-in non-replacement policy regime and whether it interferes with anti-DoS mempool acceptance algorithms or other protocols on the network. The author concludes that offering the ability to opt-in to a non-replacement regime for transactions doesn't introduce any fundamental issues with software or network policy or other protocols.Furthermore, the author discusses the difference between opting out of transaction replacement and fullrbf and argues that there is no need to offer software that might break a policy that is working well for some users. The philosophy of transaction relay policy in Bitcoin Core should support disparate use cases to make everything work better rather than breaking things prematurely because others might break them eventually anyway.The author poses questions to those who favor a fullrbf network policy, such as whether fullrbf offers any benefits other than breaking zeroconf business practices and whether it is reasonable to enforce BIP 125's rbf rules on all transactions if those rules themselves are not always incentive compatible. The author also asks whether there is a logical basis for opposing a command line option that breaks v3 transaction relay in the future that is consistent with moving towards fullrbf now.Overall, the author argues for supporting different use cases rather than breaking things prematurely and suggests that opting out of transaction replacement should continue to be allowed.
Updated on: 2023-06-16T02:29:25.643462+00:00