Why aren't alternative implementations encouraged?

[PowerGlove]

Bug-resilience is only achieved if the N independent implementations all review every pull request that is submitted, only allow direct commits from a small group of people, and are tested thoroughly at a protocol level to stamp out regressions and accidential forks.

Can Bitcoin Core afford to do this? Yes, because it's manned by dozens of developers. Whether alternative clients could afford to do so however is doubtful. If you have an alternative client maintained by just 5 people, they might struggle to completely test and review all changes, let alone implement new protocol additions.

The hard fact is, most people do not want to maintain 200,000 lines of reference client code alone, which is the only reason we have a single client anyway. Otherwise this space would be buzzing with reference clients. Many promising OSS projects have been started by a group of a few people but fizzled out a few years later simply because the devs are burned out.

To understand how much 200000 (edit) lines is, I give this comparison: I myself am managing a codebase about six times smaller than this at work [nearly all of it written by yours truly], and even that is exhausting when done alone. I don't see how 5 or even 10 people can update a 200K-line codebase in a timely manner. So the question of having alternative implementations of a program at this scale has already been answered through the efforts of other developers: "No". (It's also the reason why, at 6 million lines of code, you don't see forks of the Linux kernel floating around.)

It effectively means that most clients would not styme progress by rejecting feature upgrades in Bitcoin Core, but they would quite literally not have enough manpower to implement them in the timespan of a few weeks. Thus the implementation takes several months or even years to develop, if at all. This unnecessarilly bogs down the schedule for rolling out the features to users at a protocol level, as there would be many users of the less-maintained client, but no work is being done to actively develop the required support for it although it could be desired by the alternative maintainers. In fact, it is very common for users to be using slow codebase, examples include every exchange whose wallet engine does not support native segwit addresses in 2022.

Or another example - Although some SPV wallets still don't support taproot, imagine if some of them were connecting to the protocol using an alternative blockchain, which itself has not yet implemented the taproot support code for lack of manpower. This would have had a downstream effect for those wallets which wanted to support Taproot addresses, but can't because it depends on support from the upstream reference client.

I enjoyed reading your post, but I think that what you've mostly addressed with it is why it's not possible (in practice) and not why it's not encouraged (the point of the OP). Of course, one could infer that it's not encouraged because it's not possible, but I don't think that's what's going on.

After digesting some of the answers above, I suppose it's no great mystery why the Bitcoin Core devs don't actively encourage outside implementations. It would make their lives more difficult and give them less control over the protocol and that's probably all there is to it.

I'm not entirely comfortable having a "de facto" majority implementation. I think that's too much power to concentrate in one team of programmers.

Right now, changes to the consensus rules can be blocked by lack of miner agreement. I think it would be better if they could also be blocked by lack of programmer agreement (i.e. an outside team refusing to update their implementation).

I'm aware that this would make implementing new features (especially controversial ones) nightmarishly difficult, but (in principle) I believe that's a good thing.

Obviously, any idea that leads to a glacial pace of feature development is not going to be a popular one, and I'm mostly just fantasizing out loud at this point

[HeRetiK]

Right now, changes to the consensus rules can be blocked by lack of miner agreement. I think it would be better if they could also be blocked by lack of programmer agreement (i.e. an outside team refusing to update their implementation).

Arguably that's pretty much what happened during the hardforks of 2017. The scenario you describe is less extreme, of course, but in the end that would be the logical conclusion.

I'm aware that this would make implementing new features (especially controversial ones) nightmarishly difficult, but (in principle) I believe that's a good thing.

Obviously, any idea that leads to a glacial pace of feature development is not going to be a popular one, and I'm mostly just fantasizing out loud at this point

Compared to most alts Bitcoin's development already is moving at a glacial pace And for good reason! But I fear increasing the political overhead would pretty much halt development and possibly even increase developer attrition.

[NotATether]

I enjoyed reading your post, but I think that what you've mostly addressed with it is why it's not possible (in practice) and not why it's not encouraged (the point of the OP).

I intentionally worded it like that, because I already addressed why its not encouraged in my first reply (i.e. the protocol becomes the least common demoninator, which is exactly what the protocol architects do not want).

[PowerGlove]

Compared to most alts Bitcoin's development already is moving at a glacial pace And for good reason! But I fear increasing the political overhead would pretty much halt development and possibly even increase developer attrition.

@HeRetiK: I agree with you, and I'm beating a dead horse at this point, but I have a different definition of "glacial" and would much prefer it if the design was basically set in stone, never to be tweaked again. I don't have the same appetite for improvements that most people seem to.

