Quote from: justusranvier on January 14, 2014, 03:56:09 PM

The most effective way to sabotage Bitcoin is to allow critical portions of the codebase to bitrot and block or delay critical improvements such that an alternative that is more palatable to the establishment would appear artificially viable by comparison.

Did you know, for example, that parts of the script validating code relies on undefined compiler behaviour that effectively makes gcc-specific quirks part of the Bitcoin protocol?

Instead of this being treated as an important bug that should be fixed it's just used an an example of why there shouldn't be diversity in implementations. After a while bugs like that start looking less accidental and more weaponized.

There's at least one good reason to leave it the way it is for a time: keeping the block creating nodes (i.e. miners) on standard code (file under "critical piece of code which a lot of money is tied up in"). Long term stability is important to this system, and the passage of time will do alot to make sure that different miners on different implementations can happily contribute blocks to the same chain. The better that all developers comprehend the system, both for the reference client and any re-implementation, the less likely we are to deal with the mild cataclysm of system-wide block rollbacks. If that means monopolising block creating for a while, then it's possibly not such a bad thing. I'd prefer that it weren't like this, but we have highly capable people working from both sides of the gulf, I've no doubt that the situation is as good as can be reasonably expected (for now).

And we know that creating a competing reference implementation is more than possible, the resources and are there to make it work, and any number of scenarios where core code is changed could provide the incentives. If the core-developers forced a revolt, then I'm pretty sure some significant minds would be concentrated to the task (including a possible off-shoot of the core team). I'm also pretty sure how aware all concerned are of this type of scenario in advance (especially capable coders with large amounts of coin who disagree with any design decisions. And you can expect that demographic to continue to grow, they're best placed to understand the value of BTC, after all).

Quote from: justusranvier on January 14, 2014, 03:56:09 PM

It's also kind of funny that when you collect quotes from the core dev team you find that Bitcoin inhabits a state of superposition between two states: it's simultaneously "just an experiment" and also a "critical piece of code which a lot of money is tied up in" depending on whether you're asking for quality accountability or asking for innovation.

Well, they are (core-devs) doing an awkward high-wire act. They're all publicly known, they didn't consider the relevance of protecting their identities to the same extent that Satoshi did. So handling the entire project overall (PR inclusive) must be a daunting task. It's difficult not to contradict yourself when trying to address independently non-discrete problems from a shared domain.