Resolving the IFP Situation

Currently, the Bitcoin Cash community is in a bit of quandary due to the proposed IFP (Infrastructure Funding Plan).  The lead implementation (Bitcoin ABC) is in favor of the proposal and has integrated it into their latest software release.  Yet the community (at least the western community) is overwhelmingly opposed to the plan, and a group of a dozen heavyweight developers have already created a forked version of the ABC software without the IFP, called Bitcoin Cash Node (BCN).

The main point of this article is to try to resolve this conflict peacefully, or at the very least, offer up some ideas and food for brainstorming that others can build on.  

Although my personal views are maybe not that relevant, I’ll share them anyway:   I’ve come full circle on the IFP. First, I thought it was a good idea. Then, it seemed bad simply because it was very controversial.   Finally, I came to generally oppose it on principle, because I believe this is tinkering with the protocol in such a way that introduces unnecessary human conflict (politics), and makes Bitcoin Cash less like sound money.  That we already have a huge conflict and the IFP hasn’t even launched, is evidence in favor of this theory.

Of course, the other side of the argument is that Bitcoin Cash cannot afford to neglect infrastructure, and it is true that one critical bug could bring down the network.  In a recent developer meeting, Amaury Sechet mentioned that he thinks the community can find a solution “that makes everyone happy.” That is good. It shows a willingness to want to amicably resolve this situation.

And I do think it should be resolved sooner rather than later.  It’s a bad idea to leave Bip9 voting on a minority chain. Plus, the lingering uncertainty around this may have a negative effect on price.

Joining Forces

At first, I thought that this was an impossible situation.  We don’t want to mess with the protocol and pay out of the coinbase, but at the same time, other ideas to support infrastructure haven’t panned out.  On top of that, some people are (understandably) upset with Bitcoin ABC right now. There is also a new node team that is opposed to IFP and believes the bip9 activation with 66% to be unacceptable.  ABC has their own perspective and perhaps are waiting for alternatives to be presented.

And then it hit me!  Why not have Bitcoin ABC and Bitcoin Cash Node join forces?   

Wait a sec, what?  Join forces? How? And how does that solve anything?

What Does Each Side Want?

First, we have to understand what each side in the conflict wants.  The “No-IFP” side wants Bitcoin ABC to release a new version that would eliminate the IFP.  This would create a great sense of relief and dispel market uncertainty, and allow the community to refocus on building.

Bitcoin ABC, although not the sole supporter of IFP, has control over the lead implementation software, so let’s call this the “ABC side”.  They want money. Perhaps this is a combination of wanting to fund infrastructure as well as wanting to pay some bonuses. So far, so good.

Amaury has often rightfully complained that many responsibilities have fallen to ABC and that others haven’t pulled their weight.  But now, we have BCH node developers pledging their time. The “no one stepping up” problem just got solved, assuming those developers follow through. Overall it’s a group I respect and have a lot of confidence in both their ability and integrity.  

The Idea of a Dual Team Model

In an article I wrote last year about Bitcoin governance, I explained the difference between having a lead implementation direct the protocol (as Bitcoin ABC has done), and having multiple implementations jointly making decisions.  Bitcoin Cash began as an attempt to take a multiple implementation approach, and fell apart almost from the start. (Whether you blame BU or ABC for this doesn’t matter.)

Bitcoin Cash Node has a credible team, and are the kind of people I believe could collaborate well with ABC.  They are already taking actions to gain node and mining share, and I believe they will have some success. The controversial nature of the IFP is the catalyst.  

Thus, the “dual team” model isn’t so much a proposal, as a description of what is happening.  Of course, the two teams would have to agree on the same rules (no IFP), and then we can all move forward.  And then in the future, hopefully consensus will be reached between the two groups on any major decisions involving the protocol. 

The fact that the codebases are common is a big benefit that would allow these two groups to maximize collaborative efforts, as well as avoid consensus bugs.

It’s All About Getting the Roadmap Done

Everyone has their own unique gifts, skills, and abilities.  As people in our community have mentioned many times, Amaury’s talents are in the technical realm, and not in management or communication.  Thus, Amaury is much more suited to be a lead engineer than a project leader or maintainer.

The dual group model allows this without asking anyone to change anything.  Amaury doesn’t have to give up any control of Bitcoin ABC.

Although perhaps Amaury wishes to have “5 high paid devs he can boss around” as some have alluded to, and maybe it sounds “fun” to him, I am fairly sure it would actually be stressful and draining for Amaury in practice.  It would also be inefficient and with high turnover.  

Maybe it is best if ABC stays small in terms of personnel.  Amaury can continue the great work that he’s doing, and other developers can work freely on the Bitcoin Cash Node, and changes can be ported to ABC.  If Bitcoin Cash Node is doing infrastructure work, then the original goal of having millions of dollars worth of infrastructure development is met.

With the help of Bitcoin Cash Node, ABC can get the roadmap done faster.  That should be what this is all about. ABC benefits greatly from being able to backport from Core, so if BCH Node also has high quality code, then ABC can port from them too.

Building Culture

Interestingly, it has been Amaury as a thought leader who first called attention to some of the issues facing our community and the need for better culture. Amaury has struggled to do this within his own organization for the simple reason that he’s not a natural project leader.   

I can attest to the fact that there is a much voluntary development that you get for free when you build a positive culture.  Just look at the Electron Cash and SLP sub-communities. This is all about attracting developers. In my opinion, the Bitcoin Cash Node team now has the responsibility to build culture and attract talent on the protocol level.

Sweeten the Pot

Of course, ABC wouldn’t be completely happy with a deal where they get nothing and we just say “BCH Node will handle infrastructure needs.”  We should give ABC some money, too. It can be for bonuses or whatever. But, the point is, it can be much less than the millions previously discussed, since BCH Node will be picking up a lot of the slack.  

If this seems like a “shameless bribe”, so what?  It’s voluntary and that’s the whole point, right?

More Money

I think there can also be additional fundraisers for BCHD, ABC, BCH Node, etc.  If ABC is able to meet the community by cancelling the IFP (even under a special deal) , there will be enormous goodwill generated and this opens the possibility for more money to come in.  

In Summary

The BCH Node was born out of controversy, but now presents itself as part of the solution in providing skilled developers that can assist with infrastructure efforts.  ABC and BCH Node should work together, with each group doing what it does best, and in addition we should find a way to offer ABC some amount of immediate funding as part of the solution.

If others in the community resonate with this article, their next steps should be to try to create a proper place/time to discuss such matters between key stakeholders.