Of course, that's blithely ignoring real issues like quantum cryptography, but I suspect that even once Bitcoin is "post-quantum" there will still be many more upgrades than are strictly necessary, with each one being an opportunity to get something wrong, with possibly disastrous consequences.

I intentionally worded it like that, because I already addressed why its not encouraged in my first reply (i.e. the protocol becomes the least common demoninator, which is exactly what the protocol architects do not want).

@NotATether: Yup, can't argue with that.

[NotFuzzyWarm]

Compared to most alts Bitcoin's development already is moving at a glacial pace And for good reason! But I fear increasing the political overhead would pretty much halt development and possibly even increase developer attrition.

@HeRetiK: I agree with you, and I'm beating a dead horse at this point, but I have a different definition of "glacial" and would much prefer it if the design was basically set in stone, never to be tweaked again. I don't have the same appetite for improvements that most people seem to.

Of course, that's blithely ignoring real issues like quantum cryptography, but I suspect that even once Bitcoin is "post-quantum" there will still be many more upgrades than are strictly necessary, with each one being an opportunity to get something wrong, with possibly disastrous consequences.

I intentionally worded it like that, because I already addressed why its not encouraged in my first reply (i.e. the protocol becomes the least common demoninator, which is exactly what the protocol architects do not want).

@NotATether: Yup, can't argue with that.

Agreed.
Considering that BTC is a Financial System, it is admirable that so far the Core dev team have taken what in financial circles is called a Fiduciary approach to making sure the BTC network works securely as intended including an immutable and easily accessible record of all TX's back to the Genesis Block and nothing that is added breaks its intended purpose.

In lay terms it translates to, "Once something Works - DO NOT SCREW WITH IT unless there is a more than compelling reason to change it/add a 'Feature' to it". When there is a non-critical but valid reason, get a feeling how the major parties affected feel about the idea. If it is worth pursing then review the hell out of the code followed by tests the hell out of it with edge-cases before release. Rule #1 to that is Thou Shalt NOT Break Code! Everything created since day-1 (TX's) MUST be maintained and unchanged and seamlessly accessible by the new code.

I'm more than happy to let the altcoin folks experiment with interesting ideas for using blockchains and I'm certain that the Core developers watch what they do as well to see if what the alt folks come up with could *possibly* fit in well with "The BTC Manifesto" so to speak.

edited for text flow

[tiltedIceCream]

I enjoyed reading your post, but I think that what you've mostly addressed with it is why it's not possible (in practice) and not why it's not encouraged (the point of the OP).

I intentionally worded it like that, because I already addressed why its not encouraged in my first reply (i.e. the protocol becomes the least common demoninator, which is exactly what the protocol architects do not want).

Having the protocol be the least common denominator is exactly what the protocol architects should be striving for. Everything else is an implementation detail. To keep things truly decentralized the knowledge of how Bitcoin works should be spec driven. This allows every technical person to weigh in on the high level challenges of the protocol through documents like bips. A friendly environment towards more implementations also helps ensure a system of checks and balances where core devs can't dictate the direction of the protocol against the majority of user wishes just because they have market share.

A real-world case study of this approach can be showcased through web browsers. Sure most browsers are based on chromium but browsers like Safari and Firefox (and spin-offs like the Tor browser) have unique approaches to protocol implementations that many internet users value.

[PowerGlove]

I enjoyed reading your post, but I think that what you've mostly addressed with it is why it's not possible (in practice) and not why it's not encouraged (the point of the OP).

I intentionally worded it like that, because I already addressed why its not encouraged in my first reply (i.e. the protocol becomes the least common demoninator, which is exactly what the protocol architects do not want).

Having the protocol be the least common denominator is exactly what the protocol architects should be striving for. Everything else is an implementation detail. To keep things truly decentralized the knowledge of how Bitcoin works should be spec driven. This allows every technical person to weigh in on the high level challenges of the protocol through documents like bips. A friendly environment towards more implementations also helps ensure a system of checks and balances where core devs can't dictate the direction of the protocol against the majority of user wishes just because they have market share.

A real-world case study of this approach can be showcased through web browsers. Sure most browsers are based on chromium but browsers like Safari and Firefox (and spin-offs like the Tor browser) have unique approaches to protocol implementations that many internet users value.

That's very well put, and exactly how I feel. Have a merit and welcome to the forum!

[NotFuzzyWarm]

Having the protocol be the least common denominator is exactly what the protocol architects should be striving for. Everything else is an implementation detail.

What you describe already exists: Sidechains such as LN that at their base level are tied to Core and the main BTC network.

