ABC Dragging Feet or Existential Choice?

Recently a video appeared in the media where Roger Ver accused the developers of Bitcoin ABC of dragging their feet when it comes to doing what is needed to allow for longer chains of unconfirmed transactions as Bitcoin.com and someone at Satoshi Dice has been asking for this for a while. The tone and content of the complaint was surprising, as there has been quite a bit of discussion about the subject both in public and private meetings. A consistent answer that I have seen being given by developer of Bitcoin ABC and others is the absence of sufficient and sustained resources results in the Bitcoin ABC team being unable to address this issue, even though they would really like to tackle the problems causing the need for this limit. 

The Bitcoin ABC team’s Phabricator repository provides a clear view into exactly who has been doing what in Bitcoin Cash since the first BCH block was mined in August 2017.  When all the information is analysed and a dose of good old fashioned common sense is applied, one can only come to the conclusion that Bitcoin ABC is not only correct in their assessment of the situation and subsequent decisions, they would in fact jeopardise the ability of the Bitcoin ABC team ever reaching the goals of creating a software client capable of processing a global peer-to-peer Cash sized transaction load, if they were to decide differently.

Their current resources allow them to work towards the goals shared by all network participants, albeit at a crawling pace due to low resources, both human and financial.  Doing the work needed to make a significant change in the ability of the software client to process these long chains of unconfirmed transactions, would remove the ability to keep moving forward and would possibly even remove the ability to keep up with necessary maintenance work, in the long term. 

All successful business owners know that biting off more than you can chew can not only cause major problems, but when the effects on future workload are irreversible, it can actually bring a project down. Given the minimal resources that have been available in the past two and a half years, giving in to the increasing pressure put on the team by major economic players would be a mistake that could turn out to be very costly. Without a solid commitment for sustained resources being in place it would be very dangerous. The choice before Bitcoin ABC is not one of wanting or not wanting to help businesses asking for a change, the choice is existential. 

The 25tx Limit

Let’s start with identifying what these parties are requesting a solution for. BitcoinABC code base has in it a limit to the number of chained unconfirmed transactions. Imagine spending BCH, then spending the change that returned in your wallet and then spending that change and so forth until you have a chain of 25 transactions. At that point the Bitcoin ABC mempool code stops accepting additional transactions in that chain.

The reason for this limit is that due to the existing design of the code these chains result in miners having to do a lot of computations when processing these long chains. The computation load is quadratic so these computations get way more difficult with each extra transaction added to the chain. The limit is there to make sure nobody is able to attack the network by making a chain that would be too difficult to compute within a reasonable amount of time. The problem is of course more complicated and others have discussed it in detail elsewhere. Most important is to know that the problem is real and the limit there for a very good reason. 

Effect of Limit on Use of BCH as P2P Cash

Most people using Bitcoin Cash for its primary monetary use (peer-to-peer digital cash) will never run into this limit or will easily find ways around it. Few people will make 25 transactions between blocks being found and even if they did, having a few different inputs in different addresses in your wallet would solve that problem as one would simply start using a different input when hitting that limit. Until a block is found and everything gets confirmed at which time you can again use start making chains of 25 transactions. If one does run into the problem it is simple to solve for the future by splitting larger portions of coins into smaller by sending them to different addresses in the same wallet. So all in all the limit is at best a minor inconvenience but mostly a non issue when using Bitcoin Cash as money. 

Who is Affected by this Limit?

However there are some applications and use cases which do use on-chain transactions that respends coins quickly and therefore end up running into this limit on a regular basis. One of those is Satoshi Dice where people make small bets over and over again with the betting app paying out immediately. As such it is a non custodial betting option that generates many small chained transactions. Betting is emotion often and it obviously is not ideal if someone betting has to wait for a confirmation before he or she can again play a number of times until the 25tx limit is reached. 

Another use case I believe is related to Memo.cash where people post messages using on-chain transactions that include an Op_Return message. As with all social media platforms, users may like to post many messages and being rate limited during a time where blocks come slow can be frustrating when in the middle of a heated discussion with someone.

A use case less familiar to me, so forgive me if I get it wrong, is dividends paid out to SLP token holders or some more general token distribution use cases. Apparently this is also something that suffers from running into the 25 unconfirmed chained transaction limit. This is not something I have worked with myself so I don’t really know if these chains are unavoidable. It may well be that there are ways to work around this limit by clever coin management and wallet designs but I lack the knowledge to know this for sure.

