pull down to refresh
100 sats \ 22 replies \ @justin_shocknet 6h \ parent \ on: Undeprecate datacarrier PR rationale - @schmidty bitcoin
Yep, and I don't think I've seen anyone since make a compelling a case as to why it should continue as-is.
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
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
SegWit discount may still manifest itself as a much bigger problem than is understood today, and that was a result of compromise... Compromise being a dereliction of principles and "weak men creating hard times".
I'm not in the weeds enough to know the LOT history but I assume it's a similar story. These types of compromises only happen because of Core's positioning and the battlefield it's become as a result.
Without Core, no one has to compromise, it's a level field for ideas to compete on.
reply
If you're a pool, you can kill segwit discount today if you want to. You anyway need the witness data before you create your blocktemplate, so you can just calculate the inclusion fee as absolute per-byte. Fees aren't part of consensus. You can also enforce 1MB block space to include witness data. Your block template, your choice.
reply
But the centralized distribution of Core normalized it, where it wasn't before. Miners being rational market actors had the market rules changed on them by a politburo, one that leads the auto-downloaders.
Can't on the one hand worry about chaos by multiple distributions while ignoring the chaos caused by a universal one.
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
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
reply
Linux is probably a fair comparison in some ways since it's used in industrial systems, but not so much in others because it's constantly supporting new hardware. Bitcoin has no such need to respond to new hardware, or web standards in the context of frameworks.
The linux kernel gets a major several times a year, like Bitcoin, but businesses don't run the kernel... they run things like LTS or Enterprise distributions that only get majors every few years.
reply
For
29.1, not-fancy, format count year-of-commit, src/*.cpp only% find src -name "*.cpp" -print \
| xargs -n 1 git blame \
| sed 's/.* \([0-9]\{4\}\)-[-0-9]*.*/\1/' \
| sort -n | uniq -c
166 2009
247 2010
3382 2011
3433 2012
4558 2013
9181 2014
7356 2015
9203 2016
13201 2017
11980 2018
16129 2019
23999 2020
30487 2021
27968 2022
26245 2023
24693 2024
2074 2025
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
reply
Time will tell if the issues and trust damage we fear has already occurred and is just festering... this is only a conversation because trust has already somewhat degraded.
There was a market overhang from the bcash war, we may be in another.
The compromises made because of Core politics are likely to get worse not better #1232861
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