BUIP063: Support Bitcoin Cash with an official implementation


Staff member
Aug 22, 2015
BUIP063: Support Bitcoin Cash with an official implementation
Submitted on 1st September 2017 by solex


Bitcoin has forked.
This was not the goal of Bitcoin Unlimited which has long pursued consensus for Bitcoin onchain scaling through a combination of debate and action. It was only the advent of the small-blocker UASF which made a forking event inevitable with its rejection of blocks which were not signalling for Segwit from 1st August 2017.

In order for Bitcoin users, full-node owners and miners to continue to have a coherent voice for a Bitcoin without the highly controversial Segwit software, BUIP055 was drafted and voted upon by the BU membership. It has a block height for forking during October 2017 as Bitcoin capacity would have been crippled for 1.5 years by that date. Already colossal damage has been done to its global adoption due to high fees, unreliable confirmation times, and the crushing of many use-cases including 0-conf retail.

A further event occurred. Because most of the Bitcoin ecosystem also has serious concerns about crippled adoption the New York Agreement (Segwit2x) was hammered out. Representatives of most miners and a number of major Bitcoin companies made an agreement to increase the block size limit to 2MB and activate Segwit. This is a very generous compromise towards the small-blockers considering that 2MB is hopelessly inadequate beyond 2017, based upon historical transaction growth rates.
It has a fundamental flaw which is that the increase to 2MB (the "2x") is delayed. Hence, there is scope for this part of the NYA to be derailed.

In a decentralized global ecosystem small initiatives can cascade into large outcomes, BUIP055 was taken forward by a number of developers (notably the BitcoinABC team), and with some mining support created a spinoff, Bitcoin Cash. This has been warmly received by the global cryptocurrency marketplace with a high valuation becoming the fastest growing cryptocurrency both in terms of value and arguably in adoption rate.

Bitcoin Unlimited was part of the Bitcoin Cash launch thanks to the BU developers creating an unofficial release compatible with BitcoinABC, possible because both were framed by BUIP055. The two most significant differences from BUIP055 are:
1. Emergency Difficulty Adjustment
2. Two-way replay protection (NODE_CASH)

With the advent of Bitcoin Cash, a "larger blocks" version in line with the original 2009 Bitcoin versions 0.1 and 0.2 now exists. The divergence in UTXO sets between the legacy Bitcoin and Bitcoin Cash since 1 August is in a large part due to a rebalancing of portfolios where small-blockers have sold and large-blockers have bought.


The purpose of this BUIP is to regularise BU Cash as an official BU implementation with equal status as the existing BitcoinUnlimited implementation which has been advanced and maintained since November 2015.

If passed then BU Cash will be maintained on a permanent basis with regular upgrades. It will also be subject to the BUIP process for functional changes. Obviously, any protocol changes would have to be done after consultation and discussion with all the other teams providing Bitcoin Cash full node software.


Maintenance of the BU Cash implementation would be funded in the same approved manner as the BitcoinUnlimited implementation has always been.


There is no economic case for an artificially capped version of Bitcoin successfully competing with a scalable version. Therefore, it is very possible that the Bitcoin Cash blockchain overtakes the legacy version in total proof-of-work and develops the larger ecosystem becoming globally known as "Bitcoin".

Bitcoin Unlimited should remain positioned to be a part of that future.


Well-Known Member
Aug 28, 2015
This is awesome news. I've been thinking about this. effectively the developers don't need BU membership telling them what they can and can't do.

On the othe hand uniting this effort under the BU umbrella won't actually change that, what it does is it keeps the development community decentralized and adds another source of influence in development direction.

So I see it as a win win. This fits well with the previous BUIP to fund development with funds donated to BU.

tim potter

New Member
Sep 7, 2016
bitcoin cash needs to start with the majority of its implementations running a user-generated block size. right now bitcoin cash uses an 8MB hard limit and this absolutely must change to a soft limit long before it is approached.


Staff member
Dec 16, 2015
@tim potter : While the Bitcoin ABC implementation will join BU in implementing a non-static limit (through policy), I think there is opportunity here for an important practical experiment in emergent consensus.

The experiment I'm talking about is to see how users respond to blocks becoming full when they have the knowledge that they are in control of this limit (this assumes of course that a large majority of the Bitcoin Cash hashpower is also in favor of increasing the block size, otherwise bigger blocks will obviously not happen).

I don't think we've really had this experiment on the legacy Bitcoin chain, because the majority of miners there could not be persuaded to increase the block size via a BU hardfork induced simply by signalling.

8MB is already not a hard limit in the strict sense - it is configurable in most clients and we KNOW the implementations can handle more. For example, it could be easily raised to 16MB (except for XT nodes where I believe it is currently not simply user-configurable).

So, we could try persuading the node operator community to voluntarily double their block size caps to at least 16MB when the average capacity hits 50% , or maybe even 25% if we want to be really pre-emptive.
Then we could see how that long it takes for a sufficient number of nodes to upgrade.

If they do, miners could after some grace period of maybe a month or two (for others to adapt their software limits) slowly raise their mined block past the old limit.

After a new limit has been called out, a new threshold for the next "doubling" could also be agreed and announced (if this kind of consensual upgrade worked once, why shouldn't it work again).

Then we could have a "doubling" and a "halving" in Bitcoin :)

Notes: ABC currently has a real 32MB hard limit through the network message size (but that will of course be lifted in future as deemed safe by further testing). BUcash already has the higher 256MB network message size limit of BU.
Last edited:


Staff member
Aug 29, 2015
@freetrader I agree with everything you said above.

Another way to approach it, ABC and other client developers could just increase the default limit to 16MB, or some much larger limit, in the code they ship. This wouldn't really cause any risk for non-mining nodes, as they would just follow the longest chain.

This would ease the task of "persuading" people to raise the limits of their nodes.

Then it would be up to miners to adjust their limit downward to whatever value they deem prudent at the time, or coordinate to raise their limits when it seems like the wider community is ready for it.