Empirical insights on BCHN

Once more, baffling events are unfolding in the Bitcoin1 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 team2 appears to be growing in popularity among some online media circles, and some people trusted them with nontrivial funding3.

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

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 BCHN6. Also, incorrect author attributions add another layer of friction for ethical teams7. 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 tickets8. 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 funding9, yet after 5 years of software development efforts:

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 BCHN10. 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 codebase11. 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:

The file main_window.py illustrates these problems and more:

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 irresponsible14. The only reasonable course of action is a complete overhaul of the EC development practices, followed by a meticulous incremental rewrite15 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 technically16 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”.


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

  1. In the present article, Bitcoin always refers to Bitcoin Cash. ↩︎

  2. The BCHN team is led by ‘freetrader’ (pseudonym). Other team members include Calin Culianu, imaginaryusername (pseudonym), Dagur Val, BigBlockIfTrue (pseudonym) and Andrea Suisani. The other contributors to the BCHN codebase are too little involved to be considered as team members in any meaningful way. ↩︎

  3. BCHN co-founder Calin Culianu declares 700k USD worth of funding. Retrieved on Aug 21, 2020. ↩︎

  4. The BCHN project was created as a fork of Bitcoin ABC codebase in February 2020. ↩︎

  5. As men are exceedingly dominant among “crypto” software engineers, I am assuming that ‘freetrader’ is a man. Using ‘her/him/they’ instead of ‘him’ simply feels too tedious. ↩︎

  6. BCHN was founded on the premise that ABC is morally corrupt and does not act in the best interest of the “community”. ↩︎

  7. One of the mainstream open source community’s key ethos is proper author attribution of the source code. There is no specific enforcement of this code of conduct, however breaking it is heavily frowned upon - just like lack of personal hygiene is heavily frowned upon in modern societies. ↩︎

  8. Before a commit takes place, the matter at hand is usually first discussed between the parties. This discussion usually takes place on a web-based ticket management system in one form or another. Unlike the commits, which are expected to be durable, discussions are typically considered as ephemeral and treated as such. In terms of ticket management system, BCHN is using GitLab, Core is using GitHub, and ABC is using Phabricator. ↩︎

  9. BU has received the equivalent of 500,000 USD as BTC back in August 2016. Considering the considerable appreciation of BTC that followed, it is reasonable to consider that BU was funded in excess of 5 million USD. ↩︎

  10. EC is a bitcoin wallet, and the respective codebases of ABC, BCHN and Core all contain a wallet as well. ↩︎

  11. EC was originally forked from a project named Electrum. However, the EC team can claim 4,000 commits out of 11,000 commits. They have been running the project as their own since the inception of BCH. Backports from the original Electrum project play an inconsequential role in their recent development. ↩︎

  12. EC relies on remote blockchain indexers. The interactions between wallets and indexers are nontrivial to say the least. ↩︎

  13. See this comment # eval is generally considered bad practice. use it wisely! followed by a call to eval, no reason is given why this call in particular isn’t just bad practice. ↩︎

  14. EC is supposed to be a wallet that manages real money for real people. There is an ethical obligation of not using the general public as Guinea pigs when it comes to this class of software. ↩︎

  15. Considering the dismal situation of the EC codebase, it would probably be easier to start from scratch. Some may argue that such an effort would not bring value to the community. Well, the port authorities of Beirut were equally unconvinced that getting rid of all this ammonium nitrate would ever bring any benefit to their community as well. ↩︎

  16. Those 79 commits over 6 months hint at a light commitment, not more than 1 day of work per week. ↩︎

  17. Such as Mozilla, Redhat or Odoo for example, assuming there is a specific interest for an open source software company. ↩︎