What is the Difference Between Bitcoin and Bitcoin Cash – Part 3: Coordinating Consensus
Explore the Full Series of
“What is the Difference Between Bitcoin and Bitcoin Cash?”
Part 3:
Coordinating Consensus
In the dynamic realm of blockchain technology, where innovation and evolution are constants, certain foundational topics play pivotal roles in shaping the trajectories of leading cryptocurrencies like Bitcoin and Bitcoin Cash.
In this exploration, we embark on a journey through the intricacies of consensus mechanisms, mining, the contrasting approaches to hard forks and soft forks, and the divergent processes used to improve each protocol. These fundamental elements form the bedrock of blockchain development, defining the security, stability, and adaptability of these groundbreaking networks.
In the sections that follow, we delve deeper into these pivotal themes, exploring the mechanisms, motivations, and implications that define the dynamic landscape of blockchain development. Join us as we unravel the intricacies of these groundbreaking technologies to further define the distinct differences between these pioneering cryptocurrencies.
Table of Contents:
Mining
Proof-of-Work
Proof-of-Work + Checkpoints
Forks Explained
BTC’s Soft Fork Dogma
Bitcoin Cash’s Embrace of Hard Forks
The Origins of Protocol Changes
The Core of the Protocol
Crafting Consensus on BTC
Distributed Evolution
A CHIP Off the Old Block
Strengths and Weaknesses
Consensus Mechanism
The consensus mechanism is a fundamental pillar upon which the entire edifice of blockchain technology rests. In this section, we delve into some details of how Bitcoin (BTC) and Bitcoin Cash (BCH) achieve consensus. Both coins share an almost identical consensus mechanism, relying on the robust SHA-256 mining algorithm. Miners in this ecosystem often engage in the practice of switch-mining, dynamically hopping between prominent SHA-256 coins to maximize their profitability.
However, as we explore this mechanism in depth, we discover that it’s the subtle nuances and a single significant difference that set the course for BTC and Bitcoin Cash’s separate journeys within the world of mining and consensus.
Mining
First, let’s get into mining and how it works. SHA-256 mining is the process by which new transactions are added to a blockchain, ensuring its security and maintaining the integrity of the digital ledger. Here are some basic facts on SHA-256 mining:
Hash Functions: SHA-256 stands for “Secure Hash Algorithm 256-bit.” It’s a cryptographic hash function used in blockchain technology. A hash function is a mathematical algorithm that takes an input (in this case, a block of transactions) and produces a fixed-length string of characters, which is a unique, seemingly-random output.
Proof of Work (PoW): SHA-256 mining is a key component of the Proof of Work consensus mechanism used by cryptocurrencies like BTC and Bitcoin Cash. Miners compete to solve a mathematical puzzle by finding a specific value (called a nonce) that, when combined with all the other data in a block of transactions and hashed using SHA-256, produces a hash that meets certain criteria (starts with a specific number of leading zeros).
Mining Process: Miners use specialized computers to perform numerous calculations (hashes) per second, attempting to find the correct nonce that satisfies the PoW requirements. This process is highly competitive, and miners compete to be the first to solve the puzzle and add a new block of transactions to the blockchain.
Mining Rewards: The miner who successfully solves the puzzle and adds a block to the blockchain is rewarded with newly created coins and transaction fees from the included transactions. This incentivizes miners to participate and secure the network.
Network Security: SHA-256 mining ensures the security of the blockchain by making it computationally expensive and time-consuming for anyone to alter the transaction history. The strength of the network lies in the cumulative computational power of all miners, making it extremely resistant to attacks.
Consensus: When the majority of miners agree on the validity of transactions and add them to the blockchain, a consensus is reached. This creates a shared ledger that is distributed across the network, and it’s this consensus that makes blockchain technology trustworthy and decentralized.
Now that we have some basic understanding of mining, let’s look at how exactly each coin decides upon consensus.
Proof-of-Work
BTC’s blockchain is defined purely as the chain with the most proof of work. That means that, whenever there is a choice between two or more alternative chains, BTC’s blockchain is determined to be the chain that would have been the most difficult to hash. For any miners working on extending the chain, if an alternative chain with more proof of work comes along – even if it would replace the last 10, 50, or any number of prior blocks – the protocol dictates that it must be the correct blockchain and all the blocks to be replaced must be discarded.
Such events are called chain reorganizations, or “reorgs”. Reorgs are actually fairly common, but they usually involve replacing only a single recent block. That can happen if two miners on the network both discover a valid block at the same time. They’re both “correct” when they are new, but when one of them gets extended by an additional block, that means there will be one chain with more work and it will replace the alternative for all nodes on the network.
Proof-of-Work + Checkpoints
Bitcoin Cash uses the same strategy as BTC for determining which blockchain is valid, with one key difference. Due to the relatively low mining hashrate on Bitcoin Cash compared with BTC, it is technically possible (no matter how unrealistic) for an overwhelming amount of hashpower to reorg the Bitcoin Cash blockchain and replace many blocks, which is called a “deep reorg”. To counter this possibility, the most popular mining node implementation, Bitcoin Cash Node, has rolling checkpoints. By default, Bitcoin Cash blocks that have 10 confirmations are considered final and therefore irreversible.
Even if those nodes are confronted with an alternative chain with much more proof of work, it will not replace blocks with at least 10 confirmations. This makes Bitcoin Cash’s resilience against deep reorg attacks virtually bullet proof. However, the rolling checkpoints introduce a very slight risk of a chain split. That means it could be technically possible for nodes to disagree on which chain is valid, leading to confusion. Many in the Bitcoin Cash community believe that rolling checkpoints should be eliminated when Bitcoin Cash’s hashrate once again becomes comparable to BTC’s.
Key Takeaway:
While both BTC and Bitcoin Cash share the same SHA-256 mining algorithm and Proof-of-Work consensus mechanism, their key difference lies in how they handle chain reorganizations. BTC always considers the chain with the most proof of work as the valid one, allowing for reorganizations involving multiple blocks. Bitcoin Cash works similarly but also implements rolling checkpoints, making blocks with at least 10 confirmations irreversible, which significantly enhances resilience against deep reorg attacks. However, this introduces a slight risk of chain splits, a factor that the Bitcoin Cash community believes could be addressed when its hashrate becomes comparable to BTC’s.
Battle of the Forks
The world of blockchain technology is no stranger to debates over the merits and necessity of the different types of forks during protocol upgrades. Broadly classified, forks come in two main types: hard forks and soft forks. But what exactly sets them apart? Let’s delve into the intricacies of these fork categories to gain a clearer understanding.
Forks Explained
In simple terms, a hard fork entails a relaxation of protocol rules, while a soft fork involves a further restriction of these rules.
But what does this mean in practice? Following a hard fork, nodes that have not undergone updates will diverge from consensus, as they view the updated nodes as violators of the consensus rules, leading to their refusal to cooperate further. Conversely, after a soft fork, nodes that remain unaltered will observe that updated nodes still adhere to the existing rules, although they might not be aware that these updated nodes are also subject to additional rules.
To put it another way, soft forks are considered backward-compatible, while hard forks are backward-incompatible. As a result, soft forks permit the ongoing participation of both older and updated nodes, whereas hard forks entail the exclusion of nodes that have not transitioned to the latest version.
BTC’s Soft Fork Dogma
The BTC network has established a long-standing tradition of employing soft forks as the primary mechanism for protocol upgrades. It’s been more than a decade since the last hard fork on the network occurred. At this point, it’s fair to say one of BTC’s commandments is, “Thou Shalt Not Hard Fork”.
This strategy is rooted in a fundamental commitment to network stability and the absolute prevention of consensus splits. In the eyes of BTC developers, soft forks are less disruptive and help maintain a coherent blockchain.
However, the pursuit of this strategy does introduce a set of unique challenges. Nodes that have not undergone updates are technically still considered “in consensus.” However, these nodes fall short of accurately interpreting the information on the blockchain due to their lack of awareness regarding new rules. Referred to as “zombie nodes,” they function in relaying transactions and blocks without a full understanding of the content they are transmitting. These misunderstandings among nodes can potentially expose vulnerabilities and create undesirable attack vectors.
In addition to the problem of zombie nodes, soft forks necessitate intricate design and execution to ensure that the changes are backward-compatible, enabling old nodes to continue operating smoothly alongside the upgraded ones. While this approach enables network continuity, it also results in a build-up of what is known as “technical debt.” Technical debt represents the hidden costs incurred when convenient solutions are implemented for immediate gains.
In the context of soft forks, it translates to the increased complexity and potential complications in future debugging and software upgrade processes. As soft forks layer new rules onto the existing protocol, maintaining compatibility becomes progressively intricate, raising the bar for developers and contributing to the cost of maintaining the network’s integrity.
Bitcoin Cash’s Embrace of Hard Forks
Bitcoin Cash, in stark contrast, has been inclined to utilize hard forks as a means of upgrading its protocol. These hard forks represent a clean break from previous versions, mandating that all participants upgrade to the latest iteration for continued participation. This approach, while technically increasing the risk of accidental chain splits, streamlines the development process.
For Bitcoin Cash, hard forks are seen as crucial to achieving its vision of becoming a scalable peer-to-peer electronic cash system. It offers the flexibility to make significant protocol changes to accommodate a growing user base and evolving needs. While hard forks may pose a higher risk, they are considered necessary steps on the path to global adoption and network improvements.
Upgrading via hard forks also allows for a much cleaner development environment, reducing complexity for debugging and further improvements down the road. Bitcoin Cash has gone through such upgrades numerous times over the years without any serious problems and continues such upgrades annually.
Key Takeaway:
The difference between hard forks and soft forks lies in their impact on network consensus and compatibility. Hard forks create a clean break from previous versions and require all nodes to upgrade, while soft forks are backward compatible and allow old and updated nodes to coexist. BTC has favored soft forks to prevent consensus splits but has faced increased complexity and technical debt. In contrast, Bitcoin Cash has embraced hard forks for cleaner development environments and easier debugging, despite the perceived risk of chain splits.
Implementing Protocol Changes
The separate evolution of BTC and Bitcoin Cash has given rise to distinct governance structures. In this section, we delve into the intricate process of implementing protocol changes within these blockchain networks. While both share a common heritage, their paths diverge when it comes to decision-making, development, and protocol adjustments.
BTC and Bitcoin Cash have adopted distinct methods for initiating improvements to their respective networks. While BTC’s process for enhancements involves a certain amount of gatekeeping around the official node, Bitcoin Cash embraces a more decentralized approach involving multiple node teams and stakeholders. These unique strategies each have their own advantages and drawbacks, contributing to the individual journeys of these innovative cryptocurrencies.
The Origins of Protocol Changes
As explored in a previous article, both BTC and Bitcoin Cash trace their roots to a shared origin. Satoshi Nakamoto, the creator of Bitcoin, introduced it as open-source software, meaning that the code was accessible for public scrutiny, improvements, and potential forks into alternative directions. Initially, Satoshi made unilateral development choices, but as time passed, he welcomed the contributions of an increasing number of developers and played a coordinating role in development efforts.
After Satoshi left the project, the Bitcoin client continued to be developed by the various volunteer developers who had joined in. When the block size wars were being fought, Bitcoin developers were split into the two camps. Without an overwhelming consensus, the Bitcoin consensus rules on the block size limit could not be updated.
Following Satoshi’s departure from the project, the development of the Bitcoin client shifted to a collective of volunteer developers who had become involved. During the block size wars, Bitcoin’s development community splintered into two factions. The absence of a definitive consensus within the community hindered any updates to the Bitcoin consensus rules regarding the block size limit.
A few developers (including Gavin Andresen – Satoshi’s handpicked successor to continue maintaining Bitcoin’s code) introduced an alternative client known as Bitcoin XT, designed for miners to adopt.
The hope was that if a sufficient number of miners chose to run this alternative client, it would compel a protocol change. However, this initiative ultimately faltered. A few years later, a similar endeavor called Bitcoin Classic emerged with the same objective, and while it came closer to achieving its goal, it, too, ultimately failed. These early attempts laid the foundation for the eventual hard fork that resulted in what is now known as Bitcoin Cash.
The Core of the Protocol
Although there exist several alternative node implementations for BTC, the primary and widely recognized reference client is Bitcoin Core. In the realm of protocols, a reference client serves as the official software implementation. Bitcoin Core takes center stage in development efforts, with other node teams actively striving to maintain consensus with it, all while incorporating their unique features into the mix.
Despite the open-source nature of Bitcoin Core’s code, the responsibility of maintaining the Bitcoin Core repository on GitHub falls into the hands of a select few individuals. This small group acts as the gatekeepers, entrusted with the crucial task of reviewing and merging code contributions. This aspect is frequently regarded as a potential vulnerability within the supposed decentralization of the BTC project, designed to eliminate central points of failure. However, the optimistic perspective hinges on the expectation that these maintainers will actively pursue general consensus before incorporating any alterations.
Crafting Consensus on BTC
Bitcoin Improvement Proposals (BIPs) make up a system that facilitates consensus for the proposal, discussion, and implementation of changes and improvements to the BTC protocol. It provides a structured framework for developers and community members to propose ideas, gather feedback, and collaborate on the evolution of the BTC network. Here’s an overview of how the BIP process works:
Proposal Submission: Anyone can submit a BIP by creating a document that outlines a specific proposal for a change or improvement to the BTC protocol. The BIP document should include a clear explanation of the problem being addressed, the proposed solution, and the potential benefits or drawbacks. The document is typically written in a specific format and follows a template provided by the BIP repository.
BIP Number Assignment: Once a proposal is submitted, it receives a unique BIP number, which helps identify and reference it. The BIP number indicates the proposal’s status and category. For example, BIPs in the “Draft” stage have not yet been finalized, while those in the “Final” stage have been accepted and implemented.
Community Review and Feedback: After a BIP is submitted, it undergoes a community review process. Developers, community members, and other stakeholders can provide feedback, suggestions, and critiques on the proposal. This feedback is crucial for refining the proposal and addressing potential concerns or technical challenges.
BIP Discussions and Consensus: BIP discussions take place on various online platforms, including mailing lists, forums, and developer meetups. The BTC community engages in discussions to debate the merits of the proposal, evaluate its technical feasibility, and determine its potential impact on the network. Consensus is reached through a rough consensus, meaning broad agreement among the community rather than strict voting mechanisms.
Implementation and Testing: If a BIP gains sufficient support and consensus from the community, developers can start implementing the proposed changes in the BTC software. The implementation undergoes thorough testing to ensure its compatibility, security, and reliability.
BIP Activation and Deployment: Once the implementation is considered stable and ready, a process for activating and deploying the changes is defined. This may involve reaching a specific block height or obtaining a certain level of network-wide adoption. The deployment process is carefully planned and communicated to minimize disruptions and ensure a smooth transition.
BIP Finalization: After successful deployment, a BIP can be considered finalized. It is marked as “Final” and included in the official BIP repository as part of the BTC protocol’s historical record.
Distributed Evolution
During the pivotal fork that led to the divergence of BTC and Bitcoin Cash, the designated reference client for Bitcoin Cash emerged as Bitcoin ABC, with ABC denoting Adjustable Block size Cap. Alongside Bitcoin ABC, several other developer teams contributed to alternative code implementations for Bitcoin Cash. Initially marked by collaboration, a shift occurred over time as the other developer teams perceived Bitcoin ABC to be acting in bad faith, prioritizing their own agenda while neglecting the concerns of the broader community.
The intricate dynamics between Bitcoin ABC and other developer teams reached a critical juncture when Bitcoin ABC disregarded a meticulously researched difficulty adjustment algorithm proposed by the other teams. Rather than adopting the well-vetted solution, Bitcoin ABC pursued its in-house alternative.
Adding to the contentious atmosphere, Bitcoin ABC introduced the Infrastructure Funding Plan (IFP), a protocol change that sought to redirect a portion of new coins from each freshly mined Bitcoin Cash block into a development fund exclusively under the control of Bitcoin ABC. This move further fueled the discord within the Bitcoin Cash community.
Following extensive deliberation, the community overwhelmingly rejected the proposed change. Swiftly, an alternative node implementation, known as Bitcoin Cash Node, was assembled, released, and communicated to miners. Bitcoin Cash Node seamlessly replaced Bitcoin ABC as a readily adoptable alternative.
Following its release, virtually all miners ended up switching to Bitcoin Cash Node to follow the chain that did not exact a tax on new coins on behalf of Bitcoin ABC. As a result, Bitcoin ABC forked off of Bitcoin Cash and began a new cryptocurrency. In an historic first in the cryptocurrency world, Bitcoin Cash successfully ousted its reference node team.
An intriguing outcome has been the enhanced decentralization of Bitcoin Cash. Unlike BTC, where Bitcoin Core serves as the reference implementation, Bitcoin Cash takes a different approach. None of the node implementations, including BCHN, assert themselves as the official software for miners or node operators. Consequently, there’s no designated “official” software. Instead, all node development teams depend on ongoing collaboration with each other and other stakeholders to uphold and enhance the protocol.
A CHIP Off the Old Block
Somewhat derived from the BIP for BTC, Bitcoin Cash developers and stakeholders eventually settled on Cash Improvement Proposals (CHIPs) as the primary process of proposing, deliberating, and implementing changes on Bitcoin Cash. The general description of the CHIPs process is as follows:
Proposal Submission: Anyone interested in suggesting a consensus change or improvement can submit a CHIP on bitcoincashresearch.org. The proposal document usually outlines the problem or limitation being addressed, the proposed solution, and its potential benefits or impacts.
Review and Feedback: Once a proposal is submitted, it undergoes a review process by the community. Feedback, suggestions, and critiques are provided to evaluate the proposal’s technical feasibility, potential consequences, and alignment with the Bitcoin Cash ethos. The goal is to foster consensus and refine the proposal based on constructive feedback and collaboration. If consensus among the various node teams and stakeholders cannot be reached, the proposal usually does not go forward any further without appropriate changes being made.
Implementation and Testing: If a consensus change proposal gains sufficient support and is deemed technically feasible, developers work on implementations of the proposed changes. The implementations undergo months of extensive testing on one or more testnets to ensure its compatibility, security, and functionality.
Deployment and Activation: A carefully planned deployment strategy is devised to activate the proposed consensus changes. Network updates are only implemented every May 15 at 12pm UTC and all clients lock in all changes six months ahead of that date. That way, all stakeholders are notified far in advance of a coming change. Due to the thorough preparation by all the node teams and the rest of the ecosystem, Bitcoin Cash updates are typically seamless.
Monitoring and Evaluation: After the consensus changes are activated, the network’s performance, stability, and security are closely monitored. Any unforeseen issues or bugs that arise are addressed promptly through bug fixes or further adjustments to the consensus rules if necessary.
Strengths and Weaknesses
The robust governance structure of BTC derives its strength from the multitude of developers actively proposing, reviewing, and offering feedback on potential code changes. This extensive engagement collectively minimizes the risk of malicious or untested code infiltrating the Bitcoin Core repository.
However, a notable weakness persists due to the reliance on a singular reference implementation that officially dictates the network’s consensus rules. This concentration of power allows one team to exert significant influence over BTC’s development, potentially deviating from its foundational principles.
In stark contrast, the strength of governance in Bitcoin Cash lies in its decentralized nature, where multiple node teams collaborate to shape network changes. This approach establishes a precedent for replacing rogue node implementations, aligning seamlessly with the vision of peer-to-peer cash and ensuring continuity in the foreseeable future.
Nevertheless, a distinct weakness arises from a limited pool of developers dedicated to improvements. Despite their expertise, the dispersion of talents leads to a focus on high-priority needs, potentially delaying the implementation of many desired improvements.
Key Takeaway:
BTC and Bitcoin Cash have different governance structures. BTC uses the Bitcoin Improvement Process to implement changes in node policies or in the protocol. There is a single reference client that dictates the protocol that the entire BTC ecosystem must follow to remain in consensus. Upgrades are made through soft forks that reduce the risk of chain splits but introduce technical debt. Bitcoin Cash adopted a decentralized approach with no official reference implementation. Instead, developers rely on cooperation and collaboration among various node teams and stakeholders. Bitcoin Cash uses Cash Improvement Proposals (CHIPs) to implement new rules or consensus changes. Bitcoin Cash utilizes hard forks when upgrading the protocol, which reduces technical debt.
Conclusion
BTC and Bitcoin Cash showcase divergent approaches across crucial dimensions. The disparity in consensus mechanisms highlights a trade-off between flexibility and robustness, as BTC potentially allows for deep reorgs, while Bitcoin Cash employs rolling checkpoints for resilience, albeit with a slight risk of consensus chain splits. This choice prompts reflection on the balance between adaptability and security in shaping the future of blockchain protocols.
Fork strategies reveal another stark contrast. BTC’s soft forks prioritize network stability but accumulate technical debt, while Bitcoin Cash’s penchant for hard forks seeks a cleaner development environment at the cost of backward compatibility. The tension between stability and adaptability emerges as a critical consideration for the evolving landscape of cryptocurrencies.
Governance structures add a final layer to this narrative. BTC’s Bitcoin Improvement Process and singular reference client offer resilience but risk concentrating power. In contrast, Bitcoin Cash’s decentralized approach, lacking an official reference implementation, fosters flexibility but raises concerns about development efficiency. As these digital currencies shape distinct trajectories, the evolving cryptoverse must grapple with the nuanced choices between centralized efficiency and decentralized collaboration, charting a course that defines the next era of decentralized innovation.
Explore the Full Series of
“What is the Difference Between Bitcoin and Bitcoin Cash?”
Part 3:
Coordinating Consensus
Stay in the loop – subscribe to receive instant notifications on our latest blog posts, delivered straight to your inbox
