I think this person makes a very good argument why there IS and should be a debate. Or is he one of the "paterlalistic" people who "don't understand bitcoin"?
Discussion
This isn’t an argument, it’s just “wellllll, I haven’t thought about it that long so hold off until I do”? This debate is a decade old, that’s on Adam.
I said was I good reason for debate. Not a good reason for potentially allowing unrestricted data in OP_RETURN.
I, and many others am not convinced by the arguments FOR that change yet.
Is all tradeoffs. For example I am also not entirely convinced that this rush to Knots is a good idea either.
I’m happy to answer any question you have! I don’t see any tradeoffs at all, actually (not that I’m happy people want to embed data, to be clear I’m not!)
Remove all limits from op_return is on the table. I not see how that would not have tradeoffs. One of which would be potentially exploding the size of the unpruned blockchain, right?
People currently embed data in the chain via witness data (which allows them to embed 4x more data), often using Slipstream to get nonstandard transactions mined. I don’t see any reason to think allowing additional OP_RETURN data would increase the amount of data stored in the chain.
Isn't one of the possible recommendations to remove the limit completely on op_return? And if so, would that not allow basically limitless data to enter into the Mempools and be written to the unprunrd blockchain.
I understand that spammers are using the witness area now, and that that is worse, and part of the idea here would be using OR as it was intended. But it doesn't justify either usage, in my opinion.
The problem is there are very real and very significant consequences to mining centralization if ~all the valid transactions people want to make are not readily available to any miner running Bitcoin Core. So changing the option (a) doesn’t impact how much data people can store, they can just store it in a new place that’s more expensive (not sure why they would but even if they do great, they’re storing less data) and (b) it materially improves Bitcoin’s robustness.
I get that it feels icky, but the facts on the ground are pretty clear.
I appreciate you taking the time to write these answers and I actually understand the points that you're making already. I think we diverge fundamentally at an earlier point.
In some ways I feel like this argument is like sort of a harm reduction argument. And I think harm reduction is a good idea for drug addicts for example, but we wouldn't mail everyone in the world a pack of needles and some clean heroin just in case so they would have safe things to use if they ever decided to.
In some ways, this seems like the windows registry to me. I think part of the idea there was let's have a sanctioned place for developers to put their configuration data. Well, that kind of thing can grow into something unexpected and that's what I'm worried about as we continue to open the doors to data storage on the Bitcoin blockchain.
I would much rather see us work to find ways to make storing (large) data on the blockchain in any of the three places harder to do.
On top of this, I do not think it is unreasonable to point out that there are people involved in making this decision who will benefit from being able to store large amounts of data in op_return. And I think there's a non trivial number of users who do not want that to happen. And these users include cypherpunks, people who are current and past contributors to core. it is not cut and dry.
I don't think the community is done discussing this by any means. And I think rushing something like this on any level will increase the chance for forks and even forks between reference implementations will have implications that could be unexpected. that are possibly even negative
It is fundamentally improve to prevent those who want to store data on chain from doing so. There’s nothing to investigate there, there’s only worse ways of doing it and better ways of doing it.
> On top of this, I do not think it is unreasonable to point out that there are people involved in making this decision who will benefit from being able to store large amounts of data in op_return.
I don’t believe this is true. The Citrea instance isn’t material to them. They’re gonna do it either way, either in a really shitty way that bloats the UTXO set or in a better way. The only impact is on Bitcoin, not them.
> rushing this will increase the chance of forks
Huh? This is mempool policy, not consensus logic. People can run other code if they want to but there’s no chance of a fork for mempool policy.
If you mean that people will fork Core, I mean, okay? The issue is ~all the engineers working on Bitcoin Core and mempool policy agree with this change (which should tell you something, they don’t often all agree!), so maintaining a fork without any of the people competent at doing so is not gonna end well.
Or you end up like Knots, a one-man project shipping a ton of barely-tested patches that zero people aside from Luke have reviewed. That’s not a serious project.
I almost amended to clarify by fork I meant the project but at the same time you are making my downstream argument as well. We could end up with versions of software that could eventually diverge enough to interrupt the "lockstep" Satoshi wrote about @ BCT when the topic of multiple implimentations came up.
I agree that people running to a project being run by a single person has risks as well. But I reject your intimation that the only people competent enough to work on Bitcoin are already working on core.
Honestly, that kind of smacks of the arrogance that the community is interpreting from the people that are involved with core.
Which brings me to my final point. The fact that the community is up in arms about this may not be something that you and others agree with, but these are the people that run the software and some of them have been doing it for quite some time and some of them are also quite intelligent and not just people being led around by the nose by strong personalities or that sort of contention my perspective, this seems like the most serious issue of all. A fork in the community, if you want to call it that. I know that this is a new thing. In the op_return topic has had contention from the beginning. I was there. And many of the arguments being used today are the same ones that we're coming up at the very beginning and have continued to be concerns for many people in the community, many of whom are cryptographers, cypherpunks, programmers and prominent people.
I understand that this change is believed by its proponents to be the best way to actually reduce spam on the chain, the best middle ground, the best compromise.
But the way this is being handled has caused the community of users to lose trust significantly in the people leading the core project. And this should be alarming to all of us. Because in the end, that social schism can be the most powerful introduction of chaos and be more easily used to subvert the direction of Bitcoin than even a bug in the code.
Several typos. I try lol. One spot should read "NOT a new thing" for example
This illustrates weekday I am concerned about...