The recent funding proposal by Bitcoin Cash miners has brought a deluge of discussion. The proposal is not finalized, so naturally there are many unanswered questions.
Answers to some of those questions are beginning to form, but ultimately we need some criteria to help us determine if a proposal demands consideration in the first place before we decide on implementation details. Some may argue that said details are important in considering whether or not the plan is “good”, but determining all of the details will tend towards bikeshedding, and as Jiang Zhouer already pointed out, spending too much time debating is fruitless as no actual action takes place. What we need is a quick measuring stick to help us decide if a plan is worth delving into. If not, we can simply ignore it.
Not having such a measuring stick is setting ourselves up for failure, as the evaluation of a proposal only after the fact becomes another powderkeg of disagreement waiting to go off regardless if the plan gets executed aggressively, unitedly, or not at all. We need to explore the questions that make up that measuring stick both before the proposal kicks in and during its termination.
Before the proposal begins:
What is our velocity today?
Taking a look at the roadmap gives us a small hint. In the last two years, Bitcoin Cash has added CTOR, CashAddr, some new opcodes, and Schnorr signatures. However, one of the unfortunate things about this roadmap is that the goals get progressively more difficult and expensive to build. We’re running out of low-hanging fruit, so if it takes two years to tackle the simpler stuff, it is difficult to guess how long it may take for the rest. If we assume no changes to current funding, staffing, etc., I personally think it’s safe to say that we’re looking at 10+ years with “never” being a real possibility. All in all, our current velocity is not sufficient to make Bitcoin Cash the best money with a token economy at mankind scale. Even if 10+ years was an acceptable outcome in a vacuum, the probability of getting beaten out by a better funded, better staffed competitor in the real world is high.
Is ~$6M enough to build more of the roadmap?
The unequivocal answer here is no. If we blow all of the money on a few items on the roadmap, we’ll end up right where we are today: back to low velocity and begging for the funding necessary to maintain the new code, let alone enough money to develop the roadmap further. The funding proposal is just enough to change our trajectory. But this is incredibly important because demonstrating to the greater market that Bitcoin Cash has the velocity to get to the Moon, Mars, and beyond is necessary before enough hands come on board (and that includes engineering talent and user adoption, not just well-meaning investors).
Not only is demonstration important, but also building enough infrastructure that Bitcoin Cash can handle an influx of developers. This means more automated testing. A LOT MORE. If you rely on every developer to review and test everyone else’s code, you end up with a bureaucratic mess of code ownership, management, and other processes that are a massive drain on resources. Bitcoin ABC has been preparing for this inevitability.
Compared to around a year ago, Bitcoin ABC runs roughly 6 times more automated tests per change committed. And the number of changes per year has doubled, so that’s about 12 times more tests per week on average. Our confidence in making changes safely has never been higher. Now imagine if the number of daily contributors doubles. Running 24 times the number of tests as we did in late 2018 would be simply impossible if we tried to do this by hand. Now take this into account and reconsider the above points. If things have gotten so much better with so little funding, clearly development velocity has increased! Sadly, double the number of changes per year still pales in comparison to where we need to be. Double the speed when you’re slow is still relatively slow. We need to increase our engineering output by an order of magnitude (much of this via automation) if we want to have a chance at completing the roadmap in a reasonable timeframe. And these numbers only concern protocol development. Non-protocol work needs similar attention in this area, but that is a discussion for another time.
Does the proposal break our core principles?
With the current proposal, some people have stated that they’re questioning if this compromises the core principles that got them into bitcoin in the first place. In a similar to manner to Antony Zegers, I would argue that we are not.
Personally, I will continue working on and using Bitcoin Cash as long as it’s a free (as in freedom) currency that is fast, cheap and reliable, built on non-coercive and reciprocal principles. Every proposal (funding, protocol, or otherwise) needs to be inspected with this in mind and rapidly rejected if these principles are broken. I do not believe the current funding proposal is worthy of rapid rejection. Note that this assumes the proposal ends in the 6-month timeframe that it describes. Breaking it would be a breach of trust and would very likely have consequences of a reciprocal nature as we expect.
During the proposal’s end:
What is our velocity now?
While I don’t expect us to reach an order of magnitude increase in output with $6M, that increased velocity should certainly be measurable. If we look at other well-funded cryptocurrencies like Ethereum, they have earmarked funding of at least $27 million to work on protocol development for a one year period alone.
While it’s difficult to do an apples-to-apples comparison, it’s clear that Bitcoin Cash development is underfunded even with $6M put towards building the protocol. However, it does put us in a position to increase engineering output and attract further funding, talent, and user attention (through improved user experience as a result of better engineering). A serious attempt at measuring that increased output as a result of injecting $6M is important. It is also probably beneficial if third parties (non-protocol-development and non-miner groups) bring it upon themselves to evaluate these numbers. The community will then be able to compare numbers from different sources and produce a (hopefully) well-informed opinion on the matter.
Will the proposal actually end? Are we continuing after 6 months?
As Jonald Fyookball has already pointed out: Even if the funding proposal does work, setting a bad precedent makes the whole thing fall apart going into the future (note the core principles above). I also find it unlikely that all $6M will be spent within that 6-month period, as finding engineering talent takes time, as does training. But with a short runway of around one year for new engineers, it gives the community enough time to evaluate how much we get out of a few million dollars worth of protocol funding as well as time to plan the next stage of funding. I imagine every stage of protocol funding will be different as we learn more about what works and what doesn’t. Working towards a Linux Foundation-style funding model is likely best, but the Bitcoin Cash ecosystem is not yet mature enough to support it in a stable fashion.
Conclusion
We have a map to where we want to go and we know we aren’t going fast enough to get there in a reasonable time. Bitcoin Cash needs to step on the gas and get moving as long as we do not compromise our core principles, or else we will lose to competition, whether it meets our core principles or not. If you want the Bitcoin Cash core principles to win out, then finding a funding solution that has good answers to the above questions is paramount. I believe we’re getting very close.
You need to review your principles for consistency.
You are literally saying you are onboard with implementing an objectively coercive SF code change (orphaning a block if it doesn't meet some FISCAL criteria).
Do it, and there goes your "non-coercive principles". According to your words, and using commonly accepted interpretation, if Bitcoin Cash became coercive, you would no longer work on it.
You should take care about it, because I am not here to judge meta-principles. The code changes are the manifestation of the developer's principles I need to see.