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.

Reply to this note

Please Login to reply.

Discussion

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