On Sun, May 04, 2025 at 05:04:23PM -0300, Nagaev Boris wrote:
> > 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.

No, in this hypothetical case (see below) they could have just
downgraded to the earlier version. There's no rush to adopt new Bitcoin
Core versions.

> 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.

Nope. Wasabi was actually running Bitcoin Knots, which had full-rbf
enabled by default long before Bitcoin Core did. In *their* case, IIRC
they just turned it off, fixed their code, and turned it back on.

> 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.

It is *very* hard to imagine removing datacarrier causing issues given
that oversized OP_Returns regularly show up in blocks. We don't need to
put unlimited effort into hypotheticals. The only way this would be an
actual issue if it you had mempool-specific code that was so broken that
it broke on an oversized OP_Return (or more than one), and yet somehow
you desperately needed to use a *new* version of Bitcoin Core.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aBkt5mtT-Zh2_hsl%40petertodd.org.