Reclaiming Disk Space on Bitcoin Cash: Pruning, Fast Sync, & UTXO Commitments
Earlier this year Bitcoin Verde committed to implementing "pruning mode" and "utxo commitments" as a part of our 2021 Flipstarter. But why? What do these things even mean?
*Disclaimer: This post is targeted to the mild/moderately knowledgable Bitcoin user. It contains simplifications of concepts that are not 100% accurate but are "close enough" such that knowledge of the intricacies of Bitcoin are not required. The complete implementation proposal will be outlined in a CHIP.*
What is Pruning Mode?
Satoshi's white paper describes pruning mode in Section 7, "Reclaiming Disk Space", but what does that mean to the everyday user? Basically, "pruning mode" allows users who run nodes to do so with less disk space.
To understand how this works it is necessary to understand how data in the blockchain is used.
Blocks describe an update to the blockchain's state, and once a block is processed, only a small portion of its data needs to be kept. This "state" is often described as the "UTXO Set", which is essentially all of the spendable coins on the network; once a coin is spent it is removed from the UTXO set and often another one takes its place.
For perspective, keeping only the current state of the blockchain reduces 150+ GB of blockchain data to somewhere around 25 GB.
However, the typical implementation of "pruning mode" requires the node download the entire blockchain so that it can apply each blocks' changes to the blockchain's state. So while the disk usage may be reduced to 25 GB after it's done syncing, the node's network still downloaded the full 150 GB. More importantly, applying and validating each block to the blockchain's state is a long process. Even the most optimized implementation, BCHN, can take ~8 hours to sync the blockchain via the traditional method, and other implementations, like Bitcoin Verde, taking even longer (~20 hours).
As the blockchain grows older and its size increases, the time it takes to sync a node via the traditional methods may become increasingly time-consuming, and far enough in the future may even become a barrier to syncing new nodes.
But is there a way to avoid downloading the full blockchain since its "extra" data is immediately thrown away?
UTXO Commitments / Fast-Sync
As mentioned earlier, the "UTXO Set" is the current "state" of the blockchain. As an example, picture an accounting log recording your purchases:
*Received* $4 from DayJob.
*Received* $1 from SideGig.
**Sent** $5 to GroceryStore.
*Received* $3 from NightJob.
*Received* $4 from DayJob.
**Sent** $3 to ElectricCompany.
**Sent** $4 to MeowMeowCatSupplies.
In this example, the blockchain is the full list of transactions. It's pretty long. Meanwhile, the UTXO Set only consists of coins still available for spending, and looks like:
GroceryStore has $4.
ElectricCompany has $3.
MeowMeowCatSupplies has $4.
This is obviously a lot less data to store and sync, and is therefore much faster to process. However, the downside is a lack of accountability for where "GroceryStore" received its $4**—**how does a user know the balance was not made up or tampered with? Sending and syncing only the UTXO Set data is often referred to as "fast sync", but it relies on trust.
This is where UTXO Commitments come into play. **Without** UTXO Commitments (that is to say, just using "fast sync"), the user running the node must trust that the UTXO state wasn't tampered with. But Bitcoin isn't about trust. In Bitcoin, in order to trust something we must first verify it. Once UTXO Commitments are implemented by miners, that verification can take place, but for now, users can only trust their node implementation (or use the traditional syncing method).
In what ways are the users trusting the node implementation if they only use fast sync?
While the UTXO Set contains all of the blockchain's state (~4GB), a UTXO **Commitment** is only a 32 byte hash of that data and is put into the coinbase of a block. This hash gives users the ability to verify that all of the data included in their UTXO Set matches up with the rest of the network. Without the miner's "committing" to this hash, the validation hashes must be hard coded into the node software. While this current state is obviously not ideal, the improved user experience for syncing a node might be worth the short-term reliance on trust**—**after all, the node implementation developers would compromise their reputation if they intentionally published an invalid UTXO commitment hash. Additionally, an invalid UTXO Set would eventually cause the node to fail (or "get stuck"), so the incentive to intentionally corrupt the UTXO commitment is quite low.
So why not add UTXO Commitments to the coinbase today? Well, BCH could do that, but it's not something Verde is recommending**—**at least not right now. In order for the UTXO Commitments to be valuable, they must also be enforced to be correct by the entire network. This enforcement is what is often called a "consensus rule". So if the UTXO Commitment is incorrect then the whole block is invalid. In order to justify the cost and complexity of this change, it is prudent to first ensure the demand (and realized benefit) for such a change exists. Therefore, creating a method to "fast sync" while minimizing (but not eliminating) trust should be the first step. Only after adoption of the improved fast-sync feature occurs and both users (and developers) gain confidence in generating and validating compatible UTXO Sets, should Bitcoin Cash consider making the commitment a consensus rule.
Ultimately, pruning mode and fast sync (with UTXO Commitments) is an important part of the long-term scaling model of Bitcoin Cash. It may not completely replace the traditional method of syncing (as there are benefits for "archival nodes", such as SLP support (unless OP_GROUP becomes the main token system)), but these methods significantly reduce the barrier of entry to users and businesses needing/wanting to run a BCH node.
History of Fast Sync and Future Plans
BCHD became the first implementation to provide fast sync. Currently, BCHD supports fast sync via hardcoding the commitment hash within their codebase and downloading the UTXO set from IPFS (IPFS is not a part of the Bitcoin network). BCHD does not create UTXO commitments automatically, but they do provide a tool to generate one and is updated and published with each new release. The BCHD implementation is based off a proposal from Tomas van der Wansem in 2018. His proposal was never accepted into Bitcoin ABC's codebase despite publishing a PR. https://github.com/tomasvdw/bips/blob/master/ecmh-utxo-commitment-0.mediawiki#specification
Bitcoin Verde recently completed a beta version of fast syncing, and like BCHD, the commitment hashes are hard coded into the node. However, unlike BCHD, Bitcoin Verde introduces extensions to the existing P2P protocol for downloading and distributing commitments. The goal is to have other implementations generating and distributing UTXO commitments dynamically as well enabling P2P distribution; this progress will allow developers to gain confidence that the nodes are in consensus before enforcing new consensus rules. Even if commitments are not generated by the miners, this first phase would still be a successful user-experience improvement.
Non-coordinated implementation of this proposal does not affect block-, or network-, consensus, nor does it affect 0-conf security. Furthermore, it is impossible to introduce any accidental or intentional forking of risk to the network at this phase since UTXO Commitment Hashes are not appended to the coinbase.
This proposal will be published to https://bitcoincashresearch.org/ for feedback within the next couple of weeks. Stay tuned!
Implementation Diversity is Vital to the BCH Network
It’s no secret that the Bitcoin Verde team is a big proponent of diversity among node implementations. We’ve been persistent with our calls for node diversity for as long as we’ve existed. Generally, we like to think the greater community shares these views with us, but on occasion we do still hear questions relating to “why multiple node implementations are a good thing”.
So, why are multiple implementations important for the network?
**Distribution of Social Influence**
When I think of a healthy decentralized network one of the first things that comes to mind is a balance of power and control. Deploying multiple types of node implementations is an easy way to strike that balance.
It’s a slippery slope to become overly reliant on single entities, and it's an effective way for a public project to be taken over or misdirected (either maliciously or accidentally), as we’ve seen in the past with Bitcoin Core. When using someone else's software, users are generally reliant on what updates the developers provide. If the community becomes too reliant on a single entity to support their network, the reach of social influence and control is ultimately going to be tipped out of balance.
Unfortunately, as history has shown, people tend to act in their own self interest when left to their own governance. The problem really arises when the providers and the users eventually come to a hard disagreement, and in terms of BCH’s history, a network split is almost always the result. An easy way to remove this risk is to simply not become overly reliant on any single entity; this raises the cost for node’s to disagree and applies pressure for them to find a compromise, especially if the mining hash power and user support distribution is uncertain.
While this is certainly true for node operators, it is even more important among mining implementations. As we have seen with Bitcoin ABC’s departure last year, a healthy network also requires multiple mining implementations. The utilization of which could help prevent any one node implementation from having a disproportionate amount of influence over any other.
Ideally mining pools would utilize an array of software and whichever performed best at the time would be the current selection, but the reality is mining BCH is a resource intensive job that produces a small margin of profit for most operators. If there are small discrepancies between implementations resulting in work being performed on invalid blocks, the miner is at risk of losing revenue. Due to these circumstances, there is a very large disincentive for operators to use anything other than the current standard.
This is all not to say the status-quo majority implementation is not a fantastic choice for miners. The BCHN client is stable and performs well. Furthermore, their team has intelligent and talented people on it that put a priority on inter-node collaboration. However, in the name of decentralization, the network should strive to break free from its reliance on any single client.
Our team has tried to incentivize this behavior ourselves with the creation of a block template validation service, the BitBalancer. This service is used to prevent miners from mining an incompatible block before they spend the electricity to create its hash; instead, the BitBalancer offers a universally compatible block template. This functionality avoids what would otherwise be an orphaned block, or worse: an accidental fork in the BCH blockchain. In the future we hope this tool will help miners feel more confident using multiple node implementations to mine BCH, and when they do, there will be no single group to easily attack.
**Resiliency to Exploits and Bugs**
In a similar fashion, utilization of multiple implementations helps sustain our network’s resiliency to undiscovered bugs and exploits.
Although there have not been any major discoveries in the past several months, undiscovered bugs and exploits are always a major concern, potentially one of the network’s largest threats. Today, with an ever-increasing supply of new technologies (and cryptocurrencies), there is little forgiveness among the average consumer for failure, certainly not when it comes to finances.
Over-reliance on single implementations has the potential to amplify the effect of undiscovered bugs, some of which could result rolling back large portions of the blockchain. (Yes, we’ve seen this happen even in Bitcoin’s history.)
While it did not result in a rollback, a lesser example of this problem was presented in 2018 with the Bitcoin ABC’s “SIGHASH_BUG”. The result of a code refactoring, the sighash bug would have allowed a user to submit a malicious transaction that, when validated, would have resulted in a large portion Bitcoin ABC (upgraded vs non-upgraded) nodes splitting from one another due to incompatibility issues. This issue is oddly reminiscent of the 2013 Bitcoin BerkeleyDB/LevelDB upgrade.
Although the full ramifications of this bug’s effect can still be debated, the reality is the size of the split and severity of impact would have been in direct relation to the percentage of the network using that version of ABC. Fortunately the potential impact of this bug paled in comparison to Bitcoin Core’s (unexploited) infinite inflation bug, but this example is proof that even we (BCH) are not immune to protocol bugs. Thankfully, due to the inherent mechanisms of BCH (i.e. Nakamoto consensus) a split would not necessarily mean the death of the network and could ultimately be settled without a rollback. In the hyper-competitive market of cryptocurrencies today, the reputational damage of something catastrophic such as a chain-rollback such as what was done in the early Bitcoin Core days, would be quite disruptive for the Bitcoin Cash network both financially and reputationally.
As a network, we should strive to make the chances of this occurrence an absolute minimum and it is just another reason why software diversity is so important. Typically, a bug in one implementation is unlikely to appear in others. Certainly even less so as implementations diverge in programming languages. With less chance of a critical bug affecting a majority of the network, a diverse network can be more robust and resilient to critical bugs.
**Attraction of New Developers**
While decentralization and network resiliency are exceedingly important ways diversity helps sustain our network, I think it is equally important to highlight how it helps our community grow.
Our community is always looking for continued growth and adoption. The more BCH is adopted for its utility, the more value it provides to its supporters. Who doesn’t want their asset to increase in value? While security and functionality are certainly important for the functional health of the network, and ultimately its value offering to users, I think it is equally important to highlight the benefits diversity provides to attracting new developers.
When our team first began development on Bitcoin Verde, Bitcoin Cash’s split from Bitcoin Core was fresh and the network consisted of only 3 primary node implementations. Of the three, each one was a forked version of the core client. At that time, if a developer was interested in contributing to BCH it would have been a requirement to familiarize themselves with a vastly complex codebase in C/C++. Although this is not to say C++ isn’t a great language choice, its pool of available developers is substantially less than other languages, and its learning curve and required mastery shouldn’t be a prerequisite to contributing to peer-to-peer electronic cash.
By limiting the amount of languages available to interested developers, we are limiting opportunities for network growth and adoption.
In the last decade the number of people interested in programming has undoubtedly grown substantially. As technology is integrated further into our lives each day, individuals looking to create new technologies continue to multiply in its support. Cryptocurrencies are not the skeptical side projects many had once considered them and the opportunity to capture new talent is available. As a new market and ever growing network, the Bitcoin Cash community should strive to capture the interest of as many developers as possible.
In the last few years, our network has done an exceptional job of welcoming new teams, individuals, services, and businesses, and in order to continue to support the growth we all hope to achieve, it will be important to continue to embrace these additions.
**Conclusion**
So, why do I think multiple BCH implementations are important? Because to me a healthy decentralized network is secure, resilient, and always growing, and without a diverse offering becoming a world-wide cryptocurrencies will just be a temporary dream. We should not allow an opportunity for Bitcoin Cash to fail us like Bitcoin Core has.
275 Days
Let's recap.
On February 15th, 2020, the majority node implementation, Bitcoin ABC, announced without discussion that they would be implementing an off-roadmap contentious change to the BCH protocol. Bitcoin ABC did not consult with other node implementations before announcing this change, nor was the community polled. This announcement was made 275 days ago. https://www.bitcoinabc.org/2020-02-15-miner-fund/
Despite a decision "already being made", debate ensued--philosophical, technological, and political. In the end, an opposition manifested, and when the IFPv1 was defeated in May 2020, there was a sigh of relief: no matter which side of the equation you fell on, the conflict was over. The conversation would surely continue after a reprieve, but we'd have time to heal and come to social consensus before codifying any changes into the blockchain.
However, 160 days later, a completely separate conflict arose, originating once again from Bitcoin ABC. A change that was thought to be unanimous within the ecosystem and a victory in the name of collaboration, the ASERT DAA, was suddenly discarded for a privately developed algorithm. This different implementation objectively provided zero benefit and was put upon the ecosystem without conversation or peer-review. Once more, the community rallied; an opposition formed and Grasberg was defeated and ASERT prevailed. https://blog.bitcoinabc.org/2020/07/23/announcing-the-grasberg-daa/
15 days later, the most recent conflict was forced upon the community: IFPv2. The community once again, was placed back into the fire before any healing took place. https://medium.com/bitcoin-abc/bitcoin-abcs-plan-for-the-november-2020-upgrade-65fb84c4348f
Each of these conflicts spurred from unilateral decisions being made by one organization against many. Each of the rallying oppositions were done collaboratively between multiple other implementations, business operators, and investors. The work done behind the scenes for each of these battles was tremendous and I am humbled to have been able to play a small part. The tenacity of my peers inspires me, and I am grateful to work beside them.
I must emphasize: each battle was not won passively. It was an active and coordinated effort. While none of us risked nothing, many of us risked everything. It was exhausting, but also awe-inspiring. I have seen great teamwork and competence within the BCH ecosystem, and I am confident we can overcome any unknown challenges ahead.
Looking forward.
For 275 days, we have been in conflict, and for some, this has been an even longer endeavor.
I'm no stranger to conflict. I came from a broken home and was a scrapper as a kid. I fought in the Iraq war as a young adult. I transitioned from soldier to civilian during the great recession of 2008. I started my own business in 2011 and had to make difficult choices to keep it alive while going to college. I had my first child during the first days of the Covid-19 lockdown. Life is challenge, life is conflict, life is pain.
However, why have the last 275 days been so exhausting, and frankly, so frustrating? From my perspective, all of the BCH in-fighting from the last year has been so completely unproductive--and furthermore, so completely unnecessary. The issues have been back-to-back, without reprieve. We as people need to reflect, learn, and heal from the trials we face, and we haven't been given the opportunity to do that--at least not within the past 275 days.
With this battle over, and with it some new distribution of power, I hope we can take a reprieve as a community. Let's lick our wounds, and forgive our trespasses. More importantly, let's learn from our mistakes and from our victories. Remember it's not evil to have a different point of view and a different opinion. It's okay to disagree--respectfully. Remember the actions of those who have been acting dishonestly and without respect. Take a breath, recover from this moment, and ready yourself for the future.
We've triumphed today and it's important to celebrate that. However, don't gloat, don't hate, and don't alienate. Let's regroup and let's heal together. We have more important and more fruitful battles to win. Let's face those challenges stronger, wiser, and united.
Bitcoin Verde is Launching a Project to Increase Mining Diversity
The majority implementation crown is exceptionally heavy. I don't want it.
I do want network diversity.
I do want redundancy.
I do want a backup plan.
Preface
The lessons learned from Bitcoin Core and Blockstream will be forever remembered by the Bitcoin Cash community, and this community is proud to have multiple implementations.
Despite having 5+ node implementations, why was the entire network staggered last year due to a bug that existed in only a single implementation?
The answer isn't that node was of poor quality or that our network is only running one node implementation; in fact, neither of these things are true. **The answer is that miners are only running one node implementation.**
Bitcoin ABC is the only mining implementation
Bitcoin mining is a high-competition, low margin, risk-intolerant business.
During the infrastructure funding debate, we took extra care to understand the perspective of the miners.
When we asked why miners considered Bitcoin ABC the de facto mining implementation, we were told three reasons:
ABC's reputation for great quality
Limited alternatives willing to support mining/pool features
Homogeneous network decreases block orphan risk
Distilling this, **miners are running Bitcoin ABC because of its reputation, running a single implementation is less risky for them, and there aren't alternatives that they trust**.
Reputation
Objectively, Bitcoin ABC's reputation is fantastic. Not only is ABC producing stable, high-quality code, they are also innovating new features and providing a path for other implementations to follow. **This is not an easy task, and they've been doing a great job**.
Bitcoin ABC does great quality work. I agree with this.
Limited alternatives
I cannot speak for why Bitcoin Unlimited was not considered a practical alternative to Bitcoin ABC. However, **all 5+ implementations should strive to be viable mining alternatives**. Being viable means producing quality work; it also means reasonably obliging miners and taking their requests and concerns seriously. I encourage the minor implementations to start focusing more on this.
In line with that, I announced that Bitcoin Verde will be taking a heavy focus on becoming a viable mining node alternative. https://read.cash/@joshmgreen/bitcoin-verdes-response-to-the-miner-sponsored-development-fund-34028b1e#bitcoin-verde039s-future
Additionally, BCHD, Bitcoin Unlimited, Bitcoin Verde, and Flowee the Hub have been collaborating in the Bitcoin Verde Telegram about a minority node testnet for mining. https://t.me/bitcoinverde
Improvement on this is on its way.
A single implementation is less risky
For a miner that is constantly battling limited margins, an orphaned block is very expensive. It's why creating 32MB blocks isn't a trivial debate, and why people saw benefit in CTOR/XThinner: there is risk with propagating blocks, and poor block propagation is an important concern.
Orphaned blocks can happen organically. They can also happen out of malice intent, or because of a disagreement in validation rules--even if that disagreement is unintentional. It is this latter cause that miners see a benefit of a homogenized node ecosystem for mining. It's sound logic. It's near-impossible to have a disagreement in validation rules if almost all of the miners are running exactly the same software.
However, **it is not the homogenized ecosystem itself that miners want**. What they actually want is increased profitability by minimizing the risk of their block being orphaned.
Reducing risk for miners
In the past, some adventurous mining pools have attempted to mine with minor implementations, however they were burned by invalid blocks that were then orphaned.
**This risk is completely avoidable without resorting to a homogenized mining ecosystem.**
To remove this counter-incentive to node diversity, we will be creating a block template validation service. This open-sourced service will alert miners when the template they are attempting to mine is incompatible with other implementations, and can be ran themselves or by a 3rd party.
The block template validation system removes the risk associated with miners running different implementations. Furthermore, with this alert system, miners will be able to prune the transactions that create network incompatibilities or choose to completely switch to a different template.
This service doesn't just benefit minority implementations, it also benefits miners, developers, and the live network as a whole. By checking the validation of the template across the entire network's set of nodes:
miners can avoid accidentally splitting the network
miners greatly reduce risk of producing incompatible blocks, reducing orphans
developers can be made aware of incompatibilities between the implementations, which would be otherwise masked by the invalid block not propagating
giving the miners greater freedom of choice in their node implementation
**In line with how** **we said** **we'll fund development, we've created a** **GitHub issue** **to fund the prioritization of this feature.** This issue outlines exactly what we're building, why we're building it, for whom it is for, and how long we think it will take. https://read.cash/@joshmgreen/bitcoin-verdes-response-to-the-miner-sponsored-development-fund-34028b1e#funding-bitcoin-verde https://github.com/SoftwareVerde/bitcoin-verde/issues/8
We are offering transparency and accountability in hopes to break down some of the donation barriers that Bitcoin.com has rightfully called out. We hope this transparency helps inspire other would-be donators, so that features can be supported individually--appealing to the free market to represent demand, and avoid relying on an unaccountable slush fund. https://www.reddit.com/r/btc/comments/eugk90/i_dont_agree_with_the_statement_in_the_ama_that/
We believe this service will become standard practice across all majority mining organizations, and strongly encourage recommendation from miners and the community for how to improve this idea.
Miner Sponsored Development Fund: What We've Learned
*This is a sub-article of a larger article that goes in depth of what we've learned from the past week's of conversations and debates around BTC.TOP CEO's Jiang Zhuoer proposed solution to the long existing development funding debate. The parent article may be found* *here**.* https://read.cash/@joshmgreen/bitcoin-verdes-response-to-the-miner-sponsored-development-fund-34028b1e
After Jiang Zhuoer proposed a solution to the long existing development funding debate, there has been some very intelligent discussion on both sides. 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. https://medium.com/@jiangzhuoer/infrastructure-funding-plan-for-bitcoin-cash-131fdcd2412e https://read.cash/@Mengerian/my-view-on-the-miner-infrastructure-funding-plan-efa0ee95 https://old.reddit.com/r/btc/comments/esqjqf/development_needs_a_financial_incentive_satoshi/ffdzpv7/ https://read.cash/@shadow-kwh/bch-dev-fund-a-response-from-an-opposing-mining-group-4397e64b https://read.cash/@deadalnix/on-the-infrastructure-funding-plan-for-bitcoin-cash-bd372a10 https://read.cash/@im_uname/assessment-and-proposal-re-the-bitcoin-cash-infrastructure-funding-situation-3e5179fc https://www.reddit.com/r/btc/comments/esoi5s/ama_jiang_zhuoer_author_of_infrastructure_funding/ https://read.cash/@jonald_fyookball/little-known-but-important-facts-about-the-mining-plan-a1f1fe13 https://www.reddit.com/r/btc/comments/esxfs7/vin_armani_on_the_infrastructure_plan/ https://read.cash/@PeterRizun/the-best-of-intentions-the-dev-tax-is-intended-to-benefit-investors-but-will-corrupt-us-instead-012f5dbd
We wanted to compile our understanding and conclusions.
The idea as a whole
The intent is amicable. I don't believe any organization, including BTC.TOP and Bitcoin.com, had a malicious or manipulative intents when they proposed their idea. I think any claim to the contrary would require extraordinary evidence, and I think their goals are well defined and well-aligned with their business models, and I think the community agrees for the most part that this is their take at a solution to what is undoubtably a very complicated problem.
Furthermore, Jiang Zhuoer made it very clear that the original post is an open proposal and that the details are still up for discussion. I have been in planning meetings that become so long and stale that you want to just admit the situation is complicated and we will never know for certain what the best choice is--so let's just pick something and find out. https://www.reddit.com/r/btc/comments/esoi5s/ama_jiang_zhuoer_author_of_infrastructure_funding/
This situation is a reflection of a complicated world, and a global currency also means a global culture, and if that's not a complicated situation then I don't know what is.
Despite some conflicts of interest with well-meaning intentions, we are reasonably sure that the proposal isn't an elaborate hostile takeover. At its root, it is proposing something that we all agree on: we want to find a way to fund and facilitate development. Proposing a solution with that goal in mind is not heresy and ideas are not bad; let's not condemn people for trying to be helpful.
In line with that, Amaury's expansion on the idea is also not a malicious idea. He wants what is best for his group and he's not wrong: the people he's listed have a proven track record for the support of BCH; they're invested and I don't think they'd make bad choices rooted with malice. While this does not mean I support his idea, it also doesn't mean I don't support these people. In fact, many of these people have become my friends. https://read.cash/@deadalnix/on-the-infrastructure-funding-plan-for-bitcoin-cash-bd372a10#who-control-the-funds
I have roughly 9 years of experience running a software business, and I am well aware that talented people do not work for free for very long (it's not even a matter of whether or not they want to--they literally reasonably cannot; our world simply does not work that way). So I empathize with Amaury's plight, and I want his problem solved. But not like this.
Bitcoin Verde's understanding of the hot topics
There are a few highly contentious topics within Jiang's proposal.
Relying on a centralized distributor of the funds.
Despite its contrast to the rest of Bitcoin's ethos, there are some **genuine benefits** to this methodology, and if Jiang is trying to keep things simple, then this is certainly a reasonable proposal despite its flaws.
*a.* For one, it **inspires a checks/balance mechanism** on development (if not controlled by the developers themselves). As Roger Ver pointed out, developers can be more efficient when there's a budget constraining them to make tough choices--within reason, of course. Without stake holders communicating demands, we can easily end up with a situation that spawned BTC's Lightning--which was certainly an interesting computer science effort, but there is more to a project's success than just solving a cool technical problem. In software development, user experience is often king.
*b.* Additionally, a central fund allows for future projects to apply for funding and in theory **allows all projects the opportunity to make solid value proposals for funding**. If this is purely a Bitcoin ABC funding plan then perhaps this benefit wouldn't be realized, but an organization to lobby allows the community to put pressure on the direction of funds. This isn't necessarily a bad thing if they're receptive and it works. It's how democracy and protesting is supposed to work... but we also know that doesn't always work either.
*c.* Finally, and allegedly, **some organizations cannot receive anonymous donations**. Which organizations and for what reasons I have not been made aware, but I choose to give them the benefit of the doubt that this can be a real constraint. A central organization is certainly not anonymous, so perhaps this alleviates this problem.
However, there are also some **heavy drawbacks** for a central distributor.
*a.* A central organization has a very difficult path ahead of them: **no matter what they do they will be seen as acting unfairly**. For instance, do they donate 100% to ABC, do they split it evenly, do they partition it, and if so, how do they partition it? The answers to all of these questions are lose-lose from an optics perspective; no matter what decision they come to, it will be seen as a misrepresentation of funds. Even if the organization was working diligently and honestly, they simply cannot know with any real confidence or insight what the entire community wants nor could they accurately explain their conclusions because it's a very complicated decision and often comes down to a judgment call. Any central organization will always be viewed as malicious actors and viewed with contempt, fairly or not. This disdain will sew dissent and distrust, and our community is divided enough already.
*b.* A central organization has no incentive to remain objective. There will always be a conflict of interest. And the reality is any organization will have no oversight or tangible consequence for acting impartially. Ultimately, **there is an inherent conflict of interest**. An absolute power over development funds will corrupt absolutely. We keep lamenting the creation of Blockstream 2.0, and here we are on the precipice of electing a new one.
https://www.reddit.com/r/btc/comments/eugk90/i_dont_agree_with_the_statement_in_the_ama_that/
Funding developers directly through a funding initiative.
Leaving the sponsorship up to the individual miners/pools is democratic in nature and can be objectively more fair. With this methodology miners are able to represent their own interests proportionally instead of blindly relying on the judgement of central (and non-elected) organization.
However, directly funding developers has been done before, and lessons have been taken from those previous efforts. These lessons include the realization that funding developers for the sake of funding them does not inspire action within would-be donators--the demand is too abstract. More importantly, undirected donations does it command efficiency or accountability.
There are also logistical problems with direct funding, which includes the possibility of pools to game the system enabling them to indirectly fund themselves.
This requires the list be vetted. But by whom? And how large should the list be? And where do projects go to plead their case for funding? This schema, without major innovation, leaves us in a similar predicament as we are currently.
Who is really paying for the fund?
There is a difference between mining pools and miners. The current proposal may represent mining pools interests, but miners' must also vote with their hashing power by selecting which pool they mine for. In some ways, this is similar to a representative democracy. This initiative may be representative of the pool's desires, but may not be representative of the miners themselves.
That being said, Mark Lundeberg convinced me that the long term cost of the proposal to the miners is substantially lower than 12.5%. The reason for this is that as profitability decreases, hashing power is balanced away from BCH. With less competition, the Bitcoin Cash miners will be finding more blocks than before (proportionally), which increases their revenue (sans the 12.5%, of course). Ultimately, after some oscillation, profitability balances out to similar levels. At least theoretically. This component is what makes the plan rather clever, but is still theoretical.
Protocol change or Nakamoto Consensus?
Of the concerns listed, the most important to our team is the precedent set by this proposal.
Having nodes condone/facilitate this behavior sets a precedent that cannot be undone. When nodes coordinate with pools to shift power away from other miners, we risk setting a dangerous precedent of power.
However, if the power is only held by the miners/pools (and the node implementations are uninvolved) the miners may choose to embark on an expensive hash war by enforcing this rule themselves. That is their right.
This isolationism-like decision also allows for any pool to vote against the funding initiative at any time.
When this decision is applied via a protocol change, pools are effectively locked in for the entire duration. If attempting to leave, miners have plenty incentive to lie about their intentions with their competitors. Furthermore, there will be unsurmountable logistical problems regarding an unplanned network upgrade.
Bitcoin Verde's Response to the Miner Sponsored Development Fund
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. https://medium.com/@jiangzhuoer/infrastructure-funding-plan-for-bitcoin-cash-131fdcd2412e https://read.cash/@Mengerian/my-view-on-the-miner-infrastructure-funding-plan-efa0ee95 https://old.reddit.com/r/btc/comments/esqjqf/development_needs_a_financial_incentive_satoshi/ffdzpv7/ https://read.cash/@shadow-kwh/bch-dev-fund-a-response-from-an-opposing-mining-group-4397e64b https://read.cash/@deadalnix/on-the-infrastructure-funding-plan-for-bitcoin-cash-bd372a10 https://read.cash/@im_uname/assessment-and-proposal-re-the-bitcoin-cash-infrastructure-funding-situation-3e5179fc https://www.reddit.com/r/btc/comments/esoi5s/ama_jiang_zhuoer_author_of_infrastructure_funding/ https://read.cash/@jonald_fyookball/little-known-but-important-facts-about-the-mining-plan-a1f1fe13 https://www.reddit.com/r/btc/comments/esxfs7/vin_armani_on_the_infrastructure_plan/ https://read.cash/@PeterRizun/the-best-of-intentions-the-dev-tax-is-intended-to-benefit-investors-but-will-corrupt-us-instead-012f5dbd
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**. https://read.cash/@joshmgreen/miner-sponsored-development-fund-what-weve-learned-9e3f0e4c
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. https://bitcoinprotocol.cash
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.
@joshmgreen