Sidechains lets folks explore a myriad of possibilities as long as in the end it's compatible with the BTC protocol while (hopefully) having zero or at worst only a minuscule chance of undesired impact to the main BTC blockchain. Any risk in using the side-chain MUST be only to the operators of the side-chain service and its users and not anyone else using BTC. Again, if what those side-chain folks come up with truly serves a truly needed purpose then ja, the Core devs should consider it provided it does NOT break anything or otherwise extensively modify the basics of how the BTC network operates.

[pooya87]

Let me disagree with two statements that were posted here which I call "assumptions".

1. Alternative implementations would disagree with any protocol change and cause problems
First of all this is not a bad thing, Bitcoin is not a dictatorship to fear any kind of disagreement with or rejection of proposals by others. In fact other opinions contribute to improvement of the proposal and help see the mistakes and come up with better proposal.
Secondly other implementations doesn't mean the devs can't come together to discuss proposals in one place. In fact alternative projects brings developers from other programming languages together.
Finally, if the proposal is any good, there shouldn't be any disagreements or rejections.
In the end the community (ie. miners + nodes + economy) should decide not the developers.

2. Alternative implementations would have inadequate number of developers
This is a false assumption in my opinion. Any serious project would get enough contributors to keep it going. BTCD example I posted earlier is a good example of a project with enough serious developers, Electrum is another example (SPV implementation of the protocol).

[NotATether]

Having the protocol be the least common denominator is exactly what the protocol architects should be striving for. Everything else is an implementation detail. To keep things truly decentralized the knowledge of how Bitcoin works should be spec driven. This allows every technical person to weigh in on the high level challenges of the protocol through documents like bips.

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.

A friendly environment towards more implementations also helps ensure a system of checks and balances where core devs can't dictate the direction of the protocol against the majority of user wishes just because they have market share.

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{1}).

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. 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.

edit {1}: I call it a bug, because it is impossible to view transaction history & balance on a restored wallet via the RPC otherwise.
edit {2} bbcode formatting kludge
edit {3}:

2. Alternative implementations would have inadequate number of developers
This is a false assumption in my opinion. Any serious project would get enough contributors to keep it going. BTCD example I posted earlier is a good example of a project with enough serious developers, Electrum is another example (SPV implementation of the protocol).

Seriousness can't be measured in terms of developers. Because developers can quit but the project does not become any less serious. The quit factor will always be there, since someone started the project which means there is at least one dev for it.

They might quit because the code is perfect (in their opinion) and nothing more needs to be done. Or they might quit due to outside factors, entirely unrelated to code - especially because most of them work for free. Many an abandoned linux project falls in the second category of this thinking, by the way. We can't say that those are not serious projects.

[Wind_FURY]

Now, I'm aware that nothing prevents anyone from attempting an alternative implementation and that someone could conceivably read the source code and proceed from there.

Alternative implementations do exist though. Like BTCD.

Shouldn't the reference implementation be one of many?

There should be only one reference implementation but other alternative options for people to run as full node.

..
BTCD is not a unique node that allows people an alternative path to make protocol Bips or upgrades features from.
read their comment on the link YOU provided

Debatable. Because the BTCD developers are outside the political process of the Core developers. It can also be debated that IF BTCD starts gaining a larger following, it can create their own political process and compete with the Core developers.

In that hypothetical situation, it's probably A "good" for decentralization, but it's also debatable IF the "other implementation/reimplementation" is "still" the Bitcoin protocol.

[pooya87]

Let's not change the discussion from the title into whether BTCD was a good example or not.

[ABCbits]

A real-world case study of this approach can be showcased through web browsers. Sure most browsers are based on chromium but browsers like Safari and Firefox (and spin-offs like the Tor browser) have unique approaches to protocol implementations that many internet users value.

It's great example. Now i'm inspired to try running alternate Bitcoin full node implementation and will write short review/guide about it within next few days.

--snip--

as for saying 'its just following consensus'. which you forget, whom is in control of consensus changes. yep one dev team, and who is that dev team.. (rhetorical)

Just wondering, do you think are any implementation which do more than following most/all consensus? If yes, do you currently run such implementation (even if it's not running 24/7)?

[garlonicon]

Just wondering, do you think are any implementation which do more than following most/all consensus?

Yes.

If yes, do you currently run such implementation (even if it's not running 24/7)?

Yes, 24/7, with some minor halts for maintenance.

For example, there are nodes that accept free transactions, and they are used for P2P messaging. As long as free transactions are rejected by miners, it is safe enough. If those transactions will be accepted, then it is possible to switch to negative fee transactions with proper sighashes, then it is doubtful that any miner would attach its own coins to mine that.

[aliashraf]

Hello everyone, my apologies for not quoting/following a specific post, I've read and enjoyed all, now I have something to share:

A tribute to redundancy

Any  software is susceptible to containing bugs, lurking in the shadows, waiting for the show-time.
However, bugs are not magic, they can be identified and fixed through code review and testing, yet there is a trade-off between 1)the resources one dedicates to this process and the wasted opportunities resulting from delays in launching the code, and 2)the actual risks that are involved and have to be addressed. An infinite resource and time allocation, theoretically can address almost all the risks, but it is not how we develop software in real world.