To Fix or Not to Fix?

Given these use cases and the way all these use cases do attract attention from both speculators as also businesses interested in leveraging available technology and infrastructure, it seems reasonable to ask for a solution. Looking at available discussion and information I was unable to find any fundamental disagreement on the desire to remove this bottleneck for these use cases.  So why has Bitcoin ABC not done the work to fix this? For this, one has to understand what Bitcoin ABC does, how and with who. 

Bitcoin ABC’s Job Description

1 - Maintain the Software

The first task of a software team is to maintain the software. This means: do the work to keep it functioning with the same quality and reliability as before. Some people think that when software is written it is done, and you can just continue using it as is for years and years. But this is not the case. The software interacts with hardware and other software and as this changes continuously, the software has to change with it or it will start to malfunction. Additionally, vulnerabilities are being discovered in software and hardware regularly. This leads to maintenance work needing to take place. All this does not result in improved functionality, better code architecture or improved testing framework. It simply is work needed to avoid deterioration. One has to run to stay in the same place. 

With well architectured cleanly written software, without technical debt, the resources needed for maintenance is at its lowest. Badly architectured code filled with technical debt causes the workload to increase a great deal. The Bitcoin software, as it was released in those early days of 2009 ,can not be described as well architectured production code. I have seen it compared to proof of concept code and given its history this is understandable but it does cause issues for todays developers and ecosystem. As the software developed out of the original Satoshi client is often described as fragile and spaghetti code that is really hard to work with and on top of that there is no formal spec of what the code is actually supposed to do, you can imagine that the maintenance task that ABC has is substantial. This is a perfect example of paying technical debt created in the early days of the project. 

2- Increase the security and reliability of the code

The Bitcoin C++ code base had a notoriously poor internal test structure. These tests make sure that there are checks that run with ensuring pieces of the code are doing exactly what they are supposed to be doing, even after internal or external changes were made. Later changes and additions also often lacked sufficient tests. During more recent years there has been ongoing efforts to increase the security and reliability of the code making the chance of mishaps on the live network less likely.

3 - Reduce future Maintenance load

By removing technical debt and unnecessary complexity, improving internal testing and working towards a cleaner more robust architecture, one reduces future maintenance load and complexity. It is an investment that needs to be made. Especially in a situation where infrastructure funding is an unpredictable factor. Reducing the future load ensures that the smallest possible team would still be able to maintain the code base that helps secure the network and additionally it will free up available developers to work on the improvements and optimisations needed to reach the goals laid out in the roadmap. 

4 - Work towards the goals of the Bitcoin Cash Project

The Bitcoin Network Split that took place on August 1st 2017 took place for very fundamental reasons. At the center of the Bitcoin Cash project lies the desire to do what is needed to enable peer-to-peer digital cash. To bring economic freedom and financial sovereignty to the global population through permissionless uncensorable, peer-to-peer digital money. The removal for the need of a trusted party in the middle, a way to transact permissionless. The current roadmap is a solid expression of the goals of the Bitcoin Cash project and so the 4th Job Bitcoin ABC has is to work towards those goals using the roadmap as a guide. That does not mean that the roadmap is a rigid path towards the future. A team always needs to continue to look for improvements and things can be reevaluated. But although the path can change, a team should not let the goal out of sight. Peer-to-peer digital Cash for the global population is the reason for Bitcoin Cash’s existence and any team working on its crucial infrastructure has the moral obligation to ensure that remains the destination. 

Why Not Do Code Architecture Improvements Later?

Why not change the order of things and prioritize number 4 first? Why not concentrate on only minimal required maintenance and do all the needed functionality changes first? It would increase useability, attract more investors, users and businesses. Would it be better to just think short term and ignore things like technical debt and the future work load for a bit while we can concentrate on selling the Bitcoin Cash blockchain project to the world?

Current Workload

Current combined work has already become a load that is too large for the Bitcoin ABC team to do by themselves. There is however an advantage that lowers this load and makes it possible for them to not only accomplish the work, but also slowly work on the improvements needed to reach the roadmap goals. Bitcoin ABC code base is forked from the Bitcoin Core software. And Bitcoin Core has a large number of very active, well funded professional developers who maintain the Core software with a reasonable standard. Additionally they have managed to bring about a lot of positive changes that increase the quality of the code base and lower the time needed for maintenance in the future. Work that given their very limited resources (both human resources as also financial resources) would be impossible for the Bitcoin ABC team to accomplish by themselves. 

