Preface
BTC.TOP CEO's Jiang Zhuoer proposed last week a solution to the long existing development funding debate. Since then there has been some very intelligent discussion on both sides of the debate. My original response to the proposal invoked some very complicated emotions. With that realization, I took about a week to hear people's perspectives and spoke with the people I respect most in this community one-on-one. I took the weekend to reflect and then discussed with the Verde team.
After the discussion with the Verde team, I took some time to document our understanding of the debate as a whole. That article may be found here.
Bitcoin Verde's stance
Bitcoin Verde will not be implementing any node validation that enforces new coinbase rules. This forces any miner sponsor funding to be either optional or to be enforced at the pool level via Nakamoto Consensus. We feel the precedence set by cooperating with mining pools limits the power granted by miners to represent their best interests.
Regardless of which decision is enacted, Bitcoin Verde will still continue to follow the chain with the most chain work performed. This means that it is still possible to allow a miner (or even node) enforced development fund, but we will not be facilitating.
Ultimately, we believe this nuanced difference is the distinguishment between miner pool coordination and miner pool collusion. Coordination is healthy, collusion is not.
At the same time, we will not discourage miners from spending their money how they see fit. Custom coinbases with multiple outputs are permitted by the current consensus rules of the network, and therefore will continue to be valid. Additionally, orphaning blocks via hash power is a part of the rules of the game, regardless of whether like it or not, and we will not interfere.
This debate has further reinforced our opinion that lack of mining node diversity is a problem. We have great respect for the Bitcoin ABC and Bitcoin Unlimited teams, and I consider many of their members personal friends of mine. We are not a replacement, nor are we a competitor. We are a collaborator. And in order to collaborate, our opinions must have weight. In the Bitcoin world, weight is only defined by the hashing power behind our nodes. From a longevity of the protocol, we need multiple implementations to not only exist, but to also have influence over the blockchain. We believe Bitcoin ABC and BU have done an excellent job of leading Bitcoin Cash, and we do not intend on ever becoming a majority node. However, being completely un-mined means our actions have little influence, and therefore renders little choice for users and miners.
Bitcoin Verde's future
Bitcoin Verde will pivot its focus from a wallet-facilitating network-only node to a mining node. Will still maintain the indexing mode of Bitcoin Verde, but the desired mode will be configured upon the node's initial block download.
To facilitate the role prioritization from non-mining node to mining-node, we will be creating an experimental mining pool. This mining pool will be mined by ourselves at a loss, but others will be able to join if they wish. The pools purpose is not to create a fully featured pool that competes with existing software--in fact, this pool may end up being run via existing software. The purpose of our pool is merely to prove viability and reliable of Bitcoin Verde as a mining node.
In order to ensure the Bitcoin Verde template block would be valid (before hash power is applied to it) we will be creating a custom service to check the template block against a Bitcoin ABC/BU node.
Our goal is to make Bitcoin Verde a viable mining node within a year after the next upgrade.
Funding Bitcoin Verde
Regarding the funding debate, we will encourage funding solutions by leading by example. If our idea ends up working for us, then perhaps other projects can follow our example.
Bitcoin Verde will be asking for funding on a feature-by-feature basis. This means that if you're a miner and want an improved block template RPC call, you can ask for it and donate towards that specific objective. Likewise, if you're a block explorer organization and want an RPC call to get SLP details, you can ask for it and donate to that objective specifically.
Like any for-profit business we value money. Features will be ranked by the funding amount donated; each funded feature will be prioritized over our own personal roadmap. Higher funding amounts equals higher relative importance.
We plan to have two funding mechanisms. Funding anonymously/distributedly via github and funding via traditional contracts.
Each issue posted on github will have its own BCH address. A github issue may have a minimum budget/goal before execution begins. Each issue's title and funding address will be signed with Verde's primary funding address to prevent any misdirection of funds.
Contractual contributions can be created by reaching out to us via email or Telegram. A contractual contribution normally includes a statement of work. With that, we will issue an estimate and define a payment structure. This is the same process we've been executing for 9 years as a custom software organization.
For instance, the work we did with BU for the Bitcoin Protocol Specification was performed via a contractual contribution, including milestones and a pay structure.
Issues funded via github and issues funded via contractual contributions will be evaluated with the same priority relative to one another at the time the contract is executed. This means public github donations can compete fairly with contractual contributions. Public contributions are no less important than contractual obligations. However, once work begins on any obligation, the feature will not be re/de-prioritized until it is complete.
We believe this traditional approach to software development can be applied to open source software. This approach enables miners to keep their autonomy while also giving structure and actionable motivation to provide funding if desired. This approach also does not stagnate the free-of-cost contributions of open source software development. Funded contributions are executed only by Software Verde employees. Unaffiliated collaborators are still free to expand the project as they wish, just as they would with any open source software project.
We hope to experiment with this model in a way that does not enforce our will on any else but ourselves. If other projects find this methodology successful then that would be fantastic. If our methodology fails, then there is no harm done.
We look forward to continuing to collaborate with the Bitcoin Cash community in a joint mission to bring global, borderless, peer-to-peer digital cash to the entire world, non-discriminately.
...and you will also help the author collect more tips.
Fantastic article, this can serve as guidance for other Bitcoin Cash software projects and I hope it does.
I think this post has saved me effort to pen what I would consider a healthy business relationship of a BCH client software project with those whom it expects to fund it within the community.
👍👍👍👍