UASF BIP148 Scenarios and Game Theory.

I've already written a lot of articles on BIP148, but recently a lot of speculation has begun to appear on what will happen after the launch of the UASF, scheduled for August 1. In this article, I will describe several possible scenarios for the implementation of BIP148. But first a few caveats:

Anything can happen, right up to the total destruction of Bitcoin in the form in which we know it. One of the parties may not wish to do something for Bitkoyn and do not agree with the role of a merciful loser, but this is an unsafe assumption. We are considering any possible options for action, no matter how 'reprehensible' they may be to someone from the point of view of collateral damage.
I have no intention of trying to cover all possible scenarios. In fact, I will not be able to come up with 10% of the likely scenarios, let alone to work them out. Deeds can be as unpredictable as the inventive people can be, doing them, and this in no way can be underestimated.
You definitely should not expect that everything will happen exactly as I will say here. Understanding the implemented scenario, as a rule, encourages the losing scenario to try to reverse the course of events.
I will consider the scripts in order from simple to complex. In most cases, the more complex the scenario, the more destructive it is for Bitcoin.
In conclusion, I will give a few thoughts on what factors will ultimately matter, but the purpose of this article is not to predict the future, but to show how complex and destructive can be any of the possible scenarios.

For simplicity, I will call the parties 'users' and 'miners.' UASF (user-activated soft fork) BIP148 is initiated, respectively, by 'users'. Of course, these categories are very approximate (there may be users supporting the miners, and vice versa) and are used exclusively for convenience. Bearing in mind all of the above, let's try to look at several scenarios of events that may entail UASF BIP148.

Miners will capitulate
This is probably the easiest to understand scenario. Miners, wishing to avoid the risks associated with soft-fork, decide to support SegWit (SegWit2x, expansion blocks or BIP141) and they manage to consolidate SegWit support until August 1. A simple capitulation on the BIP141 is an ideal scenario for BIP148 supporters, as this means that they will receive SegWit, and they will not have to resort to soft fork.

Securing SegWit via Segwit2x or expansion blocks will also create a situation in which the implementation of BIP148 becomes useless. This will not necessarily be an ideal option for supporters of BIP148, but nevertheless, too, to avoid soft fork. As a result, Bitqoin will support SegWit, so this scenario can be recognized, at least partially, by users, even if it is accompanied by a larger increase in the block size.

Users get the minimum necessary hashing capacity
In this scenario, August 1 users will have something like 0 to 13% hashing capacity of the network as of July 31. The obvious consequence of such a low hashing speed is very slow block formation (1 block / 80 + minutes). This will create two big problems.

The first problem will be that a lot of unconfirmed transactions are generated in the user's blockbuster. The confirmation of transactions will take a very long time, and since the size of the block is limited, the commissions will be very high. The cost and speed of transactions in the user fork can put a lot of pressure on the price in the direction of its decline. This, in turn, can lead to the transition of hashing capacities to the blocking of miners, which will further exacerbate the situation.

The second problem is that many may have doubts about whether SegWit will be activated on the users' blockbuster! The fact is that to activate SegWit it is necessary that 95% of the blocks signal SegWit during the two-week period of network complexity adjustment, which should end before November 15. However, since users will control <13% of hashing capacity, the network complexity adjustment period will take more than 15 weeks. The period from August 1 to November 15 is only about 15 weeks, which puts the activation of SegWit (BIP141) on the user fork in doubt.

And then the obvious question arises: why do you need a fork if it does not lead to activation of SegWit? In the end, will not it be easier to assign a different date for the 'flag-setting day' of UASF - after November 15? The more obvious it becomes that SegWit will not be activated, the less will the hashing powers of reasons remain on the user fork.

Miners do nothing
In this scenario, users will monitor.