We demand rigidly-defined areas of doubt and uncertainty!Douglas Adams, the Hitchhiker's Guide to the Galaxy

Everything you need to know about BIP148, UASF, Segwit, and the 1st of August

12th Jul 2017

As most Bitcoin users will be aware by now, Bitcoin nodes enforcing BIP148 will activate Segwit via a soft fork on the 1st of August. This has the potential to cause quite a lot of disruption, and you should work out in advance what you intend to do.

This article is intended to both help you work out what you intend to do, and to make clear what we intend to do.

(TL;DR: We're running BIP148, but we expect Segwit to be activated before the 1st of August).


Segwit: Segregated Witness. A proposal to improve Bitcoin transaction throughput, fix transaction malleability, and price block space more efficiently by separating signatures from transactions. Originally intended to activate once 95% of miners are signalling support for it.

Soft fork: An update to Bitcoin's consensus rules that is backwards-compatible: all new blocks that conform to the soft fork rules will still be valid under the old rules, but not all blocks that are valid under the old rules will be valid under the soft fork rules.

Hard fork: An update to Bitcoin's consensus rules that is not backwards-compatible. New blocks conforming to the hard fork rules will not necessarily be valid under the old rules.

UASF: User-activated soft fork. A soft fork triggered by users deciding amongst themselves that they will change the consensus rules via a soft fork.

BIP148: Bitcoin Improvement Proposal 148. A proposal to use a soft fork on the 1st of August to activate Segwit without reaching the 95% miner signalling rate.

Chain split: When some network participants follow one set of consensus rules, and other participants follow another set of rules, a chain split occurs and the two sets of participants can no longer transact with one another.

NYA: The New York Agreement. A bunch of people got together and agreed to develop and run some software that would activate Segwit and increase the block size.

Segwit2x: The proposal that the NYA came up with: to activate Segwit at 80% miner signalling, followed by a hard fork to a 2MB block size.

Replay attack: In the event of a chain split, many or most transactions on either chain will also be valid transactions on the other chain, and anybody on the network can (maliciously or accidentally) replay transactions from either chain to the other chain.

Replay protection: It is sometimes possible to implement protection against a replay attack. Unfortunately, neither BIP148 nor Segwit2x includes replay protection.

Reorg: Blockchain reorganisation. When a new chain is found that has more proof of work than the current best chain, the Bitcoin client starts following the new chain instead, potentially reversing all of the transactions that happened after the point where the chains split. In the event of a soft fork, clients not following the soft fork rules are at risk of a reorg to the soft fork chain (because it is still valid under legacy rules), but clients following the soft fork rules are at no risk of a reorg to the legacy chain (because it is not valid under the soft fork rules).

What's going to happen?

If Segwit gets activated before the 1st of August (either by the original 95% signalling threshold or by Segwit2x), no chain split occurs, and there is no disruption. We expect miners to activate Segwit before the 1st of August in order to avoid UASF-related disruption, although it's by no means a sure thing.

If Segwit does not get activated before the 1st of August, BIP148 nodes split from the rest of the network, and there will likely be a period of uncertainty where it's not clear which chain will "win".

Since BIP148 is a soft fork, the BIP148-conforming chain will be valid on legacy nodes, but the legacy chain will not be valid on BIP148 nodes.

If both the BIP148 chain and the legacy chain both appear to be proceeding, it is likely that the legacy chain will lose due to the reorg risk: any time the BIP148 chain overtakes the legacy chain, all of the legacy clients will reorg on to the BIP148 chain, reversing all transactions that happened since the point that the chains split, which would be potentially hundreds of blocks.

If the BIP148 chain loses, some proponents of BIP148 intend to hard fork to change the proof-of-work algorithm so that the BIP148 chain can continue. We do not intend to follow such a change unless it has clear community consensus, but it is a possibility.

What is SMS Privacy going to do?

We are running a BIP148-enforcing node. If Segwit does not activate before the 1st of August, we will follow the BIP148 chain and activate Segwit via a soft fork.

Even in the event of a chain split, we aim to continue accepting payments, but only on the BIP148 chain. If it becomes clear that the BIP148 chain is not going to succeed, then we will revert to the legacy chain and communicate this to customers (and no customers will lose any deposits they made on the BIP148 chain).

What do customers need to do?

Before the 1st of August (and on or after the 1st of August if no chain split occurs because Segwit is already activated) you can continue to send payments as normal.

If it looks like a chain split is likely to occur, we recommend topping up your balance before the 1st of August to avoid the uncertainty. If a chain split occurs on the 1st of August, and you desperately need to make a payment that day, send it on the BIP148 chain.

If a chain split occurs on the 1st of August and you do not desperately need to make a payment that day, we recommend simply waiting it out to see which chain wins.

If after the 1st of August, it becomes apparent that the legacy chain is "winning" and the BIP148 chain is losing, we will revert to running Bitcoin Core and will once again be accepting payments on the legacy chain.

What if customers send a payment on the legacy chain instead of the BIP148 chain?

Due to the lack of replay protection, it is likely that some payments made on the legacy chain will be replayed on the BIP148 chain and vice versa, in which case the payment will show up anyway.

If the payment shows up on the legacy chain and not on the BIP148 chain, contact us and we'll work with you to resolve it (most likely by either returning the money or crediting your account with the appropriate balance).

What if neither chain wins and both chains continue to exist?

This is super unlikely to happen.

In the event that either chain has a substantially lower hash rate than the other, that chain is severely degraded until the next difficulty adjustment. The difficulty adjustment is 2016 blocks, which would take 2 weeks under normal conditions, but would take 10x that long if the chain has only 10% of the hashrate, and 100x as long with only 1% of the hashrate. Such a chain would be pretty unusable.

In the event that neither chain has a substantially lower hash rate than the other (i.e. they're quite evenly matched), the BIP148 chain is likely to win simply because of the reorg risk.


We're running BIP148. You don't have to run BIP148. Hopefully Segwit will get activated before the 1st of August simply due to the threat of BIP148. If this doesn't happen, you won't be able to pay after the chain split until BIP148 has clearly lost and we revert to the legacy chain, or BIP148 has clearly won and you reorg to the BIP148 chain.

This uncertainty is not ideal, and hopefully the disruption will be avoided. The best any of us can do is analyse the situation, communicate our intentions clearly, and hope for the best.

Bitcoin will continue long in to the future, regardless of what happens on the 1st of August, and the future looks as bright as ever.

If you have any questions, please get in touch: jes@smsprivacy.org.

James Stanley
SMS Privacy

SMS Privacy is a project by James Stanley.
Available as a Tor hidden service at smspriv6fynj23u6.onion.
Please send bug reports, feature requests, comments, concerns, etc. to jes@smsprivacy.org.
As featured on Indie Hackers.