On Fri, May 2, 2025 at 7:23 PM Peter Todd <[email protected]> wrote: > > On Fri, May 02, 2025 at 12:04:13PM -0700, /dev /fd0 wrote: > > Config `mempoolfullrbf` was added in July 2022: > > https://github.com/bitcoin/bitcoin/pull/25353 > > It was made default in August 2024: > > https://github.com/bitcoin/bitcoin/pull/30493 > > Option was removed in November 2024: > > https://github.com/bitcoin/bitcoin/pull/30592 > > > > `datacarrier` and `datacarriersize` already exist, so why is it a big deal > > to remove them after a few months of monitoring the usage with stats? > > The `mempoolfullrbf` option was a good example of how keeping an option > to reject otherwise standard transactions is just wasted effort. Having > the option didn't stop full-rbf replacements from getting mined; user's > refusing to relay a transaction type that a significant % of miners are > mining acomplishes nothing. > > In that *specific* case there were a tiny number of users, Wasabi's > Coordinator being an example, where for technical reasons full-rbf > replacements caused problems until that code was fixed; giving those > users an option to temporarily disable those replacements was sort of > useful. But there's no reason to think that will be true with OP_Return > outputs, and in any case, you can just delaying upgrading your node > while you fix your broken code. >
If I understand correctly, the Wasabi bug is described in this issue: https://github.com/WalletWasabi/WalletWasabi/issues/10648 It was opened in May 2023. If the option hadn't been available at that time, it would have been much harder for Wasabi coordinators to mitigate the issue — they would have had to patch Bitcoin Core or use an alternative node implementation, rather than just toggling a setting. Also note that the bug in Wasabi was discovered after mempoolfullrbf was added in July 2022. The first Bitcoin Core release to include this change was v24.0.1, in December 2022. It took several months after that release for the Wasabi team to realize that mempoolfullrbf=1 created problems for their use case. If the feature had been released without a flag (enabled by default with no way to disable it) it would have made things significantly harder for them. There may also be users today who rely on datacarrier behaviour/options without yet realizing they're scheduled for removal. If the options are simply relaxed in the next release, users could still set the values they need and have time to adjust their infrastructure. It would give them a chance to move away from relying on those settings before they're removed entirely in a future version. Otherwise, they may be forced to either switch to another node implementation or remain on version 29. -- Best regards, Boris Nagaev -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAFC_Vt41NOmM1Mscri%2B%3DSEPzPLb%2BZ83R2FzZkQuTVbBfGssMug%40mail.gmail.com.
