Empirical insights on BCHN

Aug 24, 2020
bitcoin

Once more, baffling events are unfolding in the Bitcoin¹ ecosystem, which seems to remain undecided whether technical competency matters - at all - for the conduct of a highly technical software initiative. A few months ago, a team of old-timers who had been involved - for years - in developing Bitcoin software, mostly via their respective contributions to Bitcoin Unlimited and Electron Cash, came together with another project named Bitcoin Cash Node (BCHN). This team² appears to be growing in popularity among some online media circles, and some people trusted them with nontrivial funding³.

As far as innovation is concerned, funding can fix many problems. However, funding cannot fix the lack of technical competence. Worse, in software, nothing can fix the lack of technical competence but a change of team players. Competency alone is not sufficient to succeed, but conversely technical incompetence invariably leads to failure, no matter how many investors get fooled in the process.

Based on empirical evidence from both recent and past software contributions from the BCHN members, this enthusiasm is misplaced. There are doubts that this team can even maintain the codebase they forked a few months ago⁴. Any hope that this team can deliver the state-of-the-art software infrastructure that BCH needs to outcompete its many rivals is lunacy.

As the BCHN team is contributing to open source projects, it is possible to assess the technical proficiency of its members by a direct examination of their public contributions. There are three codebases of interest: BCHN, Bitcoin Unlimited (BU) and Electron Cash. The examination of these codebases yields the following insights:

Six months down the road, BCHN contributions are thin and unremarkable. Nonetheless, BCHN has inherited the bad software practices that remain prevalent at BU.
BU, the most well-funded and long-lasting project in the BCH ecosystem, has been abandoned by all notable actors. No positive externalities seem to have emerged from this project either.
Electron Cash is an extreme case of haphazard software design, and yet the purest example of contributions brought by the BCHN members when left to their own devices.
The choice of freetrader (pseudonym) as the project lead for BCHN is all the more puzzling considering that he⁵ appears even less competent than his colleagues.

Based on these insights, it already appears highly improbable that BCHN will ever deliver anything akin to the ABC roadmap, but it is even less probable that BCHN will outcompete the numerous rival coins that compete with BCH.

BCHN insights

The contributions, so far, of BCHN are thin and unremarkable. Indeed, this project started as a fork of the Bitcoin ABC (ABC) codebase, and there hasn’t yet been any notable contribution that would make this codebase diverge from that of ABC. The most significant changes since the BCHN fork has been backporting later changes brought by ABC itself.

However, many of the bad practices that were in place at BU - more on this in the following section - have already been inherited by BCHN. Let’s two consider two backports operations: this one from ABC vs this one from BCHN.

The backport commit from ABC provides a meaningful title that conveys the work’s intent. It explicitly points out where the backport is originating from, i.e. Bitcoin Core (Core). It also explicitly points out that this backport commit is the first commit among a sequence of three, reflecting the logical backport unit. Finally, the commit ownership is properly assigned to the original Core contributor.

The backport commit from BCHN is basically incomprehensible. The title of the commit only contains the backport code number, which provides no clue whatsoever on the why or the what of the backport. There is no link toward the original contribution being backported. The code attribution is incorrectly assigned to a BCHN member while it originates from Core. Critical details about the commit are only found in BCHN’s ticket management system.

While the last point may seem arcane to the reader, it outlines an important problem with the BCHN workflow: while their codebase is nominally open source, their workflow is hostile to other teams who would like to benefit from their efforts. As commits are not logical atomic contributions to their codebase, it is exceedingly difficult for any third party to backport anything from BCHN⁶. Also, incorrect author attributions add another layer of friction for ethical teams⁷. Ironically, it’s the correct software practices of Core and ABC that offer the possibility for BCHN to backport work from them, while the converse isn’t true.

