UASF: User Activated Soft Fork. Developers add a mandatory rule set to change the node' software, invalidating certain kinds of previously valid blocks after a flag day. This method requires no mining majority to support or activate a chain-split. The UASF proposal intends to make a 51% attack against the blockchain that has the majority of economic activity, and this attack is called a "Wipe Out".

UAHF: User Activated Hard Fork. Developers add a mandatory rule set to change the node software. These changes make previously invalid blocks become valid after a flag day, which do not require a majority of hash power to be enforced. Nodes with the rule set changes will follow this chain irrespective of its hash rate. The UAHF proposal is a peaceful and voluntary departure of different community members who have different opinions or visions, and it is not intended to make an attack against other blockchain(s), even if the UAHF chain has the higher hash rate.

BIP148 node: a Bitcoin node that has implemented BIP148 consensus rule changes.

BIP148 chain: a blockchain that is valid according to the BIP148 consensus rule changes. BIP148 is a kind of UASF.

Original chain: The blockchain that uses the same consensus rules in use today. (May 26th, 2017)

Wipe Out: If the UASF chain is activated and if the UASF chain gains the majority hash rate, then the nodes following the original chain will reorganize and begin to follow the UASF chain. In such an event, a significant number of financial transaction records will disappear. This is a risk that UASF nodes impose on nodes intending to follow the original chain. In contrast, a UAHF does not threaten the nodes following a different rule set with this same risk.

Bit 1: The BIP9 version bit in a block header used to signal for SegWit activation.

Stagnation risk: A blockchain without mining support may suddenly stop being extended, because the economic incentive for miners is low. A minority fork like UASF is under serious risk of permanent stagnation.

Background

On May 24th, 2017, a significant economic majority, more than 80% of the entire hashing power and 80% of transactions' source software or service, of the Bitcoin industry came to an agreement in New York (New York Agreement) on tangible steps to scale Bitcoin in the near future. Representatives of Bitcoin Core declined the invite to attend this meeting. This agreement is the hard work of those who sincerely believe in Bitcoin and those entrepreneurs or investors who have strong financial interest in scaling Bitcoin quickly and unitedly. Bitmain is a supporter of the agreement. We support the agreement and we want to make it happen as soon as possible.

A software project, btc1, which is addressing the New York Agreement, has been under active development and will likely deliver a consensus rule change plan called SegWit2x. The testnet5 for SegWit2x is already alive. Alpha version of the software will be released on June 16th and everything is still on time.

Follow the github here:

https://github.com/btc1

Read a reddit discussion about it here:

https://www.reddit.com/r/btc/comments/6h1wpr/segwit2x_a_summary/

Subscribe the mailing list:

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ng

Despite this agreement, the UASF (BIP148) astroturfing movement continues to get lots of airtime on censored forums, many of which are controlled by single anonymous individuals. Many of the software developers who work in a software project called "Bitcoin Core" are also supporting it. BIP148 poses a significant risk for the Bitcoin ecosystem, so we are preparing a contingency plan to protect the economic activity on the Bitcoin blockchain from this threat.

The New York agreement is also continuously and intentionally sabotaged by a group of software developers working on Bitcoin Core.

We must also be prepared for the disruptive risk that UASF activation will bring to the Bitcoin network. The New York agreement is very conservative and aimed at bringing peace within the Bitcoin community on a simple but artificially escalated scaling issue. If somehow the New York agreement cannot prevent a chain split, we will have to be prepared.

The purpose of this blog post is to announce our UAHF contingency plan for UASF/BIP148.

Why we need a contingency plan against BIP148

According to BIP148, when the chain MTP is at or beyond Tuesday August 1st, 2017 12:00:00 AM GMT (epoch time 1501545600), BIP148 nodes will begin to orphan Bitcoin blocks not signaling Bit 1 at its UASF forking point. This consensus rule change makes the rule set smaller than original chain before BIP148 activation. BIP148 nodes will follow the new BIP148 chain if there is any more than zero hashing power supporting it; if the hash rate backing the chain is 0, BIP148 nodes will find their chain unable to be extended.

If there is hash power supporting the BIP148 chain, it does not need to be a hash rate majority to allow the chain to be extended. Even if there is only one person solving hashes by hands, given enough time the BIP148 chain can be extended by another block. According to the existing hash rate distribution, some well known mining pool operators have stated that they will support the UASF by allowing miners choice, although their total hash rate is not enough to secure a majority. A company hiring many crucial Bitcoin protocol developers controls some of its own small hash rate now according to its CEO. So the Bitcoin network is at a high risk of being split on Aug 1st, 2017.

