pull down to refresh
0 sats \ 21 replies \ @Scoresby OP 4h \ on: Undeprecate datacarrier PR rationale - @schmidty bitcoin
I can get behind this. Compromise seems good for issues that don't seem to be too important. It would be really nice to see things move on to more important/interesting issues. Props to @schmidty!
I do worry that we will just have to rehash the whole debate whenever data carrier is deprecated.
Unfortunately, even if merged, I don't think it will change the social media debate very much. So far most (almost all) the replies on X have been negative -- from both sides.
Imagine core just forks itself without data carrier and the fork with it just stops being maintained haha
reply
I had a similar thought: that lots of people think there is some power from controlling the core repo. I think devs will eventually need to prove there isn't by creating a new code fork.
What would really prove there is no power in a repo is to give the keys to core to luke then code fork.
reply
reply
Yep, and I don't think I've seen anyone since make a compelling a case as to why it should continue as-is.
reply
When I first saw you say it, I wasn't sure so I decided to brood on it a little bit, but the more I think about it, and perhaps even more significantly, the more the drama develops, the more I agree.
The only thing I worry about is that we will see more drama in the way of Bitcoin Unlimited, where a decision is made (or coded in) that a failed softfork should anyway activate.
reply
Can you expand the latter point? Not sure I quite follow...
One of my reasonings for deprecating is that any bad decisions have a more isolated impact
I think the worst case scenario is a new repository gets the same mind-share and we're just back to where we are now, but at least that would require a proactive opt-in rather than letting changes slip by as deference.
reply
I'll try.
One of my reasonings for deprecating is that any bad decisions have a more isolated impact
Yes, but it will also be more chaotic. What I'm pointing to is that in a fragmented node software landscape, it will be easier for softforks to become hardforks, simply because of developer hubris / yoloing. "Miners disagreed because miners are evil". Shitcoiners can show us how crazy it can get: check out the BCH->XEC insanity.
Right now, it is easy for a Bitcoin Core dev to say "just make a signaling client for your softfork", knowing full well that since every pool except Ocean runs Core, it's not dangerous. However if this landscape becomes more fragmented, then softfork devs will be emboldened to just do that
LOT=true fork, and that is a risk for the overall ecosystem, especially if you remember that Rusty, imho validly, cautioned against easy (ST) softforks, because it means the ecosystem is less developed against future trouble when someone pushes LOT=true:But one day, a real crisis will return. We won't have an answer, and we won't have practiced: this will make the crisis far worse. Instead, if we codify "devs propose, miners activate, users override" (i.e. a LOT=true option, off by default) we'll know exactly what the process will be when miners fail to activate. It may still be messy, of course, but we'll have all the tools at hand, and we'll even know the date the crisis will come to a head.
reply
Right now, it is easy for a Bitcoin Core dev to say "just make a signaling client for your softfork", knowing full well that since every pool except Ocean runs Core, it's not dangerous.
Miners running different code isn't dangerous. In fact, Bitcoin is fundamentally designed with different valid blocks being valid in mind.
Back in the day the people in cryptography expected not every miner having the same transactions propagated to them in time. Which is the same thing as if the blocks contents where chosen by different software.
Dont worry about it :)
hmm, I can appreciate the fear of unknown unknowns, but this example seems a little contrived
Nothing stops a yolo dev from pushing a hardfork today, nor a miner from running it. And afaik most miners are implementation forked for template tuning already.
Miners are disincentivized from mining bad blocks, hardforking therefore requires intent, or carelessness... Distribution is only a soft-impediment to accidental hardfork.
Now sure "updating" in a post-Core era could be a footgun for the careless, because it shakes up distribution... but I'd think that both transitory and extremely isolated.
What I see as most likely happening is that implementations get a little more splintered and niche, and what ultimately "replaces" core is a smaller footprint consensus library or test vectors.
I think the worst case scenario is a new repository gets the same mind-share
I think the community will always want a repo with a lot of eyes on it, to manage PRs and ensure changes are well reviewed.
If you had loads of code forks, it would be tough to know what has and hasn't been thoroughly reviewed. That won't cut it on a project that requires absolute reliability.
reply
That's the problem now, Core just gets arbitrary changes through because there's the presumption of lots of eyes on it. People just download blindly with zero discernment because the repo is trusted.
If it were more splintered, or even just relocated, it would force people to know why they're downloading what they're downloading.
It doesn't mean another repo wouldn't result in exactly the same people doing the same exact things with the same number of eyes, but the shakeup would make "upgrades" explicit.
The rate of change in Core is obscene when compared to enterprise software and SCADA systems that extremely important processes are built upon. Bitcoin is akin to those types of systems as the backbone for trillions in value, but it's changed more like a fledgling javascript framework because of this disconnected relationship between stakeholders and the NGO's ability to use it as a laboratory because of a legacy they themselves didn't build.
This will blow up eventually, the case for archiving it is that when it does blow up the impact is isolated.
Unfortunately, even if merged, I don't think it will change the social media debate very much.
The past 3 days I've been "debating" (tho not really) the repo ecosystem with a bunch of stackers under @0xbitcoiner's post (#1227133) and if I'm honest, it's leading nowhere. The only thing to do is take action.
This PR is a good action indicator. If it gets closed, then action is more warranted than it is now. If it stays open forever, action is warranted based on other activity. If it is merged, then action is less warranted.
However, I'm super hesitant to take action or even explain my full thinking on the greater issue at hand because I'd insta dox myself. Choices, choices.