A second important problem with the BCHN codebase - looking at the commits done under the BCHN stewardship - is that the commit history is basically undecipherable. The majority of the commit titles contain only cryptic code numbers, which makes it insufferably hard to figure out what is going on. This practice not only hinders any attempt at auditing the code, it also further hinders any attempt at backporting anything from BCHN in the future.

The BCHN commit listed above cannot be dismissed as anecdotal, as the vast majority of the BCHN contributions to their own codebase are similarly flawed.

Another typical commit is the Merge branch ‘master’ into ‘master’ authored one month ago by the leader of the BCHN project. While this commit is essentially inconsequential - it’s simply some bits of documentation - the commit qualifies for a “random act of change” upon the codebase. The commit title is nonsensical. The commit comment literally paraphrases the commit content. The ticket attached to the commit is overly cryptic as well.

Overall, the BCHN team’s short commit history is already nearly indecipherable. Commit titles are meaningless. Commit comments are frequently absent, replaced by links toward tickets⁸. This state of affairs comes as a stark contrast to the respective commit histories of both ABC and Core, which are vastly more accessible to third parties and that stand on their own without over-emphasizing a specific ticket management system.

Bitcoin Unlimited insights

Four out of six BCHN contributors have been prominent BU contributors over the past few years. The BCHN project is basically a direct replacement of the BU project. BU has received the equivalent of a few millions of USD of funding⁹, yet after 5 years of software development efforts:

the BU codebase has been discarded by every single miner.
there has been no notable BU contribution ever backported anywhere.
there has not been any single attempt at forking this codebase for anything notable.

The BU “cowboy” development style has already been discussed. However, the circus continues as strong as ever. This late July commit attempts to “fix locking issue” (sic). Yet, there is no test, no review, no comment, no investigation on why the problem happened in the first place, no assessment of the impact for the community, no reason given why the fix works at all, etc.

The cherry on the cake: this commit breaks the indentation of the original code, which would have been trivial to fix. A half-way decent software engineer would have heard about linters, invented 4 decades ago to eliminate these sorts of mundane problems, but apparently the BU team did not, or more plausibly, does not care.

For years, BU has been relentlessly promoted by many actors. BU was presented as superior in practically every single way to ABC: morally, technically, politically, etc. Yet, reality does not abide to the madness of the crowds and earlier this year, several BU members and their long-time supporters finally came to their senses realizing that the BU codebase was essentially broken beyond repair.

As a result, the BU codebase was ditched entirely in favor of a “clean” fork of the codebase of ABC from which BCHN originates. However, there is little reason to doubt that BCHN will follow the path of BU: the same contributors are pursuing the same goals while applying the same software development practices; they will obtain the same software results.

Electron Cash insights

The Electron Cash (EC) codebase offers reliable insights in the endgame software product that will ultimately be delivered by BCHN (if any). Indeed, the most active BCHN contributor also happens to be the most active Electron Cash contributor. Two more BCHN contributors also happen to be minor EC contributors. Furthermore, the sort of problems tackled by EC are tightly related to the ones tackled by BCHN¹⁰. Thus, the software skills required to develop EC are essentially identical to the ones required to develop BCHN.

What makes EC so specifically interesting is that - unlike the BCHN codebase, which still remains a third party product (from Core and ABC) - it is fair to say that the EC team, at this point in time, truly owns the EC codebase¹¹. Thus, it is fair to say that this codebase - in its globality - reflects the BCHN team’s software engineering skills when left to their own devices. Indeed, so far, the BCHN and BU analysis was limited to the commits. It would not be reasonable to blame BCHN for the Merkle tree nonsense in their codebase while they inherited the problem from Satoshi Nakamoto.

The EC codebase is a horror show on so many levels that it is challenging to even summarize what is going wrong with this project:

Presentation, state, persistence, network and crypto are completely entangled.
Software boundaries are left unspecified¹².
For all intents and purposes, there are no automated tests.
Automated tests are essentially impossible “by design” (due to bad design).
There is no logging system, and error handling is random at best.
Rookie mistakes, such as magic numbers, are all over the place.
Comments are mostly absent. When present, they are worrying¹³.

