BIP148 Activation
01 August 2017
What is a UASF?
UASF stands for User Activated Soft Fork. It’s a mechanism where the activation time of a soft fork occurs on a specified date enforced by full nodes, a concept sometimes referred to as the economic majority. A UASF requires a lot of industry support and coordination, which is good practice for eventual hard forks which requires even more industry coordination. In the past, a UASF was successfully carried out to activate the P2SH soft fork (BIP16). The UASF concept was combined with SegWit activation in the BIP148 proposal which can be found here: github.com/bitcoin/bips/blob/master/bip-0148.mediawiki.
What is a MASF?
MASF stands for Miner Activated Soft Fork. It’s a mechanism by which miners trigger activation of soft forks when a majority signals the readiness to upgrade. This allows for a faster activation time for the soft fork, leaving full nodes to upgrade at their leisure. This method is a tradeoff, because it puts trust in the hash power actually enforcing the new rules. If they do not, it can cause various invalid chains on the network. For example, this was the case with BIP66, when hashpower indicated they had upgraded when in fact more than 50% had not. The other tradeoff is that the method allows a small number of hash power to veto activation of the soft fork for everyone on the network. Overall, if everyone cooperates, this method is very convenient and has been used to successfully activate multiple soft forks in the past such as BIP65 CLTV and BIP112 CSV.
What is BIP148?
BIP148 is a UASF that is designed to cause the existing SegWit MASF deployment to cause activation in all existing SegWit capable node software (which currently is 80% of the network nodes). How does BIP148 Work? From August 1st, 2017, miners are required to signal readiness for SegWit by creating blocks with the version bit 1. This will cause all SegWit ready nodes, which make up over 80% of the network, to activate and begin enforcement. Link for reference: luke.dashjr.org/programs/bitcoin/files/charts/segwit.html. Miners must also check blocks prior to their own and ensure that they also signal for SegWit, and only build on those blocks.
Why BIP148 and not a direct flag day UASF for Segwit?
To be clear, BIP148 is a soft fork that requires miners to activate the existing SegWit deployment. This is not the standard for UASF because normally nodes would just begin enforcement on a given “flag day”. However, almost 80% of the network has already upgraded to SegWit capable node software, in anticipation of miner triggered activation. A new “SegWit UASF” deployment would require all nodes to upgrade again which will take considerable time. For this reason, the shortened route to SegWit activation is to require blocks to signal for SegWit activation. In general, the block signalling mechanism is only supposed to be a coordination method that makes accelerated activation possible. In 2012, P2SH was activated by UASF with a simple flag day.
BIP148 was created to avoid having to force most users to upgrade their software. A vast majority of the nodes currently deployed are aware of the BIP9 signalling for SegWit. BIP148 is designed to motivate miners to signal for SegWit so that it is activated in a way that even users who are not running BIP148 will get the benefits of the activation of SegWit. For more information on the benefits of SegWit, please visit: segwit.org.
What do users need to do to enforce BIP148?
It is recommended that users do not update unless an economic majority commits to updating and users are aware of the risks and mitigations of a failed UASF deployment.
Users aware of the risks and who want to commit should use clients that enforce BIP148. Users that run full nodes would upgrade to one that enforces BIP148, or run their node behind an upgraded border node. Users of light clients (like mobile wallets) should check with each vendor to see their support for BIP148. We plan on documenting any public responses from wallets regarding BIP148 support. Satoshi Portal Electrum Server for UASF: 158.69.102.114 port 50002
Is BIP148 a hard fork?
No, BIP148 isn’t a hard fork. A hard fork is often confused with a chain split. A hard fork is a type of chain split where the rules are loosened to allow previously disallowed blocks or transactions. A soft fork is a tightening of the rules. A soft fork will result in a converged chain if the majority of hashpower enforces its rules. For a more detailed explanation of types of forks and chain splits, see Chain Splits and Resolutions.
Why was the date of August 1, 2017 chosen?
Because BIP9 is time based, BIP148 needs to account for the possibility for some of the hash power to exit (eg. to mine another fork) which would make block intervals longer. The August 1st date allows for the economic majority to successfully activate SegWit. Theoretically, if the hashpower drops by up to 85%, it might take up to 13 weeks to complete an activation period. In this scenario, SegWit will still activate for all BIP148 compliant nodes.
[Source]
Segwit2x hard Fork
late oct to mid nov
Segwit2x chain — 100% blocks signalling for Segwit
Segwit2x attempts to create the very same type of chain as the UASF solution by doing the exact same thing — orphaning blocks that do not signal for Segwit using bit 1. The differences come about in the way the solution itself is activated.
In the UASF code a simple activation date is used. With Segwit2x a more complex method is used. Miners initially show their intent to support the solution (as is occurring at the present time) and then on July 21st they need to actually begin signalling for its activation.
Miners show their intent to support the ‘New York Agreement’ — the meeting where Segwit2x was conceived — by adding ‘NYA’ in the coinbase text of any blocks that they mine. This in itself does nothing to trigger anything within the Segwit2x code and is intended purely to be a publicly visible show of intended support.
The actual signalling for the activation of Segwit2x is due to begin on July 21st. In a similar fashion to the BIP 9 signalling for the activation of Segwit itself, a version bit is used to activate Segwit2x. In order for Segwit2x to activate it requires that at least 80% of blocks over a short 336 block period signal bit 4. There should be between 3 and 4 of these short periods between July 21st and August 1st. As the last period needs to be the LOCKED_IN period, there will be 2–3 actual periods where the 80% threshold can be met. The very existence of the UASF and its ‘set in stone’ activation date has undoubtedly been the driving force behind Segwit2x’s recent reduced confirmation window update.
It is worth noting that Segwit2x itself does not set bit 4 — this will be done independently by the miners as part of their mining workflow in line withexisting guidelines. Coordinating the design, implementation, build, testing and deployment of Segwit2x in accordance with its aggressive project timeline is a sizeable task in itself and falls under the remit of the Segwit2x Working Group.
Once miners start running Segwit2x on the main chain it will look for the bit 4 ‘flag’, measure signalling against the 80% threshold and respond accordingly.
Once activated, the Segwit2x code will follow the exact same logic as the UASF code, in that it will start orphaning blocks that do not signal for Segwit using bit 1.
Because the signalling is done purely by miners in the blocks they create, users and nodes will simply follow the longest valid chain as normal. Users do not need to run the Segwit2x code.
Miners running Segwit2x will add to the chain, extending it with blocks that all count towards BIP 9’s 95% activation threshold. It will have created a chain where 100% of the blocks signal readiness for Segwit.
[Source]