Leverage the Resources of Other Projects.

Because their software is a fork from the Bitcoin Core software, the Bitcoin ABC team can use work done by that much larger team through a process called back porting. Instead of having to do the work yourself, you find the pieces of work that can be used and bring them in your code base. If a section of the code has not been changed the work can be brought in most simply. One Bitcoin ABC dev can do the work of many developers this way. However this works most efficient when the code is identical or only has very few changes. The more changes there are in a Bitcoin ABC code base the harder it becomes to back port from Bitcoin Core and the more work a developer needs to do to accomplish the work. Where before one developer could bring in the work of for instance 6 developers, this now gets reduced to 3 or 2 or in the worst case, back porting becomes no longer possible or beneficial and the code needs to be maintained without leveraging the work of others. 

The Cost of Making Changes

As such, every change made to the code base has a resource cost for the creation of that change and the peer review and revisions needed during its creation process and then there is additionally a cost due to reduced efficiency when back porting or even worse, when doing maintenance and future needed improvements Bitcoin ABC will no longer be able to use the manpower provided by Bitcoin Core due to the changes made and will need to do all the work itself. So even if a change does not take much time to implement, it can change things in a way that will cause large drain on resources forever going forward.

Bitcoin ABC Resources since 2017

The Bitcoin ABC team, through its lead developer Amaury Séchet but also through others, recently has made no secret about the fact that the team is lacking funding and as a result has limited resources. Even if one does not believe this and think it is just greedy devs looking for more money and power, one can simply go to the Bitcoin Cash Phabricator page and check who has been doing which work over the past years. Put together a timeline starting before August 1st 2017. Who was doing the work over time and how much work was done. I am sure it becomes clear very quickly that Bitcoin ABC started with very little help. That you will find that many that talk the talk, did not walk the walk. One would think that those that were helping shortly before the split took place and who voiced their support very publicly, would stick around to make sure that the Bitcoin ABC code base and other infrastructure was providing stable value to the network. Looking at Phabricator I am sure you will see the reality of what happened. 

A Few Heros Doing The Heavy Lifting

Over the past 2.5 years the work done to maintain the Bitcoin ABC code and get it in a better shape, preparing for a future of peer-to-peer global cash for the world, was done by very few people. This is the harsh reality. So now after all this time a leader of such a team has a very clear picture of what production can be expected given the human resources available. He also will have a good idea of what effect on productivity additional divergence from the original code base has. During the first half of this year, the reality was that the available workforce managed to slowly catch up on backporting from Core. So finally progress was being made and the workforce in ABC was not only able to keep up with Core by leveraging their work but was able to reduce the gap that was caused by hardly anybody doing the work at the beginning of the project. Along the way some much needed changes were made as Bitcoin Cash is obviously not the same project and has different requirements. But each such change had additional future workload as a side effect and cost . When choosing what to do and what not to do the emphasis has lately been on doing things that have large positive impact on the network keeping the goals of the project in sight, while not adding too much future workload or where possible choosing options that reduce complexity and reduce future workload.  

Why Not Just Do a Quick Fix?

Some people have proposed doing a quick fix. A work around the problem that would alleviate the problems without having to redesign or refactor the relevant parts of the code. If you understand how diverting from the Bitcoin Core code base causes a lot of extra future work load for a team, you may also understand without having in depth technical understanding, that quick and dirty fixes would also create divergence and therefore add to the future maintenance work load. But even more importantly they will  increase future workload even more as they would add technical debt and possibly make other desired solutions planned for the future more difficult or maybe even impossible. To be certain about the complete added future workload of such a proposed quick fix one needs to understand it in all details. A professionally written specification of such a fix is essential in understanding the proposed code and its short and long term effects on the project. In general a software team will want to minimize adding complexity and for a project that supports a large and high valuable ecosystem they will definitely avoid adding code and algorithms that they do not fully understand the short term and long term effect of. 

“We Want to But We Can Not”

