Yeahhh but from a practical software maintenance standpoint, there are risks.

Core's benefit is that it has a lot of eyeballs on the problem and extremely (and culturally calcified) review standards. It's like one company building all the railroads to extremely exacting standards. Everyone benefits from the smooth rides and reliably delivery schedules.

Breaking that tradition comes with tradeoffs. Less disciplined or scrupulous project maintainers can hide their lower standards or outright malicious agendas with affinity marketing, community-building, and Core conspiracy-mongering (think Roger Ver). And unlike altcoin projects, we still have to ride on their rails.

The problem is that Core it's now brimming with academics all eager to treat Bitcoin like a grant program -- they don't really give a fuck if there are practical limits to what Bitcoin should do that actually add to the value proposition. Thry dont live on Bitcoin. Theyre not heavily invested in its success. They wjist ant to do computer science, and Bitcoin is a great lab in which they can make a name for themselves.

Reply to this note

Please Login to reply.

Discussion

The upside to lots of code forks is that Core will now be so occupied trying to mitigate all the little incompatibities between their project and other implementations. That will siphon away their energy and appetite for building all their dumb wonk academic hobby horses.

My argument for many node implementations is mainly based on the fact that Bitcoin is a protocol. A node implementations only needs to implement the protocol.

But because all the eyes have been on Core for so long, the protocol has become so bloated and complex that it's the only game in town. There'll come a time when that bloat will cause Core to either collapse or become unmaintainable.

What's better? All eyes on Core, where only a handful of devs can manage the complexity; or a hundred times more eyes on a hundred different node implementations?

We're at a point where Core is so stable on the network, that alternative implementations can be made from scratch that either find themselves compatible with the overall network or not. The eye of nature is worth even more than the eyes of a hundred devs.

Only the runners of alternative nodes run the risk of whatever bugs there might be. But I just can't get over the fact that a protocol somehow only has one implementation in wide use, and I think that monoculture is more a risk than diversity.

There are two major lightning node implementations. So the pool of talents is now split. There are less eyes on wither project than there could be. There are competing agendas. And it's an extremely complex protocol where bugs from incompatibites are constantly arising, to the detriment of the users' experiences.

I'd rather that than everyone trying to fight for consensus in a single codebase, even though that's the most "efficient" way to do it. But I don't think efficiency helps a decentralized system grow strong, however frustrating that is.

And even if there were only one lightning implementation, you still need people to update their nodes to expand the protocol. But people tend to update blindly. If there were a more diverse ecosystem, one update in one implementation wouldn't put the whole system at risk.