So, what alternatives do we have to deal with mission-critical software where failure is not tolerable? It is established practice: redundancy. Unlike what is trended here, I'm in support of redundant alternative clients.  

As of the fears, uncertainties and doubts which Satoshi has triggered about the possible chain splits, I'm not proposing it as a naive scenario in which competing clients are exposing the network to unintentional forks, etc. On the contrary, I think it was Satoshi who put bitcoin in bug-related risks by discouraging alternate implementations. Hence, CVE-2018-17144 was his fault and not Peter Wuille's. Devs are entitled to make mistakes once or twice a year, it is the architect who is in charge of fault tolerance and risk management.

Obviously, for bitcoin as a new class of distributed systems, naively recommending multiple implementations is not reasonable, the same as unbelievable recommendation of one god, one client! As a more detailed assessment of the risks would reveal, there are 3 class of untolerable, high priority failures due to bug where non of them is truly addressed by neither of the two architectures under consideration. Let's take a look:

Risk #1: Unintentional forks happen with disastrous consequences, because of different nodes, implementing different clients or different versions.

Risk #2: Nodes explicitly and widely compromise official protocol specs, yet consensus is reached by a considerable portion of the network.

Risk #3: Healthy, protocol compliant nodes are not able to bootstrap as a result of mild versions of the above case, where the breach is considered to be tolerable, hence no roll-back or even bug-fix is applied.


Single (dominating) client architecture:
#1- Is not fully adequate, even for risk #1 because of the versioning and slow adoption process. Despite huge dominance in the network, bitcoin development and versioning follows an exaggerated conservatism and undergoes an exhaustive dedication of time and resource in the upgrade process, a clear deviation of state of the art agile development methodologies with huge resource and opportunity lost consequences.

#2- Fails to meet any measure against this risk. The CVE-2018-17144 mentioned above, is the nearest case (yet not an exemplary one) where a bug can stay in shadows for long times, being inherited version by version, getting enough dominance in the network waiting for the show-time, usually the worst time ever.

#3- Can enforce circumventing measures like what is called "consensus bugs" by Core devs and BIPs are required to comply, a reasonable approach, I've to admit.

Naive multiple clients architecture: ( where we have different implementations installed by the nodes deliberately)
It suffers from the same problems as the single client model with different degrees of severeness, better for risk #2 and worse for #1, to be specific.


I'd suggest a third model: an Enhanced Heterogeneous Multiple Clients Architecture, as follows:

1-We classify nodes into 2 categories, high-end nodes with more critical mission with regard to the owners' expectations and resource allocation (we expect them to be properly aligned, i.e., more expectations ---> stronger nodes installed).

2-We encourage/support multiple alternative clients to be developed by different parties, with diverse platforms.

3-We certify, introduce the client software after passing the appropriate checklists.

4-Implementations are supposed to meet a well-defined integration spec via RPC/API/..., for supporting a robust voting module, called before  changing the state of the blockchain and (optionally) the mempool.

5-We recommend first class users to install 3 different clients of their choice, ordinary less critical users are free to choose one client of their choice,

As a result, bugs cause disagreements in high-end nodes which are resolved by voting, just triggering bug alerts, while the affected low-end clients are not supposed to cause catastrophic damages. Other than very high fault tolerance, it has an astonishingly huge boosting effect on development process.

AFAICT, there is no other comparable architecture for a system such as bitcoin while, interestingly, huge impacts on everything discussed here will be in the horizon, positive impacts, for sure. Bests of both worlds are achieved, and the network is guaranteed to have an astronomical level of fatal failure resistance. Use your own imagination  

[Wind_FURY]

Let's not change the discussion from the title into whether BTCD was a good example or not.

That wasn't the point. The point was, in my opinion, reimplementations should be discouraged because of the reasons that I posted in reply to franky1's post. That was only the hypothetical situation. BUT the actual situation is, there's not enough users that matter who run those other implementations/reimplementations, which could also be debated that it can only pull contributors away from Core, and could make Core's developer community smaller, and therefore possibly making its development process more centralized.