So you can still filter it out but people are mad that it isn’t the default setting. So instead of convincing everyone to change the op return size limit in their node settings, they are convincing everyone to just completely move over to node?
Discussion
The left curve take is always the winning take.
Yes I believe you are understanding correctly.
Big picture everyone is forgetting that BTC is all purely voluntary and open source. You can run a node or not, you can pick the version, you can modify the settings, you can upgrade or not or downgrade, etc.
While defaults do matter, they matter far less in BTC this there are not forced auto updates and everything is open source and volume tart.
I view this all as a bit of a strawman because I’ve never met a single bitcoiner in real life who immediately updates their node when a new Core version comes out. Whether it’s inertia or caution people are generally slow to update, if at all.
Autocorrect fix:
Yes I believe you are understanding correctly.
Big picture everyone is forgetting that BTC is all purely voluntary and open source. You can run a node or not, you can pick the version, you can modify the settings, you can upgrade or not or downgrade, etc.
While defaults do matter, they matter far less in BTC because there are not forced auto updates and everything is open source and voluntary.
I view this all as a bit of a strawman because I’ve never met a single bitcoiner in real life who immediately updates their node when a new Core version comes out. Whether it’s inertia or caution people are generally slow to update, if at all.
It’s just a problem when/if there is a chain split
Since this is non consensus related (e.g. no one is debating what is or is not a valid bitcoin transaction) there should be no chain split implications unless there was a genuine bug where Knits disagreed on what a valid transaction was.
There is a scenario where it can cause a chain split. I don’t remember what it was.