Bitcoin Cash Upgrade 2023
Bitauth.com open source software will support four Cash Improvement Proposals (CHIPs) for the 2023 Bitcoin Cash Upgrade.
In preparation for the November "lock-in" phase of the Cash Improvement Proposal (CHIP) process, I'd like to offer my support for four proposals to be activated in May 2023.
CHIP-2021-01 Restrict Transaction Version
CHIP-2021-01 Minimum Transaction Size
Additionally, I recommend that all actively-maintained software migrate to
chipnet as the primary test network for Bitcoin Cash.
Chipnet is tuned to remain lightweight, easy to mine, and 6 months ahead: Chipnet deploys network upgrades in November, giving developers months to build with new upgrades before they're active on the main network. Chipnet offers more certainty, wider testing, and stronger launches. 🚀
The Bitcoin Cash network is upgraded every year on May 15th. There's no centralized foundation or organization managing this upgrade: it's an informal convention maintained by the many development teams, businesses, and organizations making up the Bitcoin Cash ecosystem.
From 2009 to 2019, Bitcoin Cash's upgrade process was driven by contributions to the most popular node implementation, often placing its maintainers in lucrative, influential, and polarizing positions. Disputes between developers and other teams were poorly mediated, and the resulting upgrades were plagued with uncertainty around acceptance and activation timelines. These issues lead to several network splits (BTC, BSV, and XEC).
The Cash Improvement Proposal (CHIP) process allows for greater collaboration, less brinkmanship, and a healthier, more decentralized development ecosystem.
CHIPs can be proposed and championed by anyone, and acceptance is a collaborative process between the many development teams, businesses, and organizations making up the Bitcoin Cash ecosystem.
By convention, CHIPs must meet several milestones to be considered viable for inclusion in an upgrade. These milestones ensure proposals are widely circulated and reviewed long before they are activated, allowing ecosystem stakeholders adequate time to analyze and provide feedback.
Widely-supported CHIPs make their way into node implementations and other open source software, paving the way for the "lock-in" phase of the process.
CHIPs must be "locked in" by November 15th (in time for activation on
chipnet). While a last-resort dispute resolution process is specified, most CHIPs can be locked-in by a less adversarial, collaborative, informal process.
After meeting all pre-lock-in milestones, CHIP owners must gather public statements from as many ecosystem stakeholders as possible: Bitcoin Cash service providers, exchanges, businesses, miners, organizations, and development teams of nodes, indexers, wallets, and other ecosystem software.
CHIPs must demonstrate overwhelming, widespread approval. In many cases, stakeholders may abstain from rendering a decision on a CHIP, but disapproval should be rare, minor, and well-addressed. CHIP owners are encouraged to mediate and resolve differences, and if necessary, delay activation until the next year's upgrade.
In most cases, disagreements are surfaced and addressed early in the CHIP process, creating a more collaborative environment and reducing wasted effort. Proposals that accomplish this process have already demonstrated technical excellence, prudent consideration of costs and risks, and thoughtful attention to all stakeholder requirements and feedback.
These "uneventful" CHIPs are widely considered to be "locked-in", and the ecosystem saves considerable effort by avoiding the need for on-chain signaling, voting, or other more costly consensus-building methods.
Supporting CHIPs for Lock-In
To demonstrate widespread approval, CHIPs must collect public statements from stakeholders. Stakeholders interested in the success of a CHIP can help by offering public support.
Below I've summarized each of these proposals and why I think they should be included in the May 2023 upgrade.
CHIP 2021-01 Restrict Transaction Version
CHIP 2021-01 Restrict transaction version is a proposal by
Tom Zander, Jonathan Silverblood, and bitcoincashautist to restrict the transaction
version field to the available versions (
Currently, nonstandard transactions can be created with any value in that field, a legacy of the idea that upgrades should not modify existing fields (a "hard fork"), and instead covertly add new fields (a "soft fork"). This idea leads to unnecessary technical debt and protocol complexity, and Bitcoin Cash has repeatedly demonstrated that non-covert upgrades lead to a simpler, more efficient protocol.
This CHIP paves the way for future transaction version upgrades that could save significant network bandwidth and blockchain storage space. I fully support its activation in the May 2023 upgrade.
CHIP 2021-01 Minimum Transaction Size
CHIP 2021-01 Allow transactions to be smaller in size is a proposal by
Tom Zander to lower the minimum transaction size from 100 bytes to 65 bytes.
The 100-byte minimum was added to prevent an obscure type of payment fraud that is possible with a 64 byte transaction. However, a 100-byte limit is overly restrictive: useful transactions can be created in the range between 65 and 100 bytes.
Allowing transactions to be as small as 65 bytes avoids wasting bandwidth and storage. I fully support activation of this CHIP in the May 2023 upgrade.
CHIP 2022-02 CashTokens
CHIP-2022-02-CashTokens is my proposal to enable two new primitives on Bitcoin Cash: fungible tokens and non-fungible tokens.
Beyond simply being able to represent other assets on Bitcoin Cash, CashTokens also enable decentralized applications on Bitcoin Cash comparable to Ethereum (ETH) contract functionality, while retaining Bitcoin Cash's >1000x efficiency advantage in transaction and block validation.
I've written a more extensive overview of CashTokens. I also published a proof of concept for a non-custodial, censorship-resistant decentralized exchange built directly on Bitcoin Cash. This Twitter thread explains how it works, how it outperforms "global state" systems like Ethereum, and how it could make a big impact in real world use cases:
You can find the code and technical summary on GitHub, and there's also a higher-level overview in this blog post: Jedex: Decentralized Exchanges on Bitcoin Cash.
CashTokens has been through significant review, is already implemented in popular open source software, and the CashTokens testnet has already processed thousands of test transactions. I fully support activation of CashTokens in the May 2023 Bitcoin Cash upgrade.
CHIP 2022-05 P2SH32
CHIP-2022-05-P2SH32 is a proposal by
bitcoincashautist to enable 32-byte, Pay-to-Script-Hash (P2SH) outputs. This solves a long-standing, expensive-but-serious vulnerability in certain types of contracts.
I've written more about the vulnerability, including an extensive overview of possible alternative solutions and why they are more complicated and less efficient than this CHIP.
This vulnerability has been well understood since before the BCH/BTC split, but solving it has recently become more important: Bitcoin Cash contracts are becoming much more powerful. Recurring payments, time-delayed vaults, long/hedge derivatives, crowdfunding and assurance contracts, decentralized exchanges, sidechains, and more – many smart contract use cases will soon be more efficient on Bitcoin Cash than on any other cryptocurrency.
Solving this vulnerability in the next upgrade is critical for the long-term, overall security of the Bitcoin Cash contract ecosystem. The P2SH32 CHIP is a simple, complete solution to the problem, and I fully support its activation in the May 2023 upgrade.
Open Source Software Support
The following open source software will include support for the 2023 Bitcoin Cash upgrade on or before Feb 15, 2023.
Discussion & Contributions
For questions and discussion regarding these planned upgrades to Bitauth.com open source software, please join us in the Bitauth Telegram Group or the project-specific chat groups: Bitauth IDE, Chaingraph Devs, and Libauth Devs.
You can also follow each project on GitHub:
Post released to the public domain under CC0-1.0, no attribution necessary.