There is still a 4mb per block limit no?
Discussion
Yes, but that doesn’t change my point. A change/proposal that allows for additional data that wouldn’t be there otherwise increases the cost of running a node and is a headwind to decentralization.
To what extent? Who knows, but we can know it won’t lower the cost of running and node and further decentralization
The block size limit already keeps the nodes small enough to maintain decentralization. That's why this argument has no weight.
‘Small enough’ and ‘Decentralized’ are not objetive parameters. A change that allows for more arbitrary data to be included in blocks that would not otherwise be there can only hurt the cost of running a node and decentralization.
I never stated the extent of the negative impact, just that there very clearly is one. So the question is, is it worth it?
There isn't an impact. That's the whole point you're missing.
It doesn't allow for any data that wouldn't be there otherwise. It removes filters. Those filters can already be removed and be in concensous anyways.
Why is a change needed?
It's not NEEDED. It makes Core more maintainable. Passing this puts the whole debate to rest. Senseless arguments about stuff that doesn't matter.
If nothing is being changed, then what is being passed?
Default filters. This is changing the default to have none and if users want them, then they can add them. It's better to have no arbitrary default filters. Because that's what they are. Arbitrary. If you would like to change your mempool policy after this merge then you are free to do so.
I guess if we are to believe that it Bitcoin is not strictly a monetary network, then changing the default to allow any type of data is not a big deal.
I am of the opinion that Bitcoin’s purpose is as a monetary network, so changing the default settings to allow for information that is not aligned with that purpose is a move in the wrong direction.
Subversion happens from within. Not saying this is an attack by state actors, but if they wanted to attack bitcoin they would do it this way. Slowly pushing for small changes that are seemingly not a big deal.
Just because someone can jump over a wall, doesn’t mean it’s a bad idea to have walls.
I don't understand why we give everyone a wall by default. This still allows for everyone to build their own wall as high as they want to. It just makes the default no wall. Making the repo more maintainable and putting the whole debate over how high the default wall should be.
Thanks for your summary. So, how does one go about re-adding the filters? Is it easy?
Not particularly. But it is easy to run a concensous forks like knots that has the filters in it. So if you would like to filter your mempool, then you can easily run knots.
So in the current bitcoin software, these filters are available, but not turned on?
They are available and some are turned on as we speak
Some, but not others?
No they are all on, it's just a matter of the thresholds. By default the OP RETURN data can hold 80bytes of data. You can raise or lower this limit. The PR is to remove it entirely. If they do, you can still run a node with whatever limit you want and you would still be in concensous.
Thanks. Does pruning remove this data by default?
No. Pruning just removes txins up to a certain checkpoint that you define. It doesn't care what's in them. But also this is for mempool policy. ie transactions that have not yet been confirmed. Once a txt is confirmed, every node will store it. No matter what their mempool policy is