BIP148 is very dangerous for exchanges and other business. There is no sign of significant economic support behind BIP148 and when it is alive as a blockchain, the economic support would most likely be based on speculation. The mining activity behind a UASF chain may stop without notice, and investors who buy in the BIP148 propaganda may lose all their investment. Any exchanges that decide to support a UASF token after the forking point need to consider the stagnation risk attached to it.

There is no replay protection on a BIP148 chain. Transactions will be broadcast on both chains and users cannot prevent them from being confirmed on both. Exchanges must stop withdrawals and deposits at the forking point for some time, and deploy their own coin splitting methods. If you want to learn more, please read from the References section of this post: Mitigating Bitcoin Forking Risk during Network Upgrade.

The UASF chain presents a risk of the original chain being wiped out. If there is no contingency plan, all economic activity that occurs on the original chain after the UASF forking point will face the risk of being wiped out. This has disastrous consequences for the entire Bitcoin ecosystem. UASF is an attack against users and enterprises who disagree with activating SegWit right now without a block size increase, which is a very important clause in the Hong Kong agreement made by the global Bitcoin community in February, 2016. The chain reorg risk is more significant than imaged, as analyzed by Peter R. in BUIP055,

Rationale for Reorg Protection

The probability (P) that the big-block chain reorgs back to the small-block chain is given by

P = (q/p)^2

where p is the fraction of the hash power mining the big-block chain and q is the fraction of the hash power remaining on the small block chain [2]. With 75% of the hash power supporting larger blocks, the probability of a reorg is 11%.

Protection Plan

This plan is for a User Activated Hard Fork, or UAHF. You can find technical specs here:

https://github.com/bitcoin-UAHF/spec/

The activation time is configurable. We will do the hard fork at 12 hours and 20 mins later than UASF. The epoch time stamp will be 1501590000.

There is "must be big" rule at the fork block. The block size of the fork block must be larger than 1,000,000 Byte. Fork block means the first block which adopt the consensus rule change.

It will accept block of which the size is less than 8MB and we, miners, will soft-limit the block size to less than 2MB.

There will be a soft fork rule added into the protocol to limit the sigops per transaction within 20K.

The block size will not be a part of hard-coded consensus rule for us in the future after the fork block. Miners who generate large blocks will be punished by economic incentives, but not limiting the block size.

There will be replay attack protection that is available for exchanges and wallet developers. You can find the spec here:

https://github.com/Bitcoin-UAHF/spec/blob/master/replay-protected-sighash.md

Bitmain will use some of its own hash rate and work with the developer community to have a contingency plan based on UAHF. We will develop options for miners to voluntarily join us.

Bitmain will mine the chain for a minimum of 72 hours after the BIP148 forking point with a certain percentage of hash rate supplied by our own mining operations.

Bitmain will likely not release immediately the mined blocks to the public network unless circumstances call for it, which means that Bitmain will mine such chain privately first. We intend in the following situations to release the mined blocks to the public (non-exhaustive list):

1. The BIP148 chain is activated and subsequently gains significant support from the mining industry, i.e. after BIP148 has already successfully split the chain;
2. Market sentiment for a big block hard fork is strong, and economic rationale drives us to mine it, for example, the exchange rate is in favor of big-block Bitcoin;
3. If there is already a significant amount of other miners mining a big-block chain publicly and we decide that it is rational for us to mine on top of that chain. In such a case, we will also consider joining that chain and give up our privately mined chain so that the public UAHF chain will not be under the risk of being reorganized.

Once Bitmain starts to mine a UAHF chain publicly, we will mine it persistently and ignore short-term economic incentives. We believe a roadmap including the option to adjust block size will serve users better so we expect it to attract a higher market price in the long term. The economic network will expand faster, and the winning odds will be higher in a highly competitive cryptocurrency market.

We share the same belief with some very early Bitcoiners, that decentralization means that more than 1 billion people in 200 countries are using Bitcoin as a saving currency and payment network, and that it comprises of hundreds of thousands of Bitcoin services, traders, exchanges and software. We do not believe that decentralization means a 1MB block size limit or a responsibility to constrain the block size so that a Raspberry Pi can run a full node while the fee per Bitcoin transaction is higher than the daily income in most developing countries. We believe Bitcoin needs to offer people an alternative to flourish without depending on powerful authorities that charge fees that can be as high as 100$/transaction.