When watching the video of BCH Dev meeting number 12 in July of this year, Bitcoin.coms Emil Oldenburg asks about the 25 tx limit. I will quote some of the answers he got but will encourage everybody interested in this subject to watch or rewatch that meeting video. https://youtu.be/k4P_U_IKxKU starting at the 10:55 time mark. 

Amaury explains: “You gotta realize that that limit is in place because of how the data flow across the whole software. this is very very significant refactoring”

This of course means that the work would also create a large and lasting divergence from Core code and that is confirmed by the next answer he gives:

“so like there are multiple facets to that problem but I'd say the biggest problem is not really the path, the biggest problem is that anything that we change we cannot then back port from Core and we will have to maintain it ourselves. In the current state of affairs, it's very difficult to take on more on that front.” 

So if you understand what I tried to tell you above then you understand what he is saying is: We have a team that is small and no additional finances to grow that team. As a result we are barely able to keep up with the work that we are obliged to do as a responsible professional software provider supporting a billion dollar network and industry. We are currently only able to crawl towards our goals and any changes that right now add a sustained workload to our project will take away our ability to make progress and will in fact make it impossible for us to reach the goals that we set out to reach when first presenting this client and project in Arnhem one month before the split took place. 

Priorities

The first obligation the Bitcoin ABC team has is to keep chasing those goals and not create a situation where they are forced to pivot away from them. And to do so while reducing the chance of bugs as much as possible by only allowing production quality work and insisting on processes and procedures that are unseen error limiting and requiring everybody in the team to not only write code but also review rigorously the code of others.

What Amaury Séchet has been trying to tell everybody is that given the current workforce and funding, Bitcoin ABC can not take on much additional work but even more important it can not take on work that risks rendering the team unable to make progress reaching the primary goals. 

Plan That Could Bring Back Coin-Age Prioritization.

So is there anything that can be done? Well, there is. 

In Bitcoin Cash developer meeting number 12, Amaury Séchet and Mark Lundeberg discuss a path forward, which makes total sense. It is a large refactoring job and would diverge long term from the Core code base so it would add to the future work load a great deal. However, listening to it, you will see that there are also a lot of benefits to this approach as it would remove the reason for the limit entirely and would improve the fundamental design in a way that would reduce other problems and allow for many other improvements. For instance, it would lead to the possibility of bringing back coin age based transaction prioritization which would be of great benefit as it would ensure that certain attacks. For instance spamming the network would no longer risk affecting and degrading the user experience for normal users of the system, as the coins used in their transactions would most likely be old enough to be prioritized over those of an attacker. This was a very neat system that was part of the original client but was taken out by small block advocates that believed full blocks and a fee market were needed for Bitcoin to work. 

Hands Are Tied

So in my view the possible future laid out in the meeting mentioned above is something that I think many would be very enthusiastic and supportive of. It would not only reduce the problem that Roger Ver and others are campaigning to have reduced, it would be eliminated entirely. And even more important, it would improve the overall design of the software in a way that would be clean and logical and bring much future benefit. That meeting also makes it clear that Bitcoin ABC really wants to be able to do this work as they clearly have a good plan and believe in the benefits it will bring. But their enthusiasm and willingness does not take away the current reality that their hands are tied due to limited resources.

Limited Positive Effects of Infrastructure Fundraiser 

One positive thing has to be noted when it comes to resources. This summer a public fundraiser resulted in the collection of some funds for BCH infrastructure. Some of those coins were Bitcoin ABC specific. Additionally, Bitcoin ABC received all the funds that were collected in the general donation address as it was decided that those funds would have most impact with that team. With that it was possible to fund a developer that was previously was funded by others. Additionally the Bitcoin ABC team was able to additionally fund two experienced developers with history in Bitcoin Cash protocol development and with that making sure they were not lost to the Bitcoin Cash ecosystem. 

Unfortunately the funds collected during that fundraiser are very limited and at current BCH price will run out in less than 6 months. Despite ongoing efforts to find additional resources, no additional long term funding is committed to by Bitcoin.com or others and therefore the BitcoinABC team needs to assume these additional human resources are only temporary. This means that the ability to take on long term additional workload is unrealistic. Ignoring those realities would render Bitcoin ABC entirely powerless the day those funds run out and those people are forced to look for alternative income. Not only would they lose the additional developer hours provided by the two new team members, they would that day also lose one of the most productive developers that has been a driving force within the ABC software project for well over a year. 

