But Bitcoin isn't just a FOSS project -- it aspires to be a currency, even a financial system of sorts. Currencies have a network effect; the more widespread their adoption, the greater their gravity, making a popular currency difficult to supplant.

I'm skeptical that the FOSS philosophy is the correct philosophy for anything which becomes harder to replace as it becomes more established.

It seems to me that the problem with Bitcoin is that its "consensus rules" (the flowchart to follow to decide a block of transactions as either being valid or invalid) aren't instantiated anywhere, but rather are just buried within the particular implementation details of BitcoinCore.

In an ideal world, you'd split these up:

1. there'd be a currency steering committee (with some structure whose ideal form is above my pay-grade) that produces a machine-readable validity ruleset (sort of like a DTD or XML Schema);

2. and then there'd be a proliferation of competing clients that all know how to parse those rulesets, and use them to validate blocks; but which otherwise go about their business of being Bitcoin clients in entirely separate ways.

With such a split, issues with the management of "BitcoinCore the FOSS reference client implementation" wouldn't overlap with issues with "Bitcoin, the ruleset that, in being instantiated in a majority of nodes, gives them a consensus chain." Instead, the first would just be a regular code project, no longer at-all critical; and the second would be something more like the project of defining a new version of e.g. the ePub standard, or of drafting an RFC.

There are several problems with this. Firstly, a machine-readable validity ruleset would basically just have to be a library implementing the rules, simply because of their complexity - for example, one of the previous validity changes requires scripts of a particular format to be treated as hashes of the actual script, which is provided by the transaction redeeming it. Secondly, bugs in implementations can effectively cause the to enforce unexpected additional rules, such as the BDB lock limit which caused an unplanned hard fork a few years back. Thirdly, everyone involved still needs to be a skilled developer with knowledge of distributed systems - especially the currency steering committee, since changes to the validity ruleset can break the whole thing in subtle and unexpected ways - and the committee still needs in-depth knowledge of the actual implementations to know if they can cope with their planned rule changes.

The challenge is that the rules are only legitimized by the clients choosing to follow them. You can't launch new rules until at least 50% of clients by weight are following those rules. There is no way for the ruleset to somehow disable or ignore a misbehaving client, you need consensus.

Right, this would just make the difference explicit: given a good spec for defining the rulesets, a client would be able to just give a drop-down for which ruleset to follow (or allow you to point the client at your own by URL, etc.)

They have been split up. Bitcoin Core now builds a separate library, libbitcoinconsensus.

but that has already happened, TFA is advocating moving to LibreOffice (BitcoinClassic).

BitcoinClassic has to do what LibreOffice has done first. Write more code, have more active developers, fix more bugs - be the better community for new developers etc. So far none of this happened.

That has been tried before with XT and it failed.

Bitcoin Classic is the attempt to change the reference implementation from the Core code to their code, by only changing as little as possible (that is, raising the 1 MB blocksize to 2 MB).

The current problem is not being more open to other developers but to get a different reference implementation installed on full nodes and miners.

Yeah, but that's a chicken and egg problem because unless/until BitcoinClassic outcompetes the other one, none of your code will ever get executed, so any developer wanting to scratch an itch must contribute to the existing bitcoin rather than BitcoinClassic.

The dynamics don't work the same way as a traditonal FOSS fork. Perhaps getting mindshare first is the way.

I know; and obviously Bitcoin Core aren't going to fire themselves. I'm just addressing the why they should be unseated, not the how.

(It's worth noting that Bitcoin Core supporters have been DDOSing people running the various attempts at a "LibreOffice" that've been tried).

DDOSing nodes does nothing to support Bitcoin Core.

Bitcoin nodes get DDOSed from time to time-- e.g. people incorrectly believe they're the node for some service they think they can extort. Sometimes users on bufferbloat afflicted connections mistake other users fetching the chain from them as a DOS attack.

That said, since these claims that people are DDOSing "Bitcoin classic" were first made, I've had someone running a classic node-- in the hope of identifying the attacker-- which has received no attacks. I don't believe the claimed attacks are widespread if they're even happening at all.

That's not the sort of DDoS going on here. Classic nodes are getting DOS'd in a way that Core is also vulnerable to.

Classic hasn't activated yet. If Classic were already accepting 2MB blocks, the chain would have already forked.