Software Development

Currently, there are at least 3 client development teams working on the code of the spec. All of them want to stay quiet and away from the propaganda and troll army of certain companies. They will announce themselves when they feel ready for it. Users will be able to install the software and decide whether to join the UAHF.

The softwares are expected to be ready before July 1st, and it will be live on testnet by then.

Future Roadmap

If New York agreement activates

We wish that New York agreement will be developed and carried out well. It is the last hope for Bitcoin to scale unitedly in face of the BIP148 threat. We will try our best to deploy and activate it as soon as possible.

If BIP148 activates

Then UAHF will be alive on the same day. The UAHF chain will protect the economic transactions that are under risk of reorganization because of UASF.

Later, we will support the activation of SegWit on the UAHF chain if there is no patent risk associated with SegWit and if the arbitrary discount rate of witness data segment is removed. The weight parameter, which is designed for artificial rates, may need to be deleted and we need to be frank and straightforward in the software code about different limitations on different kind of blocks and other parameters. A SegWit without the artificial discount rate will treat legacy transaction type fairly and it will not give SegWit transactions an unfair advantage. It will also help the capacity increasing effect of SegWit more significantly than with the discounted rate. We will also push for and encourage changes in code, in main block or in extension block, that will make Lightning Network run more safely and reliably than Core's present version of SegWit does.

Extension blocks will be developed as a framework to encourage multiple protocol development teams to bring innovations and capacities into the Bitcoin protocol. Some important but aggressive innovations can be introduced without affecting all Bitcoin users or companies around the world. This will accelerate the innovation of Bitcoin protocol. Sidechains will also be encouraged after the associated security issues have been reviewed by the technical community. Miners are genuinely driven by the hope that Bitcoin will be a success.

We will encourage and help various multi-layer solutions come into production. As a very early investor of RootStock, we identified the potential of another important competing cryptocurrency. We are already working closely with authors of other multilayer solutions.

A new SPV security service by full nodes should be promoted, and further research and libraries that are compatible with the SPV model should also be promoted among wallet developers.

If Bitcoin can combine Bitcoin NG by Emin and Lumino by Sergio together, then a throughput increase of the current Bitcoin network to up to 100x can be easier to achieve with a block size of around 100KB but of a higher block generation frequency. The original Bitcoin NG is a hard fork proposal, but we can soft fork it into the protocol with the extension block framework. At the same time, RootStock, co-founded by the inventor of Lumino, is also trying to implement Lumino on RootStock. Lumino will work perfectly with Lightning Network. It will be interesting to see which implementation will bring Lumino into production first, and in what ways.

Schnorr Signature is also under last stage review.

The diversification of client development shall be promoted. Defensive Consensus concept is under development and will help in the mining industry. Defensive Consensus will help the Bitcoin network work safely while multiple implementations work together.

There are and will be other good innovations in the Bitcoin community that have not been well promoted because of various reasons. We seek to actively work with those innovations.

BUIP056 will be developed to manage the block size issue before a fully automatic and mathematical block size governance model is widely accepted. As evidenced in the past years of debate, miners have proved to be very conservative and willing to work with the wider economic community. The rough roadmap of the block size increase for the next few years is below.

Weak blocks will have to be developed and deployed, before the block size increase reaches 8MB.

References

For other parties in the ecosystem, we recommend detailed research on effects of the UASF. All Bitcoin businesses must be prepared on that day to mitigate or eliminate the risks that UASF carries.

Mitigating Bitcoin Forking Risk during Network Upgrade,https://github.com/digitsu/splitting-bitcoin

If you want to learn more about minority forks, please see Meni Rosenfeld's presentation:

How I learned to stop worrying and love the fork https://fieryspinningsword.com/2015/08/25/how-i-learned-to-stop-worrying-and-love-the-fork/

A Fork in the Road: Must we Choose a Path?  https://www.youtube.com/watch?v=kkJHOpuvQo0&feature=youtu.be

Here is a letter to help you understand the history and full picture of the great debate on Bitcoin scaling, even you are not miners:

An Open Letter to Miners

https://www.reddit.com/r/btc/comments/6befxw/an_open_letter_to_bitcoin_miners_jonald_fyookball/

Here is another blog help you to understand what will happen on the BIP148 fork:

https://medium.com/@jimmysong/uasf-bip148-scenarios-and-game-theory-9530336d953e