The file main_window.py illustrates these problems and more:

It’s a Big ball of Mud with no discernible organization in the code.
It’s a The God object, with over 5000 lines of Python that glues everything.
It’s an Input Kludge where the “Receive” tab welcomes a payment request of 1 billion BCH.
Accidental Complexity is everywhere with QT plumbing permeating everything.
Busy Waiting is used to give an impression of security.
Coding by Exception is an accepted norm.
Error Hiding is the main approach to deal with errors.
Magic strings are all over the place.
Magic numbers are also all over the place.
Spaghetti code dominates with classes defined inside methods for no reason.
Etc.

Based on these observations, it appears that EC is a live example of a fair share of the software antipatterns ever documented. Figuring out the occurrences of the remaining antipatterns in the EC codebase is left as an exercise to the attentive, and very patient, reader.

A few days ago, the EC team closed a funding round based on a proposed roadmap. The EC team does not appear even remotely aware that their codebase carries a massive amount of technological debt. Liquidating this debt should take priority over everything else. There is a complete disconnect between the proposed roadmap and what is urgently needed.

At this point, adding more features to EC is irresponsible¹⁴. The only reasonable course of action is a complete overhaul of the EC development practices, followed by a meticulous incremental rewrite¹⁵ of the entire codebase.

The ‘freetrader’ leadership

The BCHN team is led by ‘freetrader’, an anonymous contributor who was part of Bitcoin ABC at the time of the creation of the BCH fork. This participation seems to have granted him an aura of “BCH co-founder”.

However, the close inspection of the 79 commits of freetrader spread over 6 months while he was technically¹⁶ part of ABC tells a different story. Those commits are dominantly mundane and minor: cosmetic nits, minor test fixes, minor BCH vs BTC changes, etc. This commit stream reflects the sort of basic, yet useful, work delegated to junior developers or interns while they work under the close supervision of their seniors.

If we look at freetrader commits in the BCHN codebase, we see more of the same, but with less supervision. A senior software engineer would probably not have a let the intern push nine commits all titled Merge branch ‘master’ into ‘master’ because it’s highly nonsensical.

The other code contributions of freetrader are remarkably devoid of ambition, like refactoring away the Mempool, the UTXO, or the locking insanity of the old Satoshi client.

Finally, a leader must also be judged by the directions given to the project. The roadmap of BCHN is quite spectacular in this regards (quoting):

Establish a professional mining node, which listens to feedback and delivers measurable improvements. Provide well-researched proposals for consensus rule enhancements regarding DAA, 0-conf and script improvements. Lead by example with specification-driven development that enables greater mining node diversity and increases BCH’s resistance to capture.

This prose qualifies for the purest grade of corporate happy talk: vague and consensual orientations associated with grammatical ornaments serving the ego of the organization itself: “professional”, “well-researched”, “lead by example”.

Conclusions

The contributors behind BCHN have - individually as well as collectively - demonstrated, over several years and hundreds of public software contributions, a lack of software engineering skills and, to a large degree, a lack of interest in acquiring those skills as well. Indeed, there is no discernible improvement of the work produced by the BCHN contributors over time. Their present-day software practices are as bad as they were three years ago.

Software engineers have been in high demand for several decades. However, there are serious doubts that any of the BCHN contributors would get hired in a respectable¹⁷ software company even for junior positions. Considering that the funding received by the various BCH projects is well below what is considered usual market rates for software engineers, one may wonder whether those contributors are not simply stuck with BCH projects for a lack of better professional prospects.

Predicting the success of a software venture is a lucky shot at best. However, predicting its failure, given that specific observations are made, can be done with near certainty. In the case of BCHN, the ample empirical evidence indicates - with near certainty - that they will not deliver anything of value to the BCH stakeholders no matter how much funding is made available.