Why Was It Not Explained to Roger Ver and his team?

Now some may say: “Why was this not explained in detail to Roger and us?” To them I would like to say that I know there have been private meetings with Roger and many others about this. Additionally I would expect people to do what is needed to gain an understanding of the reasoning behind a position with as much energy as they ask others to put into explaining things. In fact, knowing the fact that the Bitcoin ABC team has always been underfunded, understaffed and over extended I would say that a large well resourced company like Bitcoin.com should be required to do the research and ask the questions rather than requiring the underfunded team to provide them detailed blog posts and in depth written down explanations. 

I would expect from such a company an assumption of good faith towards the leading software team. In other words, the assumption that this teams primary objective is to do what is in the long term best interest of the Bitcoin Cash project. A project that could be created thanks to that software client being created in early 2017 and it being ready in time for what would subsequently happen on August 1st of that year. However, what I see clear signs of is a deep seeded mistrust that likely is a result of past experience with Blockstream driven Core team as also a result from the hate campaign headed up by CSW last year. The blunt and brutal communication style of Bitcoin ABC’s founder and lead developer is obviously not reducing this bias against leading implementation of Bitcoin Cash but that is no excuse for not taking what has been said many many times now at face value, analyse the situation Bitcoin ABC is in by looking at the facts or asking the questions in one of those private meetings that were and are taking place. 

Is Bitcoin ABC Dragging its Feet

My answer to Roger Ver is: No Roger, Bitcoin ABC is not dragging its feet. It is telling you that their lack of resources is serious and absence of sustainable funding makes that doing what you want them to do, in effect suicidal as it would long term render the team incapable of reaching the goals and so would take away its reason for existing. Giving in to the pressure you and others are putting on them to do what Satoshi Dice and you have been asking for, would in fact jeopardize not only the Bitcoin ABC project but as I and others believe they are very important for the future success of the project I would say that it would even jeopardize the Bitcoin Cash project.

Putting Extra Pressure On ABC

After some have told me this video was a tactic to put additional pressure on Bitcoin ABC, I would like to add the following: Putting pressure on a small team of people that is underfunded and over-extended may not be a very smart thing to do unless you want that team to disappear. 

Most if not all members of the team are professionals that would have no problem quickly finding a better paying job, with less chaos, drama and risk. They have been working long hours, working at impossible hours as they believe in the goals of the Bitcoin Cash project. They dropped everything to fix urgent problems at a reduced income as they want to see this project succeed and see the world population regain economic freedom and financial sovereignty. The day they are forced into a situation where they know their work and their sacrifice will no longer be able to reach those goals, the most rational and logical step would be to pack up and leave. 

Bitcoin, A Peer-To-Peer Digital Cash System

The first and primary reason why Bitcoin Cash was created was for this use case. Peer-to-peer money for the world. It was because of prohibitively high fees and people being pushed into off chain solution may it be custodial, federated or unfinished second layer solution with very questionable economics and security. The fact that Bitcoin with high fees and throttled network would no longer be able to bank the unbanked, bring economic freedom and financial sovereignty to the entire world was on the base of the split that gave us Bitcoin Cash as BTC had changed its direction into a future that did no longer have those goals. Although I believe many of the use cases people are working on are important and interesting I would urge all to not lose sight of the reason Bitcoin Cash split away from BTC. We need to keep prioritizing the work that leads to reaching those goals. I urge all to support those that keep speaking truth and who stick to reaching those goals even when pressure is put on them to do what would make it impossible to reach those goals. 

Stop Complaining, Start Supporting

Those that say they want certain changes, those that complain that changes are not added fast enough and businesses and projects that stand to benefit from such changes would do well to draw their wallet and ensure that it can actually be done. If we do not collectively strengthen the open source team and fund its developers, we are destined to find ourselves in a situation where such a team is forced to give up or build a business that generates income and attract venture capital. That model has been tried before when core developers found themselves faced with similar issues, being unable to  attract long term funding. We all know this model has failed miserably and when it comes to ensuring that the goals of the project are not replaced with something that first and foremost benefits that venture capital funded business and its investors. With this in mind I call on everybody to help find sustainable “no strings attached” funding and resources to strengthen the software team that has been at the birth of this project and that has been working towards its security and future 24/7 for the past two and a half years.