Well yeah, as someone who is busy drafing a BIP right now (about standardizing the message verification algo - but that's an entirely different topic) - I am very happy that I can spearhead an improvement without having to maintain entire modules of BTC code first. And from what I know, the BIP merely has to reach a consensus with other people like me i.e. other mailing list posters - in order to be generally accepted. Here is a lot of power in the community's hand already, and pretty much explains, in a practical sense, why nobody has attempted a serious alternate implementation - because the BIP system for improving Bitcoin already lets them vote on changes they like and reject the ones that they don't like, so that's what they do. Read below for an explination for why this pevents protocol divergence.


When I was talking about developers, I was referring to anybody who'd be interested in contributing code to Bitcoin Core, lest my position be misunderstood.

I'd certainly not be happy if Core code contribution was entirely done by achow and a small group of people, because then the little devs would be shut out (and I'm already not happy with Electrum devs, for leaving my bugfix PR dangling for months without even a comment about it <- this is what you get when implementations or protocols are managed entirely by 3 or 4 people).

Having said that, most of this discussion has been very theoretical, because intra[/]-protocol LCM has already been achieved due to the BIP voting system you mentioned, which is open to developers of all clients[/url]. Mathematically speaking, consensus converges to some number.

Whereas inter-protocol LCM is pretty much non-existant because attempts to create the conditions necessary for one, via the opposing developers' own client plus its own system of proposals that do not carry over to BIPs, eventually lead to a chain split anyway [like Bcash]. A consensus divergence to infinity basically.

Let me repeat, that creating an alternative client does not in itself create the necessary conditions for divergent protocol improvements between them. (I have not seen libbitcoin server make a single part of the protocol different from Core, for example). I think we can all agree on this.

Also, implementing some BIPs but not others does not create the necessary conditions for divergent protocols either, as most of them can be implemented independently from each other.

What *does* create divergent protocols is when the other alternative client has a different system for making improvements to the protocol (ie something other than BIPs) or if it has no improvement system at all and merely adds protocol features at a user's or developer's whim. Unfortunately this is what most people who don't like the protocol do - they fork not only the client, but also the BIP system. That is to say, from that point BIPs for one protocol will not apply for the other (unless they are proposed to both protocols), and vice versa.

And the reason why they don't make alternative clients in the first place has been written in my second post. The few tough lot like Libbitcoin who have succeeded in making an alternative client, do not burden themselves with maintaining a clone proposal system - which is necessary for the concept of divergent protocols to exist.

There is generally a reason why people make alternative implementations in the first place - it's usually not to cause protocol divergence (and since most people make clients exactly for this purpose I have been specifically warning about this type of client earlier), but to implement non-protocol features that are not present inside Bitcoin Core. For example, RPC calls and command-line options. Maybe a better way of selecting peers, or a way to kick out spam & bot peers which does not exist for Core. They are implementaiton details, after all.

Very few people make a client for this purpose anyway, because it's cruel, menial work. They very much perfer to make their own protocol so they can be more glamorous and advertise how their protocol (which they usually refer to as a "coin" - they are doing this as a hardfork anyway) is so much better than the first one.