pull down to refresh

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.
100 sats \ 2 replies \ @tomlaies 1h
but it's changed more like a fledgling javascript framework because of this disconnected relationship
Is that true?
I'm aware of code half-life measurements on Linux:
Would be interesting to see where Bitcoin Core falls on that spectrum
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
0 sats \ 4 replies \ @leaf 2h
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
17 sats \ 1 reply \ @leaf 2h
I can see your point about isolating impact, but I think what we'd ideally like is no issues. Even isolated issues would damage people's trust in bitcoin, especially if they lost money.
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
0 sats \ 0 replies \ @leaf 2h
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