You are taking an ocean mining marketing stunt and blowing it way out of proportion.
State-Level Attack On Bitcoin?
https://blossom.primal.net/f403b43ed90e880b0620b39c9243b6e41901a8223336e63d0d24a9e252c8c071.mp4
Discussion
Nice FED psyop bait and switch right here. So tell us Satan, why is uncompressed CP on bitcoin not a problem?
It's a huge problem. So why isn't the ACTUAL solution to the problem being discussed?
You mean a consensus change?
Here is my opinion:
We have 2 realities here-
#1 this op_return filter change in B-core software is required for the potential "attack" that knots is saying could happen.
#2 this change is NOT required and the CP attack could happen at any time.
Thus, we end up logically at the original question, WHAT IS THE BENEFIT OF MAKING THIS CHANGE THEN?
IMO there is no benefit to making this change and thus I will not make it on my node.
The benefit I think is that
1. The setting doesn't actually solve any problems.
2. The core devs were sick of the constant debate so they decided to free themselves of it by removing it entirely since it's not consensus critical.
I would prefer they keep the setting and I don't care if anyone runs anything else. I just don't want people to think that they are actually fixing any problem by setting datacarriersize because they're not.
Well who knows? The “CP attack” hasn’t happened yet, so why make the change?
I’m not very sympathetic to devs being “sick of” ANYTHING. Anybody who doesn’t freely contribute to free software should fucking quit and that especially includes this current batch of corporate losers.
Uncapped arbitrary data has been possible since 2010. Nothing is different. They realized filters don't work because they don't. I think the setting should stay but removing it is not a big deal because it doesn't work.
It’s a cultural issue. The devs do not set policy. Contrast with how full RBF came into being.
Also most op_returns are under 80B so the filter does work
