Lets just start by getting to the point. I am not a fan of the infrastructure funding plan (IFP) and think it is a mistake to include in the May upgrade. There are a number of reasons for this which I will detail below. Be prepared to read for a while, I plan on covering a lot of topics, you have been warned.

Near the end of the post I have written up a proposal that I believe can be implemented quickly and help the community fund critical projects ASAP. I also want to commend the many individuals who have spoken up against the current plan, especially those that have had good standing in the community since Bitcoin Cash was formed in 2017. Polite disagreement is critical to progress, be wary of those that demonize an honest discussion.

Developers, why we need them -

As a developer it is clear to me the value quality developers bring to BCH. As someone who has developed software for over 20 years, I have seen what it takes to build and support software.

• Design & Architecture

• Feature Development

• Maintenance

• CI /Testing

• Builds and release management

• Marketing / Branding

Now, the above is just the bare minimum to do business. Some projects can cut corners, but unfortunately for full node developers, they also come with additional requirements.

• Bitcoin protocol knowledge

• Cryptography

• P2P Networking

Now we take a peek at the Bitcoin Cash roadmap - https://www.bitcoincash.org/roadmap.html. We have ambitious goals, global P2P cash for the world. This is what we have signed up for, and there is no doubt we will need talented developers to get us there.

Since we need more experienced programmers, the opportunity costs for them are very high. We can't expect the best talent to work for free because they love BCH, they also need to survive. While its great to have lots of part time devs working on BCH, this isn't how we take it to the next level. We need people to focus on it full time, and hopefully multiple teams doing that.

Multiple full node teams competing in the BCH ecosystem is my dream. It was disappointing to me that less than 50% of the full node projects were on the whitelist in the latest version of Bitcoin ABC.

We need devs. We need lots of them, and we want them to compete with amazing full node projects that push innovation forward. That means we need to figure out ways for them to get compensated.

Funding open source -

Unfortunately when you give your product away for free, with source code, it can be more difficult to compensate the developers. The typical ways these projects try and make money, or get their devs paid:

• Support contracts (RedHat)

• Merch (Hats!)

• Commercial sponsored devs

• Donations

Now, support contracts for full nodes aren't going to net any team meaningful amounts of money. This could maybe pay for some infra costs.

Merch also won't be good enough... probably not even worth their time to setup.

Commercial sponsored devs I think is where we are now. There is almost no transparency as to where the funds are coming from, and we don't know what requests are being made to the full node developers.

Donations right now are low on most projects. However, I don't think it has been done correctly.

So lets talk ABC -

The facts are quite simple. Without ABC, Bitcoin Cash would not exist. There are people on the ABC team that definitely feel entitled, as they have put in a lot of work, and are quite frustrated that they can't fund the team correctly.

Donations are spotty, and in order to really plan and staff correctly you need a decent runway. They have worked with a few miners to try and solve their funding issues in what they consider a practical way, and given that almost all the hashrate is using ABC today, they must be doing something right.

However, the lack of financial support by those benefiting from ABC seems to signal they are not doing what the market wants.

Right now the market is favoring adoption efforts over infrastructure. The money in BCH isn't going to the full nodes, but to people building wallets, payment processors and other growth generation opportunities.

Fundamentally ABC is suffering because people are not interested in funding their roadmap blindly. The market is signaling they want specific features to be worked on, like the 25 chained transaction limit. The market wants feature flexibility. They want to find product-market fit.

So, in that position it is imperative that a software team actually explain what major features/refactors they are currently working on. Why those are important to the project, and an estimate on the resources required.

Right now people don't know what they are funding when they donate to ABC. If a project wants donations they need to communicate with their users! Large contributors will also have suggestions on ways to better utilize resources, but only if that information is actually available. They also don't necessarily want to pay for just backporting PR's from core.

It is also much more difficult to track ABC's work in real time because they insist on using Phabricator. Just that little bit of extra friction might insulate the project from some trolls, but it also insulates it from people that genuinely want to follow the changes going in.

One thing I know doesn't help with donations. Negativity. Publicly attacking people in the space, wars on twitter, or tribalism. We want to talk about what funding can enable, what we can do with it, and stay optimistic and forward looking with regards to development.

So why not just go along with the IFP?

I don't think we have explored all the options yet. I don't think changing who is issued coins is prudent at this time. This changes the incentives in the system, and more importantly signals that discussions about the block reward are open game. The optics of a team adding code to the consensus layer to pay themselves can never be undone. Imagine if BTC had attempted a 5% kickback to the core client.

For me, who the funds go to doesn't matter. It is the fact that a small group of people can decide who is on that list. I work on one of the projects on that whitelist and I would prefer the chain to stay pure than take kickbacks from the miners.

I also don't like how the implementation in ABC that already landed in a release version didn't match a single posted spec or discussion. There were apparently unilateral decisions being made. It feels rushed, just like all the upgrades since the 6 month HF cycle started. The DAA we chose is still having issues due to rushing it in to meet an arbitrary 6 month upgrade schedule.

I don't want this to end up the same way. Discussions on funding are happening, we should see what options we have, and not rush to make this fundamental change to the BCH protocol.

So what do we need?

So, my criteria for dev funding:

• Voluntary.

• Equal Opportunity

• Easy for profiteers on the network.

• Tracking/Stats.

• Accountability.

So, right off the bat, the IFP doesn't meet my criteria.

• It isn't voluntary. The protocol is being changed to force miners to do something they wouldn't usually do. This also happened after they put a significant investment into the network that could take years to repay.

• There is literally no accountability or tracking on what work gets done for the money. The IFP has no way to show what specific work is being funded, just the teams overall income.

• I consider BCH more than ANY full node implementation. I think that it should be just as easy to fund any node, having a whitelist gives those on that list an unfair advantage at the protocol layer.

Proposal time!

So, my proposal is simple. We need to build project funding into the mining pools themselves and gamify the process!

Basically, miners log into their pool, and in the sidebar they see a new section called "Projects". This can be infra, wallets, whatever you want, with a nice filter to easily find what you need. You can then select one or many projects and set how much you want to contribute from your earnings.

The pool then can track how much you have donated, and an aggregate of what the entire pool has donated! Each pool can have different projects listed, and a submission process for new projects to be added.

SLP tokens can also be issued to those who donated, which allow for perks on the pool or sister sites.

Mining pools can use this feature as a differentiator. Some will have better use for their tokens, or have a better interface to track projects. This gives them something to market for more miners to choose their pool.

While this solution seems simple, there are a number of reasons I think it will be much more effective than the status quo:

• It guarantees projects visibility in the same interface miners must go to track their rewards. They will see it every time they login.

• It allows miners to get better visibility into what projects are doing, and an incentive for mining pools to provide actual data on project development.

• It automatically gives payments over time. Makes it easier for projects to track money coming in and plan based on consistent payouts rather than large lump sums.

• Some pools can require donations if they want, the free market should control what pools decide. Some could refuse to donate, some will allow users to select donation amounts, some require a couple percent. Don't dictate, see what evolves.

• Funding can easily be integrated into solutions like flipstarter, requiring a threshold before a feature is funded. Again, the market decides if constant payouts or flipstarter style funding works better!

Conclusion

I recommend we start small and not be hasty with protocol changes. Simple solutions can work, we just need to try them and see what is effective.

The amount of work to build a donation interface into the pools is not high and could provide value back to the Bitcoin Cash community forever. Lets make donations work by making them so convenient and accessible that miners volunteer to help fund the next generation of BCH projects!

We don't need protocol changes for this. We need more accessible tools and information. These are solvable problems.