pull down to refresh

Can I run Bitcoin Core 30 in mode 29?
169 sats \ 9 comments \ @anon 15 Sep 2025 bitcoin

I understand some defaults have been changed in Bitcoin Core 30 related to OP_RETURN and some people decided to run forks of it because of that. Is it not possible for those parameters to be set back to their values as they were in Bitcoin Core 29? If yes, then is it not more secure to stick to Bitcoin Core which is better reviewed and still have it operate as it did before the version 30 release?

write
preview
related posts
130 sats \ 0 replies \ @DarthCoin 15 Sep 2025

If you don't know what are you doing, why are you still upgrading to v30 ? Just stick with what you have. Nothing will change. Nothing.

What really matters: #1222299

reply
33 sats \ 1 reply \ @Scoresby 15 Sep 2025

The argument seems to be more about what the defaults are and whether datacarriersize is deprecated, but your point is a good one.

reply
100 sats \ 0 replies \ @0xbitcoiner 15 Sep 2025

I only found out today that they're thinking about removing the datacarriersize option in a future version. Honestly, that makes no sense to me. Changing the default? Fine, that’s not a big deal. But not letting people set it however they want? That’s just not okay.

reply
33 sats \ 1 reply \ @0xbitcoiner 15 Sep 2025

I’ve wondered about that too, and I think you’re right. Kinda sucks there’s no detailed list on GitHub about the changes in Bitcoin Core 30.

I still find it hard to understand the argument on favor to this change. As far as I understand the size of "OP_RETURN outputs" will be relaxed from 80 Bytes to 100k bytes, allowing the storage of arbitrary data, like images and even small videos.

[...]

To be clear, Bitcoin Core v30 lets node runners configure the OP_RETURN size limit (the -datacarriersize config option). The only change is that its default value is increased (to effectively unlimited). It is marked deprecated, which means the option is expected to be removed in a future version, but given the current political dispute around it, I do not expect that will happen any time soon.

The reason for changing the default isn't just that OP_RETURN is already used, and data storage through other means is already possible (including through ways that are cheaper than through OP_RETURN); it is that attempting to address this at the relay level is not more than a mild discouragement, and given enough incentives to bypass it (as we've seen exist) is harmful on itself, both for the ecosystem at large, and for individual node runners, in addition to being ineffective.

https://bitcoin.stackexchange.com/questions/127895/implications-of-op-return-changes-in-upcoming-bitcoin-core-version-30-0
reply
10 sats \ 0 replies \ @0xbitcoiner 15 Sep 2025
reply
0 sats \ 3 replies \ @anon 15 Sep 2025

Thanks, that makes sense. So running Bitcoin Core 30 with -datacarriersize=80 in the config makes it behave like 29.

reply
0 sats \ 2 replies \ @0xbitcoiner 15 Sep 2025
reply
0 sats \ 1 reply \ @anon 15 Sep 2025

So that would be 83:

It can be overridden with -datacarriersize=83 to revert to the limit enforced in previous versions.

from https://bitcoin.stackexchange.com/questions/127895/implications-of-op-return-changes-in-upcoming-bitcoin-core-version-30-0/127903#127903

It is marked deprecated, which means the option is expected to be removed in a future version, but given the current political dispute around it, I do not expect that will happen any time soon.
reply
0 sats \ 0 replies \ @0xbitcoiner 15 Sep 2025

Yeah, that’s how I see it too, but I’m no expert on this stuff. Take a look at the official draft for version 30. #1222557

reply