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.
sourced from uasf.saltylemon.org
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.
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.
| Company | Category | Support Type | ANN. |
|---|---|---|---|
| Abra | Worldwide payments | Support | proof |
| Altana | Wallet | Support | proof |
| Azteco | Consumer Bitcoin | Support | proof |
| Bitcoin Embassy | Education | Support | proof |
| Bitcoin India | Miner | Support | proof |
| BitCoinReminder | Tool | Support | proof |
| Bitfury | Miner | Support | proof |
| BitKong | Casino | Support | proof |
| Bitonic (BL3P) | Exchange | Support | proof |
| BitPay | Payment processor | No support | proof |
| Bitrated | Identity & consumer protection | Support | proof |
| Bitrefill | Exchange | Support | proof |
| Bittylicious | Exchange | Support | proof |
| Bitvest | Gambling | Support | proof |
| Blockchain Academy | Education | Support | proof |
| Blockonomics | Explorer | Support | proof |
| Bustabit | Casino | Interest | proof |
| Bylls | Service | Support | proof |
| Ciphrex | Wallet/Development Stack | Support | proof |
| CoinGate | Payment Processor | Support | proof |
| Coinkite | Hardware/Software | Support | proof |
| Coinomi | Multi-currency Wallet | Support | proof |
| Darknet Heroes League | Dark Net Marketplace | Support | proof |
| Échange de Montréal | Exchange | Support | proof |
| Electrum | Wallet | Support | proof |
| Freedom Node | Education | Support | proof |
| inbitcoin | Payment Processor | Ready | proof |
| JoinMarket | Mixer | Support | proof |
| LightningASIC | Miner | Support | proof |
| MegaDice | Gambling | Support | proof |
| Microsoft | Decentralized Identity dpt. | Support | proof |
| MojBitcoin | ATM Operator | Support | proof |
| Mycelium | Wallet | Ready | proof |
| Prasos | Bitcoin broker | Support | proof |
| Samourai Wallet | Wallet | Support | proof |
| Satoshi Counter | Broker | Support | proof |
| Satoshi Portal | Financial services | Support | proof |
| Stampery Inc. | Timestamping | Support | proof |
| Simple Bitcoin Wallet | Wallet | Support | proof |
| Trezor | Hardware Wallet | Ready | proof |
| Trezor Web Wallet | Hardware Wallet | Ready, in beta | proof, implemented |
| Vaultoro | Bitcoin & gold exchange | Support | proof |
| Walltime | Exchange | Support | proof |
| Yogh | Explorer | Support | proof |
Add your business here by creating a pull request (must include public announcement link)
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.
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
Freedom Node Electrum Server for UASF: bitcoin.freedomnode.com port 50001
Prior to August 1st, 2017, miners should either:
- Update their node software to a BIP148-enforcing version; or
- Run a BIP148 border node to filter out invalid blocks, and update their existing mining software to produce blocks with version 1 bit enabled, to vote for Segwit activation
BIP148 requires support from the economic majority, particularly exchanges and wallets. If this does not occur, node software supporting BIP148 should not be run after August 1st as it will cause a chain split leading to the abandonment of BIP148. There are strong economic incentives in the Bitcoin system for nodes to cooperate and remain in consensus to prevent chain splits. If the economic majority is signalling as of August 1st, miners have many incentives to follow along. Not following along would make it difficult to sell coins mined after August 1st as the blocks would not be accepted by the economic majority. Essentially, miners would be producing an altcoin not recognized by users and exchanges, making them less useful and in lower demand.
Some miners could opt to ignore the BIP148 rule and attempt to split the chain, but this would require a majority of miners who would be out of consensus from the rest of the economic majority.
If a majority of hash power follows BIP148, all nodes will follow the chain regardless of if they are running BIP148. Non-compliant blocks will be orphaned. All SegWit nodes will eventually activate SegWit.
If a minority of the hash power (under 51%) follows BIP148, nodes running BIP148 will be fine, but those not running BIP148 will be out of consensus with the rest of the economy. In this scenario, the more of the economy that runs BIP148, the better. Miners will find it difficult to sell their coins leading economically motivated miners to start enforcing BIP148.
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.
The best way to show support is to champion it through social media (Twitter, Facebook, etc...) and petition businesses and wallets to support it. Many users have already installed (or upgraded to) Bitcoin Core UASF BIP148 and this is best option for those who use own nodes to send and receive bitcoin.
Users who cannot upgrade existing Bitcoin Core can change their node's user agent string to include BIP148, but such nodes will have to be upgraded to UASF BIP148 in order to be able to function on the BIP148 chain after August 1.
To signal #BIP148 on Linux on your node without a software change:
echo "uacomment=UASF-SegWit-BIP148" >> ~/.bitcoin/bitcoin.conf && bitcoin-cli stop && sleep 5 && bitcoind
To signal #BIP148 on Windows, you can edit the shortcut for Bitcoin as follows:
N.B. This will not enforce UASF on your node; it will only signal that you support it at this stage. If you intend to use BIP148 to send and receive bitcoin after BIP148 activation, make sure to install Bitcoin Core UASF BIP148 prior to August 1, 2017.
Signed binaries can be downloaded here. To build from source, follow the instructions below.
First, install all necessary dependencies which are mentioned in the official Bitcoin build instructions:
You can also use the gitian build system, which is a bit more complex, but generates deterministic builds which can then be verified by the signatures of some core developers:
| Source | Link |
|---|---|
| Gitian | https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md |
| Signatures | https://github.com/UASF/gitian.sigs |
The next step is to clone the UASF repository:
git clone https://github.com/UASF/bitcoin.git bitcoin_bip148
cd bitcoin_bip148
git checkout 0.14-BIP148
and then continue with the default compiling steps which are mentioned in the official build instructions:
./autogen.sh
./configure
make
make install # optional
Finished - you can run now your UASF BIP148 node.
Yes. There are two slack channels on slack.bitcoincore.org:
- #UASF for general talk
- #UASF-SUPPORT for people who want to setup their BIP148 node
Feel free to join, we are always happy about people which are interested and would like to discuss with us!
No. BIP148 will occur as long as any users support it. Many users have committed to running BIP148 regardless of consequences, therefore it cannot be cancelled.
No. Users that decide to enforce the new rules will only follow blocks that conform to the existing rules which will in turn cause miners to activate SegWit. A UASF could be enforced by any number of economic nodes, although hash power may only choose to follow such rules if there was significant economic weight behind it.
Soft forks rely on the economic incentives of the majority of miners and economic actors to reject invalid blocks based on the new ruleset. Since the new BIP148 rules are a stricter set than the old rules, any chain split means the chain with the old rules would be in danger of being wiped out. If the majority of miners enforce the new ruleset, all blocks produced that are invalid in the new ruleset will become orphaned. This economic incentive pushes miners to enforce the new rules. A UASF uses similar economic incentives. If the majority of hashing power enforces the new rules, chain splits remain temporary as with a solely miner enforced soft fork.
If the majority of hashpower does not enforce the rules, a chain split would occur. If there is a greater demand for the blocks produced by the BIP148 miners, then profit-driven miners would eventually flock to this chain, leading to the orphaning of the pre-soft-fork chain. If the demand is less for the soft-fork chain, then both chains may co-exist indefinitely.
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.
Miner activated soft forks are a convenient shortcut to activating soft forks because it allows the changes to activate before a significant portion of the economy upgrades. The signalling process is just to coordinate when a supermajority of hashrate has upgraded, nodes can then activate and begin enforcing the new rules. It was never intended to be a vote although it has an unintentional veto where a small amount of hash power can hold up the process.
Ultimately consensus is decided by the economic nodes in the ecosystem since they validate the chain and engage in economic activity. Ultimately even miner activated soft forks (MASF) are enforced by the nodes. The miners simply trigger activation in the nodes.
A UASF forgoes the need for miner signalling because economic nodes are given more time to upgrade to the new rules and begin enforcing in the future. A UASF in no way impedes the operation of non-upgraded miners, nor disenfranchises them in any way. Miners always have the freedom to produce blocks following any rules they wish, but if they fall out of consensus with the economic nodes, their blocks will be rejected by the network.
Miners can always attack any chain at any time, but must do so by exerting real opportunity costs - they have to stop mining for profit. There are two main types of attacks. The first attack would be mining empty blocks. In the case of a chain split, this kind of attack would actually be beneficial - it would allow the chain to reach a difficulty retarget period faster. The second kind of attack is an active 51% attack on the chain. This type of attack requires a majority of hash power colluding to orphan valid blocks that have been mined. This kind of attack is always possible in Bitcoin, but can be defeated by changing the Proof of Work. These types of attacks are discouraged due to economic incentives- there typically is more to gain by cooperating than attacking.
Both sides of a chain split will produce slower than normal blocks until the difficulty period resets. This time will be dependent on the allocation of hash power. For example, if 25% of the hash power was left on a chain, it would take four times as long (8 weeks) to reach a retarget period. After this period, blocks would return to 10 minutes. Congestion would also likely result in higher fees, which would encourage more mining on this chain and faster blocks until equilibrium would be reached.
This will depend on what type of wallet you use. In the case of a wallet using a centralized service's nodes, make sure the nodes their service uses are upgraded. In the case of something like Electrum, make sure the Electrum server you are using is upgraded. Ultimately, any non-fully validating wallet will derive information about balances from a fully validating node. You must take whatever steps you have to in order to ensure your wallet is connected to an upgraded BIP148 nodes.
Successful User Activated Soft Forks require a strong consensus from the economy to be successful. BIP148 also is subject to changes as it is reviewed, so some minor details may change before it is ready. Please check regulary to be up to date with the latest version.
You can find software here - be sure to verify the signtures:
| Operating system | Signatures |
|---|---|
| win64-setup-unsigned.exe | Signatures |
| win64.zip | Signatures |
| win32-setup-unsigned.exe | Signatures |
| win32.zip | Signatures |
| Ubuntu | PPA provided by Luke-Jr |
| osx64.tar.gz | Signatures |
| osx-unsigned.dmg | Signatures |
| x86_64-linux-gnu.tar.gz | Signatures |
| i686-pc-linux-gnu.tar.gz | Signatures |
| aarch64-linux-gnu.tar.gz | Signatures |
| arm-linux-gnueabihf.tar.gz | Signatures |
| Source Code |
BIP8 is a modification to BIP9. BIP9 was the deployment mechanism for soft forks in the past that relied on miners signalling 95% readiness for activation. It was successfully used to activate BIP65 (OP_CHECKLOCKTIMEVERIFY) and BIP68/BIP112/BIP113 (CHECKSEQUENCEVERIFY/Median Time). BIP9 allows for upgrades to the system whenever a supermajority of miners are ready to enforce the changes, allowing for faster upgrades than a UASF may allow. Every 2016 blocks, if 95% of those blocks signalled readiness for the proposed change, the soft fork enforcement would become mandatory in 2016 blocks. Each change is given a fixed timeframe to achieve this activation, such that any change that is not activated may have its bit reused. Proposals that do not achieve activation expire at the end of their time period, but may be renewed if there is sufficient interest.
BIP8 modifies BIP9 to automatically convert into a UASF at the end of its activation time. This avoids the problem of a miner veto while still allowing miners to begin enforcing the rules sooner than a pure UASF would allow. Once the final period completes after the timeout period, the rules become mandatory, regardless of signalling.
There was a proposal made by Shaolinfry to use BIP8 to deploy SegWit. The proposal would set a new version bit for deployment after the current proposal would expire, and would lock-in in April 2018. Miners would still be able to activate SegWit prior to the this date, but failure to activate would result in a mandatory lock-in.
Unlike BIP148, this proposal would not require miners to signal version bits for SegWit or create SegWit blocks. The only requirement for miners is to not build on top of blocks that are invalid under the SegWit rules.
Contribute to this document here github.com/OPUASF/UASF