On Mon, May 5, 2025 at 8:52 AM Greg Maxwell <[email protected]> wrote: > > On Monday, May 5, 2025 at 9:27:24 AM UTC Nagaev Boris wrote: > > > There may also be users today who rely on datacarrier > > behaviour/options without yet realizing they're scheduled for removal. > > > How is it possible that anyone relies on it in a way that it will be a > detriment to them? > > "I run bitcoind because I want to help centralize the network through > incentives to direct miner submission and slower block propagation, and by > encouraging utxo bloating 'fake addresses' outputs! I also like diminishing > my own ability to anticipate the content of the next block using data on my > own node" ? :P Were that actually someone's opinion I don't think anyone > would regret inviting them to run different software. > > I've been engaging 1:1 with people concerned about the change on forums for > the last few days and I've haven't yet encountered any clear argument as to > why someone would be harmed by the change. > > Rather, I've found that they've simply been fed an incorrect argument that > this change is a product of "bitcoin core" being in favor of non-monetary > (ab)uses of the Bitcoin network, and that it will radically increase the > amount of it. As far as I can tell this is a total falsehood both respect to > motivations and credible effects, and allegations otherwise just don't > survive the sunlight of a competent counterargument. >
My point is that it's hard to foresee every possible use case. We don't know how everyone's infrastructure is set up. Some users might only realize this change affects them after it's already released. And if they do need to adjust something in their workflow, it's a lot easier if they can temporarily restore the previous behavior. Right now, those users aren't speaking up, because they don't yet know they'll be affected. For example, someone might be running a device with very limited resources that can't afford to store the full mempool, but also can't disable it entirely. If they're only monitoring certain types of transactions that never use OP_RETURN, filtering those out is a simple and practical optimization. Or consider a system that pulls mempool transactions via RPC from Bitcoin Core. It might assume certain things about OP_RETURN outputs, maybe it allocates a static buffer for them, and crashes if one turns out to be unexpectedly large. Fixing that kind of issue may take time. Keeping the option available gives operators the flexibility to update their systems without breaking things in the meantime. This isn't about defending every edge case as critical. It's just about recognizing that once an option is removed, anyone who runs into a problem is stuck. Leaving the setting in place for one more release, even in a relaxed or discouraged state, gives people a fair chance to adjust before it disappears. -- 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_Vt6WU37OX5_92rWf5e-aesA%2BRa5Smh69d4P33-0YaGu6YQ%40mail.gmail.com.
