pull down to refresh
169 sats \ 13 replies \ @optimism 2h \ parent \ on: Undeprecate datacarrier PR rationale - @schmidty bitcoin
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.
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 :)
reply
Ah! But that wasn't my point really - and we've seen on BIP68 activation that there's a lot of "SPV-mining" risk anyway, where early templates are being pre-made by some script that just builds on top of the last known header. I don't know how common that still is; I should spend more time with b10c's observer.
I'm not worried about multiple valid implementations, I'm worried about this: you soft-fork in your proof-of-chips
OP_CHECKLAYSVERIFY upgrade and when your activation fails with 20% support it activates. People start verifying their chips and then someone on a non-supporting node (80% of the network) spends an utxo without verified chips. Now 20% of the network hardforked off.reply
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.
reply
I'd think that both transitory and extremely isolated.
Everything landed okay-ish after the blocksize war so besides time nothing was wasted, except maybe the invention of LOT itself, which is imho an abomination. It's seen a lot of discussion and was at some point proposed for taproot activation, but we got ST in its place.
I do agree that this isn't a reason to not move forward with any decentralization though. And it's easy for anyone to use this fear against the current power that has vested in Core.
reply
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.
reply
People just download blindly with zero discernment because the repo is trusted.
They trust that others are looking at the code, and you get that with one main repo.
It's unrealistic to expect most people to start doing code review and verifying the code for themselves.
but it's changed more like a fledgling javascript framework
As I understand it, PRs are often in review for months or even years, if thet get merged at all. That's hardly like the javascript community.
Regardless, if there were multiple code forks, I'd expect that to reduce code security/reliability, not increase it. The eyeballs would be split between repos and there would be more chance of a bug or questionable change getting through.
reply
That's what I just said, people don't look at what they're downloading, they're trusting a false legacy. That's bad.
People that don't want to discern what they're downloading would then be less likely to download changes they don't need. That's good.
Core has multiple major versions per year, that's worse than many js frameworks.
The prescription isn't multiple forks, that just may be an outcome, the actual prescription is to prevent a politburo from impersonating Bitcoin.
reply
People that don't want to discern what they're downloading would then be less likely to download changes they don't need. That's good.
I'd say a loss in trust in bitcoin due to issues will be a bigger factor, even if those issues were isolated.
Core has multiple major versions per year, that's worse than many js frameworks.
That's not a metric I'd judge a project's coding practices by. I think something like the number of bugs and their severity would be better.
the actual prescription is to prevent a politburo from impersonating Bitcoin
I doubt that would happen. They might fool the gullible, but few else, imo. Certainly not big miners or businesses who would have a lot to lose if bitcoin failed.
reply
