What is the Difference Between Bitcoin and Bitcoin Cash? – Part 4: Divergent Evolution Explored
Explore the Full Series of
“What is the Difference Between Bitcoin and Bitcoin Cash?”
Part 4:
Divergent Evolution Explored
Embarking on distinct trajectories since the 2017 split, Bitcoin (BTC) and Bitcoin Cash (BCH) have evolved with unique approaches to blockchain development. In this sweeping exploration, we delve into the shared and distinctive upgrades that have shaped the course of these two prominent cryptocurrencies.
From fundamental changes affecting transaction handling to innovations fostering scalability and security, we navigate through the key upgrades, shedding light on how BTC and Bitcoin Cash have addressed the challenges posed by the dynamic landscape of decentralized money.
While our focus spans across pivotal upgrades, it’s important to note that this article is not an exhaustive encyclopedia of every single modification on the two blockchains. Instead, we aim to distill the essence of their developmental journeys, emphasizing the upgrades that have had significant implications for users, developers, and the broader cryptocurrency community.
Moreover, our approach strives to strike a balance between depth and accessibility, ensuring that even those with a general interest can grasp the evolution of these cryptocurrencies. So, join us on this journey of exploration, where we demystify the complexities, celebrate the innovations, and provide insights into the fascinating difference between Bitcoin and Bitcoin Cash improvements.
Table of Contents:
1 MB Block Size Limit
Disabled Opcodes
Pay To Script Hash
OP_RETURN
Replace-By-Fee
Segregated Witness
Taproot
Full Replace-By-Fee by Default
Configurable Block Size Limit
No Replace-By-Fee
CashAddr
Re-enabled Opcodes
Larger OP_RETURN
Canonical Transaction Ordering
Graphene
External Message Validation
Schnorr Signatures
No Unconfirmed Transaction Chain Limit
Upgraded Difficulty Adjustment Algorithm
Multiple OP_RETURNs
Double-Spend Proofs
Native Introspection Opcodes
Bigger Script Integers
Pay-To-Script-Hash-32
CashTokens
Adaptive Block Size Limit Algorithm
UTXO Fastsync & UTXO Commitments
Reusable Payment Addresses
XThinner & Blocktorrent
Common Heritage
As explored in an earlier article, Bitcoin (BTC) and Bitcoin Cash (BCH) originate from a common source, akin to two branches of the same tree. Consequently, they inherit certain foundational features. The entire protocol history, from Satoshi Nakamoto’s initial software execution to the divergence of the two blockchains, is a shared legacy between the two.
Here are some notable features that were integrated into the protocol before the 2017 split. While there are numerous other features beyond those listed, it’s worth highlighting the ones discussed in this section. These features are mentioned because they have undergone modifications or upgrades on either BTC, Bitcoin Cash, or both. Now, let’s explore the initial capabilities each coin had after the split.
1 MB Block Size Limit
While not exactly a “feature”, the block size limit serves as a crucial safeguard. Furthermore, its relevance extends to the subsequent upgrades on the two primary Bitcoin-derived chains.
In Bitcoin’s early days, there was no defined limit on the size of blocks of transactions. However, in July 2010, Satoshi Nakamoto introduced a 1 MB limit without providing explicit reasons for doing so. The apparent concern was that a malicious miner might generate blocks too large for others to accept, potentially leading to a chain split.
Satoshi, while never explicitly giving his reasons for inserting the limit, evidently aimed to eliminate the limit once the network demonstrated its capability to handle larger blocks. Despite these stated intentions, the limit planted the seeds of discord within the Bitcoin community.
Disabled Opcodes
Opcodes that have been disabled are more of an anti-feature. Satoshi obviously had big ideas from the start. But as will be shown, they were not quite production-ready. But it sets the stage for the further development of features down the road.
Bitcoin Script effectively serves as the language for transactions, carrying out various functions through commands known as opcodes. These opcodes were present in the initial implementation of Bitcoin, with some remaining largely dormant during the cryptocurrency’s initial year.
In 2010, the identification of bugs related to certain opcodes raised concerns as their exploitation could potentially crash nodes and enable the unauthorized spending of coins. Given the uncertainty regarding bugs in other opcodes, a precautionary measure was taken for safety, resulting in the removal of numerous unexplored opcodes.
The disabled opcodes encompassed a range of functionalities, including splicing operations like OP_CAT, logical operations such as OP_AND and OP_OR, and arithmetic operations like OP_MUL and OP_DIV. A comprehensive list of these disabled opcodes can be found here.
The removal of these opcodes deprived the Bitcoin community of the opportunity to explore intriguing applications that could have been developed using them.
Pay To Script Hash
Pay To Script Hash (P2SH) is a transaction type that became part of the Bitcoin protocol in April 2012. Before its introduction, several transaction types were already in existence:
Pay To Public Key (P2PK): This type enables the locking of coins to a specific public key, which can be unlocked by the corresponding private key.
Pay To Public Key Hash (P2PKH): The most prevalent transaction type, similar to P2PK. It allows coins to be locked to a hash of a public key, offering added security by avoiding the need to reveal the complete public key.
Pay To Multisig (P2MS): This type facilitates the locking of coins to multiple public keys, requiring M-of-N signatures from those public keys for unlocking.
P2SH was an innovative addition that enabled coins to be locked to a custom redeem script. The receiving “address” for the coins is a hash of the script. To enhance privacy, the redeem script can remain undisclosed until the coins are redeemed. At that point, the script must be provided and matched with the hash to enable spending.
The redeem script can encompass various requirements for spending the coins, such as a time delay or limiting payments to specific addresses. Due to the versatility of P2SH, most multisig transactions use it rather than P2MS. Overall, the possibilities of P2SH transactions are limitless.
OP_RETURN
From the early days of Bitcoin, there have been those utilizing it for data storage. However, some in the community opposed the idea of Bitcoin storing non-transaction-specific data. The initial methods of inserting data into the blockchain relied on exploiting opcodes, resulting in valid unspent transaction outputs (UTXOs) that could never be spent but also could never be pruned from the blockchain.
OP_RETURN emerged as a compromise facilitating the insertion of arbitrary data into transactions. Crucially, the OP_RETURN opcode designates the output as provably unspendable, allowing for the pruning of these outputs from the UTXO set.
OP_RETURN technically existed from the outset, permitting data up to 10,000 bytes. Nevertheless, these transactions were considered non-standard, resulting in nodes refusing to relay them.
To accommodate those seeking to include data in the blockchain, the standardization of relaying OP_RETURN transactions was implemented in 2014, allowing a size of up to 40 bytes. Initially proposed at 80 bytes, the decision to limit it was driven by certain developers aiming to discourage specific use cases surrounding OP_RETURN.
At that time, a protocol layer named CounterParty was under development, aiming to utilize OP_RETURN data for token creation and establish a token-trading platform. However, many developers viewed these use cases as spam, leading to the reduction of OP_RETURN to 40 bytes, limiting its capacity.
Frustration mounted as Bitcoin developers resisted expanding the data capacity of OP_RETURN. Advocates argued that, if a transaction paid a sufficient fee for inclusion in the blockchain, it should accommodate arbitrary data. Amid these debates, numerous Bitcoin use cases were abandoned, and several projects migrated to Ethereum, where experimentation was more encouraged. Finally, in 2016, the OP_RETURN relay limit was raised to the initially-proposed 80 bytes.
Replace-By-Fee
Replace-By-Fee (RBF) is a contentious “feature” that establishes rules for substituting a prior, unconfirmed transaction with a nearly identical one but featuring a higher fee. The intention is to increase the likelihood of confirmation when a transaction is stalled due to an insufficient miner fee.
From Bitcoin’s inception, nodes retained the freedom to tailor their transaction relay policies, and miners possessed the authority to validate any iteration of a transaction they encountered. However, the convention was to relay or confirm the first version of the observed transaction.
This approach was both logical and practical, particularly in a commercial context. When a customer uses Bitcoin to pay for a product or service, the transaction typically doesn’t receive immediate confirmation. Instead, it needs to be mined into a block, a process occurring approximately every ten minutes. Thus, when a business identifies a transaction on the blockchain indicating payment, a certain level of confidence should be associated with its eventual confirmation.
But if any version of the transaction can be confirmed, another transaction might later replace it, directing the funds elsewhere (e.g. back to the spender). This could undermine the business’s confidence in the transaction. The question arises: Why would RBF become a feature if it introduces potential confusion into commerce?
In 2016, Bitcoin transactions consistently occupied over half of the available block space, leading to a surge in transaction costs. To address this, in February of that year, opt-in RBF was standardized in the Bitcoin Core client. Subsequently, users, if permitted by their wallet software, could mark their transactions as potentially replaceable. The responsibility then fell on those accepting Bitcoin payments to check for RBF-flagged transactions and respond accordingly.
Key Takeaway:
Key features (or the lack thereof) set the stage for future upgrades on BTC and Bitcoin Cash. The block limit, opcodes, and transaction policies all contributed heavily to the eventual block size wars. After the 2017 split of Bitcoin, which led to the separate chains of BTC and Bitcoin Cash, each coin dealt with these issues in divergent ways over the ensuing years.
BTC Upgrades
Following the 2017 split between BTC and Bitcoin Cash, BTC developers found themselves liberated from the incessant pressure to increase the block size. Those users and developers advocating for a more scalable blockchain had largely migrated to Bitcoin Cash or elsewhere in pursuit of a network that could expand in tandem with demand.
In the view of BTC proponents, the debate was considered settled, and the block size war had concluded with a victory for small (1 MB) blocks indefinitely. This outcome granted them the freedom to shape the protocol according to their vision, emphasizing no substantial block size expansions at the base layer and a commitment to avoiding hard forks.
Since the 2017 split, BTC has witnessed only two notable upgrades, which we will delve into along with an anticipated update on the horizon.
Segregated Witness
The introduction of Segregated Witness (SegWit) in August 2017 was a milestone in BTC’s development, addressing the scalability challenge without resorting to a hard fork. In SegWit, the “witness,” representing the transaction’s cryptographic signature, is segregated from the transaction data. This segregation, coupled with a redefined approach to block space, resulted in an increased capacity within each block. With all transactions adopting SegWit, the effective block space could reach 1.8 MB, accommodating more transactions.
An important benefit of SegWit is the potential reduction in transaction fees. By accommodating more transactions in each block, the competition for inclusion diminishes, resulting in lower fees. This becomes especially critical during periods of heightened network congestion when transaction fees tend to surge. Despite the effective block size increase to 1.8 MB, fees could still pose challenges during periods of high transaction demand.
SegWit not only enhances throughput but also addresses the vulnerability of transaction malleability. Transaction malleability poses a risk by allowing third parties to modify certain transaction properties. Through the segregation of witness data, SegWit eliminates this malleability risk, bolstering the security and reliability of BTC transactions. This reduction in malleability laid the groundwork for the development and implementation of second-layer scaling solutions, such as the Lightning Network.
BTC developers successfully implemented the entire Segregated Witness (SegWit) update through a soft fork. Unlike hard forks that loosen protocol rules, soft forks impose restrictions. A peculiar aspect of soft forks is that, from the perspective of non-updated nodes, the system seems to adhere to the old rules. The update essentially employs a strategy to coax the old nodes into participating rather than rejecting blocks, resulting in some intriguing side effects.
One consequence is that the SegWit update is essentially irreversible once implemented. Any identification of systemic issues would necessitate a hard fork to return to the pre-SegWit rules. Given BTC’s aversion to hard forks, it implies that SegWit is likely a permanent fixture, whether it proves beneficial or not.
Taproot
BTC’s Taproot update, activated in November 2021, represents another significant milestone for BTC. At its core, Taproot introduced a new scripting language called Tapscript, along with the implementation of Schnorr signatures. These innovations bring enhanced privacy in some use cases and slightly more scalability due to smaller transactions.
Taproot’s standout feature lies in its capacity to enhance the privacy of intricate transactions. By incorporating Schnorr signatures, numerous signatures within a transaction can be consolidated into a single signature. This aggregation renders multi-signature transactions indistinguishable from their single-signature counterparts, bolstering privacy and fortifying the BTC network against specific forms of blockchain analysis. Nonetheless, critics have voiced concerns about potential inadvertent privacy leaks stemming from the introduction of new transaction types.
Similar to SegWit, the Taproot upgrade was facilitated through a soft fork. Consequently, outdated nodes aren’t mandated to update to the latest version for consensus maintenance. However, this also implies that old nodes might not accurately interpret the information they receive, echoing the peculiarities associated with the SegWit update.
Full Replace-By-Fee by Default (In Development)
Initially, Replace-By-Fee (RBF) was an opt-in feature when standardized. However, BTC developers are now contemplating a software update to consistently accept and relay duplicate transactions with higher fees. Importantly, this proposed change wouldn’t impact consensus rules, eliminating the need for a fork to implement this update.
The primary advantage of adopting a transaction acceptance and relay policy that always allows higher-fee duplicates is clear: users who initially set insufficient fees on their transactions can resend them with higher fees, enticing miners to expedite confirmations. In times of heightened network activity and limited block space, competition for transaction inclusion intensifies, leading to higher fees. While the full-RBF policy presents an attractive solution under such circumstances, it comes with trade-offs in terms of commercial efficiency.
In the existing opt-in RBF policy, businesses receiving BTC payments can choose to exclusively accept non-RBF-enabled payments for certain services. For instance, if managing a BTC ATM, dispensing cash would ideally rely on transactions with a reasonable expectation of non-replacement before confirmation.
However, with full RBF as the default, businesses would lose the certainty of a one-and-done transaction. The constant potential for a replacement transaction redirecting the payment elsewhere means that, under a full-RBF policy, goods and services could never be reliably delivered or guaranteed at the point of sale. Waiting for a blockchain confirmation would become a necessity, introducing significant complications to certain transactions.
Key Takeaway:
Since the split with Bitcoin Cash in 2017, BTC has undergone just a few major upgrades. These upgrades have contributed to modest scalability improvements, a malleability fix to lay groundwork for second-layer payment channels, increased privacy for certain transactions, and transaction fee policies that favor the need for confirmation over point-of-sale use cases.
Bitcoin Cash Upgrades
Compared to development on BTC, Bitcoin Cash development has proceeded at quite a rapid pace. And, in quite the contrast to BTC norms, Bitcoin Cash has fully adopted a strategy of hard forking when the consensus rules need to be updated.
Apart from the hard fork that led to the split between the two coins, Bitcoin Cash has undergone nine additional hard forks. Initially, major upgrades, which could involve a hard fork, were planned every six months, occurring on May 15 and November 15. However, in recent years, a shift to annual updates on May 15 has become the new convention.
Bitcoin Cash has witnessed the introduction of numerous new capabilities, a revival of some old features, and the ongoing development of a few upcoming features. In the following sections, we’ll delve into several of these aspects, shedding light on the evolution and current state of Bitcoin Cash.
Configurable Block Size Limit
The block size was the key point of contention in the aptly-named block size wars when there was only one version of Bitcoin. One of the very first upgrades on Bitcoin Cash was the complete elimination of a hard block size limit and allowing a configurable limit in the consensus rules. But that doesn’t mean that blocks can be any size.
Bitcoin Cash introduced a user-configurable Excessive Block setting (EB) in its initial clients, featuring a default value of 8 MB. Miners on the Bitcoin Cash network technically have the flexibility to adjust the EB based on their preferences. However, achieving consensus and coordination for the EB among the vast majority of the hashpower is crucial to avoid disagreements over which blocks to accept. Without this alignment, the potential for reorganizations and confusion can emerge within the network.
It’s important to note that these scaling efforts involve much more than simply changing a variable in the node implementation. Proper scaling requires a lot of research and testing, breakthroughs in database management, efficiency improvements, identifying and removing bottlenecks, and software optimizations. All this and more helps to ensure rational and safe scaling for the Bitcoin Cash blockchain.
In the year following the split, Bitcoin Cash successfully coordinated to increase the EB to 32 MB. This adjustment aimed to enhance the network’s maximum throughput to over 200 transactions per second, a significant rate compared to BTC’s theoretical maximum of 12 transactions per second. For proponents of Bitcoin Cash, this initiative represented just the initial phase of the coin’s broader efforts to scale, with further developments discussed later in this exploration.
No Replace-By-Fee
In addition to removing the hard limit on the block size, Bitcoin Cash promptly eliminated Replace-By-Fee (RBF). Within the Bitcoin Cash community, there is a strong commitment to the concept of a genuine peer-to-peer currency. To fulfill the vision of Bitcoin Cash as such a currency, it needs to embody cash-like qualities, minimizing transaction friction. In the eyes of the community, the inclusion of RBF compromises the potential for swift and hassle-free transactions in everyday commerce.
Eliminating Replace-By-Fee means there is no designated method to signal transactions for potential replacement. Consequently, nodes, as a default, exclusively accept and relay the initial version of a transaction they encounter. This streamlined approach facilitates point-of-sale scenarios, ensuring simplicity in transactions. Additionally, with ample room for all transactions due to scaling, Bitcoin Cash users can navigate without concern about transaction delays, providing a substantial advantage for both users and merchants.
CashAddr
In 2018, Bitcoin Cash introduced the CashAddr address format to alleviate confusion with the legacy address encoding used by BTC.
Legacy format:
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
CashAddr format:
bitcoincash:qp3wjpa3tjlj042z2wv7hahsldgwhwy0rq9sywjpyy
CashAddr aims to enhance ease of use when copying and sharing payment information. The primary motivation behind CashAddr was to prevent users from accidentally sending Bitcoin Cash to Bitcoin addresses or vice versa. The choice of CashAddr encoding, based on the Bech32 work, offers advantages such as a human-readable prefix, strong checksums, efficient QR code encoding, and improved speed for address encoding and decoding. The introduction of CashAddr demonstrates the Bitcoin Cash community’s commitment to improving user experience, providing clearer distinctions between different cryptocurrencies, and avoiding potential cross-chain transaction errors. This move aligns with the broader goal of making Bitcoin Cash more user-friendly and accessible.
Re-enabled Opcodes
Between 2018 and 2019, Bitcoin Cash reintegrated numerous opcodes that had been discontinued in BTC. These opcodes, spanning splicing, bitwise logic, arithmetic, and more, offer the capability for straightforward data manipulation with minimal overhead. This restoration of fundamental building blocks provides a level of flexibility conducive to diverse applications. Developers can leverage these opcodes to craft various custom transactions, unlocking a realm of exciting possibilities.
Larger OP_RETURN
In 2018, Bitcoin Cash nodes collaboratively raised the maximum size of OP_RETURN outputs from 80 bytes to 220 bytes. This expansion made it possible to include a considerably larger volume of arbitrary data within the blockchain. This enhanced capability opens the door to various applications, including contract metadata storage, on-chain social media platforms, and colored coin protocols.
The decision to increase the maximum size of OP_RETURN outputs to 220 bytes was strategic. Recognizing the persistent interest in injecting arbitrary data into the blockchain, the adjustment aimed to provide sufficient space within OP_RETURN. This larger capacity discourages users from resorting to alternative methods that might burden nodes with additional data parsing tasks, ensuring a more streamlined and efficient process.
Given that OP_RETURN outputs are unspendable, they can be safely ignored by unconcerned parties. Consequently, the decision to allocate 220 bytes for data storage ensures that it remains the most cost-effective and efficient method for storing data on the blockchain, emphasizing practicality in managing blockchain resources.
Canonical Transaction Ordering
In 2018, Canonical Transaction Ordering (CTOR) emerged as a pivotal consensus change, introducing specific rules for organizing transactions within a block. Prior to CTOR, the ordering of transactions lacked a systematic standard, allowing for various approaches. The implementation of CTOR establishes a uniform transaction ordering protocol, ensuring consistent block reconstruction for a given set of transactions. This standardization enhances predictability and clarity in the blockchain’s structure.
CTOR significantly improves block propagation in the Bitcoin Cash network. When a miner successfully solves a block, timely dissemination to other nodes for validation is crucial in the competitive mining environment. CTOR’s impact on block ordering enhances the efficiency of this process by allowing miners to send only transaction IDs, minimizing redundancy and facilitating rapid block validation. Most nodes already possess the majority of transactions in a new block, and CTOR streamlines the dissemination process by leveraging the redundancy of transaction data. This approach enables nodes to reconstruct the block accurately using provided transaction IDs and the standardized ordering dictated by CTOR.
Graphene
Graphene represents a significant advancement in accelerating block propagation. By leveraging a combination of bloom filters and invertible bloom lookup tables, this technology enables nodes to swiftly identify missing transactions when receiving block data. As a result, when a node broadcasts block information, Graphene facilitates the rapid retrieval of all confirmed transactions within the block for receiving nodes. When coupled with CTOR, Graphene contributes to the efficient and quick reconstruction and validation of new blocks. It’s important to note that Graphene is not a consensus rule but has been integrated into Bitcoin Unlimited, a widely used Bitcoin Cash node implementation.
External Message Validation
In 2018, the Bitcoin Cash protocol incorporated the OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY opcodes. These additions introduced the capability to validate arbitrary messages from sources external to the blockchain. This increased flexibility extends the use cases beyond simple monetary transactions, enabling users to sign and verify various forms of information on the blockchain.
These opcodes provide the virtual machine with the ability to validate messages from external oracles. Such messages might encompass stock or commodity prices, sports results, or any financially relevant data. External agents can sign messages and transactions can be contingent on the validity of these signatures. This opens up the potential for a variety of financial tools and applications on the Bitcoin Cash network.
Schnorr Signatures
In 2019, Bitcoin Cash incorporated Schnorr signatures for both single- and multi-sig transaction types. This signature scheme represents an efficient and versatile alternative to traditional ECDSA in blockchain networks. Schnorr signatures offer advantages such as shorter signature sizes, faster verification, and the capacity to aggregate multiple signatures into one, thereby enhancing privacy and scalability.
Furthermore, Schnorr signatures eradicate third-party transaction malleability, streamlining development for applications that demand non-malleability, such as payment channels. The integration of Schnorr signatures stands as a noteworthy advancement in bolstering Bitcoin Cash’s transaction capabilities and broadening its potential use cases.
No Unconfirmed Transaction Chain Limit
Transactions broadcast to the network remain unconfirmed until they are included in a block, with new blocks being solved approximately every ten minutes. Each transaction relies on inputs from a previous transaction, forming a chain of unconfirmed transactions if the preceding one is still pending confirmation. In BTC, nodes typically restrict such chains to 25 unconfirmed transactions. Additional transactions are rejected until the preceding ones are confirmed.
Bitcoin Cash inherited this same unconfirmed transaction chain limit from before the split. However, given its intended use as a fast and efficient medium of exchange, this limit posed challenges for applications involving frequent transactions.
The year 2020 saw an increase in the unconfirmed transaction chain limit to 50, offering more flexibility in certain scenarios. In a significant move in 2021, this limit was entirely eliminated. With the inherent confidence that any valid Bitcoin Cash transaction would eventually be confirmed, the limit was deemed unnecessary. This change empowers application developers to generate and broadcast chains of unconfirmed transactions of any length, knowing they will ultimately be confirmed.
Upgraded Difficulty Adjustment Algorithm
For those delving into the mechanics of Bitcoin, the concept of a Difficulty Adjustment Algorithm (DAA) likely surfaced. Bitcoin relies on miners to validate transactions by finding a hash of block data that fulfills specific criteria – a foundational aspect of the proof-of-work system. This setup ensures that energy is expended to authenticate transactions, making it highly unlikely that miners would use even more energy to reverse them. The network’s target is to solve a block approximately every ten minutes.
Mining in the Bitcoin network is inherently competitive. An influx of hashpower makes block-solving quicker than the intended 10-minute mark, while a reduction in hashpower extends the time required. The DAA steps in to address this. Originally, Bitcoin’s DAA recalibrated the mining difficulty every 2,016 blocks, roughly every two weeks, aiming to maintain an average block-solving time of around 10 minutes.
Bitcoin Cash has experienced different iterations of the DAA at different stages. Following the 2017 split, uncertainty surrounded the hashpower allocation for Bitcoin Cash. In the event of a significant reduction, such as a quarter of the original chain’s hashpower for example, blocks could potentially take up to 40 minutes, and the difficulty might not adjust for two months. To address this potential scenario, an emergency DAA was promptly implemented at the fork.
The emergency DAA faced challenges, leading to significant oscillations in hashpower as miners alternated between the two coins. Consequently, a few months later, it was replaced by the CW-144 algorithm. This new algorithm sought to assess the variance in chainwork (CW) over the latest 144 blocks, offering some improvements but still exhibiting periodic oscillations.
Bitcoin Cash underwent a significant upgrade in 2020 with the adoption of the Absolutely Scheduled Exponentially Rising Targets (ASERT) DAA. ASERT utilizes an exponential moving average approach to consistently target a correction toward an average block time of 10 minutes. This implementation leads to a dynamically adjusted difficulty, substantially reducing variations in block times.
Multiple OP_RETURNs
In 2021, Bitcoin Cash nodes introduced a new standard that permits the inclusion of multiple OP_RETURN outputs in a single transaction. This update was designed to improve the functionality of OP_RETURN, providing developers with the flexibility to experiment with new features without disrupting existing systems.
This alteration unleashes the complete potential of OP_RETURN’s experimental expressiveness, simplifying the development process for OP_RETURN capabilities. Developers can now more easily build upon these capabilities without the complications of parsing scripts or the need to distribute efforts across multiple transactions.
Double-Spend Proofs
The possibility of double spending unconfirmed transactions poses a slight threat to merchant security. Malicious actors can redirect payments intended for a specific merchant back to themselves, exploiting the gap between transaction initiation and confirmation.
To address this vulnerability, Bitcoin Cash has implemented Double-Spend Proofs (DSPs) which introduces a cryptographic method for network nodes to share provable evidence of double spending attempts on unconfirmed transactions. DSPs enables the validation of identical signatures attempting to spend the same output in pay-to-public-key-hash (P2PKH) transactions.
If a merchant uses software that has fully implemented DSPs, they can get alerts within seconds if a customer attempts a double-spend. Even with node participation as low as 20%, DSPs become a powerful tool for timely detection, allowing merchants to make informed decisions and significantly improving the security of unconfirmed cryptocurrency transactions.
Native Introspection Opcodes
In 2022 Bitcoin Cash added several new native introspection opcodes to the protocol. Native introspection allows Bitcoin Cash contracts to efficiently access crucial details about the current transaction, such as output values and recipients, without imposing additional costs on transaction validation. Native introspection also leads to a significant reduction in covenant transaction sizes.
This efficiency improvement not only simplifies complex transactions but also enhances the possibilities around scheduled and recurring payments. Furthermore, by reducing waste in covenant contracts, native introspection operations open the door to more innovative use cases on Bitcoin Cash like contract transferability, mergeable and splittable contracts, and contracts denominated in different currencies.
Bigger Script Integers
In 2022 Bitcoin Cash also added bigger script integers to allow more flexibility in contracts. Before the upgrade, the virtual machine could only handle math operations on 32-bit integers, which represents up to about 21 BCH. This limitation made it challenging for contracts to work with larger values. Developers found ways around this, but those workarounds were often impractical, hard to secure, and made transactions much larger. Now, with the introduction of covenants, this limit has become more of a problem, causing vulnerabilities in contracts and hindering real-world applications.
64-bit integers bring significant benefits to the Bitcoin Cash ecosystem. By expanding the upper limit for arithmetic operations in contracts, it allows for efficient handling of much larger values, enabling the development of large-scale decentralized applications. This enhancement also eliminates the need for complex higher-precision math emulation, simplifying contract development and reducing the risk of vulnerabilities. Overall, these improvements enhance the functionality, security, and efficiency of Bitcoin Cash contracts.
Pay-To-Script-Hash-32
All Bitcoin-derived chains have an inherent security vulnerability in its P2SH feature (discussed above) due to the known weakness against birthday attacks in the currently used 20-byte variant. Although existing applications remain unaffected, the limitation hinders the creation of certain decentralized applications, making them insecure or impractical.
In 2023 Bitcoin Cash upgraded to a 32-byte variant of P2SH, which enhances the cryptographic security of its system, addressing the vulnerability without requiring action from users. This improvement ensures that applications relying on the upgraded feature will be more secure against collision attacks. The upgrade promotes faster and easier development of new products and applications on the Bitcoin Cash network, benefiting the entire ecosystem by simplifying contract usage and making secure contract development and auditing more accessible.
CashTokens
The CashTokens upgrade is the most substantial upgrade on Bitcoin Cash in years. Implemented in 2023, CashTokens made it possible for native tokens, both fungible and non-fungible, to reside directly and securely on the blockchain. This offers individuals, organizations, and decentralized applications the ability to issue tokens directly on the base layer. The CashTokens upgrade enhances accessibility and versatility within the Bitcoin Cash ecosystem, fostering diverse use cases from NFTs to loyalty programs to sophisticated financial tools.
CashTokens offer valuable benefits to the Bitcoin Cash ecosystem, particularly in cross-contract interfaces and decentralized applications. Through the use of non-fungible tokens, contracts can securely commit to messages, allowing other contracts to trustlessly read and act upon these commitments. This feature ensures impersonation-proof interactions and opens the door to the creation of public interfaces for a wide range of contracts. Additionally, CashTokens support efficient representations of complex internal states, serving as a foundation for the development of advanced decentralized applications on the Bitcoin Cash network.
Read More: What Are CashTokens? – A Guide to Native Tokens on Bitcoin Cash
In the domain of decentralized applications, CashTokens are pivotal for representing on-chain assets effectively, including voting shares, utility tokens, collateralized loans, and prediction market options. Fungible tokens play a crucial role in implementing intricate coordination tasks such as liquidity-pooling, auctions, voting, and sidechain withdrawals. Simultaneously, non-fungible tokens become instrumental in coordinating trustless activity between multiple covenants, enabling constructions like covenant-tracking tokens, depository child covenants, and multithreaded covenants that require specific covenant instances to be authenticated. The introduction of universal token primitives further enhances the ecosystem, supporting the development of interoperable token standards and ensuring broad accessibility across various contracts and wallets.
Adaptive Block Size Limit Algorithm (Expected Upgrade)
Debates about the block size is what originally sparked the Bitcoin fork that became known as Bitcoin Cash. While further increases on the maximum block size allowed by nodes have always been expected, the uncertainty around such debates has been a cause for concern. But now a new block size algorithm, slated for the 2024 upgrade, has the potential to create a new path forward.
The envisioned algorithm represents a significant shift, as it proposes an automatic adjustment of Bitcoin Cash’s effective block size limit following each block, contingent on usage metrics. Under this framework, the potential for the block size to double annually during periods of maximum growth aims to mitigate the challenges tied to manual coordination and susceptibility to social attacks. The current approach, involving consensus among developers, miners, and stakeholders for excessive block (EB) adjustments, could be streamlined, reducing the associated time constraints and potential ecosystem tensions.
The new algorithm for adjusting Bitcoin Cash’s block size is a clever approach that eliminates the need for widespread agreement on every small change. By examining the size of recent blocks, the algorithm dynamically adjusts the limit. The existing 32 MB EB limit serves as a minimum, and the algorithm can increase it in response to growing transaction activity. With its smooth adjustments and inherent flexibility, the algorithm represents a sophisticated and stable solution, demonstrating Bitcoin Cash’s commitment to scalable growth and effective transaction handling.
UTXO Fastsync & UTXO Commitments (In Development)
Every new transaction in Bitcoin Cash depends upon unspent transaction outputs from prior transactions. These unspent transaction outputs are often referred to as UTXOs. The set of all UTXOs at any given moment is the most critical part of the blockchain that a node needs to know in order to validate new transactions. UTXO Fastsync and UTXO commitments leverage this fact to make node syncing much easier.
UTXO Fastsync, which has already been implemented in some Bitcoin Cash nodes, is a way for nodes on the Bitcoin Cash network to quickly share and update their information without going through the usual slow process of downloading and processing the entire history. Without Fastsync, when a new node joins the network, it takes 8 hours or more to download and build the entire history of the blockchain from the beginning up to the present. The goal of UTXO Fastsync is to reduce that time to a couple of hours or less. It introduces the idea of creating and sharing a “snapshot” of the current state of the network, which includes all spendable coins (UTXOs). These snapshots can be easily shared among nodes, helping them sync up faster.
Related to Fastsync, UTXO commitments are currently in development and would require a protocol change. The upgrade would require miners to commit to a specific set of UTXOs in the blocks they generate, providing proof of the state of the network. While UTXO Fastsync radically improves the syncing process, UTXO commitments allow such syncing to be done trustlessly. Combined, they can make it easier for new users, businesses, or projects to run their own nodes on the Bitcoin Cash network. The ultimate goal is to make Bitcoin Cash more scalable as its blockchain grows, preventing long synchronization times and reducing barriers for new developers and applications using the network.
Reusable Payment Addresses (In Development)
Bitcoin Cash addresses are pseudonymous, which means there is technically no identification tied to a particular address. But if a user or business accepts recurring payments through a single published address, privacy is compromised. To accept multiple payments and maintain privacy, the receiver must generate a new address and transmit it to the sender every time a payment is required. This can often force users and businesses to choose between privacy and usability.
Reusable Payment Addresses (RPAs) are currently being developed to address this dilemma. To overcome the above challenges, RPAs introduce a new alias system that allows senders to generate a fresh address for any recipient with a handle. This is achieved through a combination of the Elliptic-curve Diffie-Hellman properties of Bitcoin keys and a simple grinding system, resulting in a byte-prefix. This byte-prefix can be discovered through scanning while also remaining within an acceptable anonymity set. The end result is that users and merchants can share a static paycode and anyone can use that paycode to generate a fresh address and send a payment that is indistinguishable from normal transactions.
XThinner & Blocktorrent (In Development)
XThinner and Blocktorrent are two protocols in varying stages of development that have the potential of speeding up block propagation even faster than Graphene. With current Bitcoin Cash use, compact blocks and Graphene continue to work well. But in the future, if Bitcoin Cash blocks become much bigger, one or both of these protocols may be able to help relieve network bottlenecks.
XThinner focuses on compression, capable of reducing block data to about 12 to 16 bits per transaction, achieving a reduction of up to 99.6%. The protocol has demonstrated strong performance in tests on the Bitcoin Cash mainnet.
Blocktorrent works by breaking down a block into small, independently verifiable chunks for transmission. Each chunk is designed to be about the size of one IP packet. The key goal is to improve block propagation performance by allowing nodes to forward each IP packet shortly after receiving it, regardless of the order or whether other packets have been received. This is a departure from traditional methods where nodes couldn’t forward the first byte until the entire block was received and validated.
These two protocols demonstrate Bitcoin Cash’s dedication to pioneering advancements, showcasing a commitment to ongoing improvements that enhance the scalability and performance of its blockchain network.
Key Takeaway:
Bitcoin Cash has undergone numerous upgrades, showcasing a commitment to innovation and scalability. Key developments include a much larger block size limit, elimination of Replace-By-Fee (RBF), reactivation of disabled opcodes, increased OP_RETURN size, adoption of Canonical Transaction Ordering (CTOR), integration of Graphene technology, addition of many new opcodes, implementation of Schnorr signatures, removal of unconfirmed transaction chain limits, upgraded Difficulty Adjustment Algorithms (DAA), and more. The most significant recent upgrade, CashTokens, introduces native tokens, enhancing smart contract capabilities and ecosystem versatility. Upcoming developments include an Adaptive Block Size Limit Algorithm, UTXO Fastsync, UTXO Commitments, Reusable Payment Addresses, and protocols like XThinner and Blocktorrent aimed at further improving block propagation speed. These advancements demonstrate Bitcoin Cash’s dedication to addressing challenges and expanding its capabilities.
Conclusion
In the aftermath of the 2017 split between BTC and Bitcoin Cash, both cryptocurrencies embarked on distinct developmental journeys, guided by their respective visions and philosophies. BTC, with a focus on security, stability, and conservative changes, chose a path that retained a 1 MB block size limit and adopted upgrades like Segregated Witness (SegWit) and Taproot to enhance privacy and scalability. Bitcoin Cash, in contrast, embraced a more dynamic strategy, frequently hard forking to implement a range of features designed to maximize on-chain scalability, usability, and innovation.
The development pace of Bitcoin Cash has been notably rapid, marked by a series of hard forks and a commitment to exploring new possibilities. The configurable block size limit, removal of Replace-By-Fee (RBF), reactivation of disabled opcodes, and increased OP_RETURN size are among the pivotal upgrades that showcase Bitcoin Cash’s dedication to enhancing user experience and fostering innovation. The adoption of Schnorr signatures, removal of unconfirmed transaction chain limits, and the implementation of Double-Spend Proofs (DSPs) further demonstrate a commitment to security and efficiency.
Recent upgrades on Bitcoin Cash have been particularly transformative. The introduction of CashTokens in 2023 stands out as a significant milestone, enabling native tokens on the blockchain and expanding the ecosystem’s potential use cases, from NFTs and loyalty programs to complex interactive contracts. Looking ahead, the anticipated Adaptive Block Size Limit Algorithm, UTXO Fastsync, UTXO Commitments, Reusable Payment Addresses, and protocols like XThinner and Blocktorrent underscore Bitcoin Cash’s ongoing commitment to scalability, decentralization, and usability.
As the Bitcoin Cash ecosystem evolves, it strives to address challenges and push the boundaries of what’s possible in the realm of decentralized finance, applications, and tokenization. The commitment to innovation, scalability, and adaptability positions Bitcoin Cash as a major contender in the broader landscape of digital currencies. The development choices made by BTC and Bitcoin Cash since their split in 2017 have shaped two distinct approaches to the challenges and opportunities presented by blockchain technology. Ultimately, the success and impact of each cryptocurrency will be determined by the ongoing collaboration and support of their respective communities, developers, and users.
Explore the Full Series of
“What is the Difference Between Bitcoin and Bitcoin Cash?”
Part 4:
Divergent Evolution Explored
Stay in the loop – subscribe to receive instant notifications on our latest blog posts, delivered straight to your inbox
