When someone provides one argument that stands up to the slightest bit of scrutiny why paternalistic node policy is a good (or even neutral) thing, I’ll happily change my tune. Until then…
Discussion
"Paternalistic node policy" is a bs argument and exactly what core devs are pushing on the community right now.
#gfy
Since these arguments seem to rush to ad hominim and strawmen I will just say sounds like daddy issues to me.
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"?
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...
One option gives nodes a choice and the other doesn’t. Which one of those sounds paternalistic?
This is actually a good frame, but then why was the OP Return limit included in Bitcoin .9?
Are you really suggesting that nothing material to this has changed in Bitcoin in a *decade*? Come on…
I'm genuinely asking, what (specifically) has changed?
With all the great benefits of segwit (lightening!), it also enabled (made a concession to?) consensus valid 4mb blocks. In this world the potential harm of blocking consensus valid transactions with an insignificant amount of data in an op return should not be something the reference implementation of bitcoin is a party to.
So your logic is the blocks are heavier so fuck it make it possible to go even heavier bc it's a small increase?
I just don't want to see incentives to route around our peer to peer mempools with things like slipstream. As much as possible, I hope all miners can be on a level playing field. Once I finally get my bitaxe setup, I want to be able to compete fair and square. This is obviously on a very small personal level, but when this scales it may be critical to mining and bitcoin's decentralization. It is my understanding that other standardness rules are important for ddos and other attacks. The op return limit is not. I would probably be in favor of a consensus softfork that limited blockchain spam without negative centralization risks. But that is quite unlikely unfortunately. Sadly, 4mb blocks/transactions of crap are possible. Will blocks be heavier without the op return limit? Maybe, but I believe negligibly so. I'm more concerned with centralization risks, utxo set harm (I think this may have a greater impact on costs to run a node than any potential small increase in storage costs.), and making it harder to securely maintain bitcoin core. I'm no one significant here though, and am just regurgitating information. But it is information obtained from multiple well regarded 😉 minds past & present of bitcoin, and it makes sense to me. Best to you and all of us! but I need to step away from this soon. Rainy day, but when that passes, I need some rays!
Why no zap?
I appreciate the thought. I'll get there eventually. I'm an amethyst user on graphene, and that works well for me. I'd like to use ecash for zaps, and was hoping amethyst or another similar client might build in an ecash wallet whose balance I can maintain externally with a lightning wallet. I'm aware of nostr wallet connect, and that may ultimately be the route I take, but my initial desire was to avoid inter app communication on my phone. I think I may be overly concerned though, and just need to get on with it. I do want to join the zap party! Curious to know how you're setup for zaps if you don't mind sharing.
At the time, Bitcoin Core scaled poorly. We didn’t have things like compact blocks and were not really ready to handle actually full blocks. Further, things like Slipstream and Libre Relay didn’t exist so policy wasn’t completely useless, though obviously it still only fairly marginally increased the cost of finding a miner to mine non-standard stuff (though F2Pool was mining non-standard stuff regularly not too much later than this). Finally, there didn’t seem to be a ton of demand for these kinds of transactions, just people exploring backing up their data to the chain, so nudging them away from that was effective (compare to today where it not only wouldn’t be effective, it would harm most miners in favor of MARA) vs today where we have transactors putting crap in the UTXO set to get around the limit, which is obviously much much worse.