[bitcoin-dev] I do not support the BIP 148 UASF

[Gregory Maxwell]

On Thu, Apr 20, 2017 at 6:39 PM, shaolinfry <shaolinfry at protonmail.ch> wrote:
> I agree with much of your thoughts. I originally started working on a
> generalized way to deploy user activated soft forks, in a way that leveraged
> BIP9 to allow for optional faster MASF activation. BIP148 came about as a
> way to satify many people's frustrations about the current segwit
> activation. I have said several times in various places that the proposal
> requires a very high amount of consensus that needs to be present to make
> actual deployment feasible. BIP148 is certainly not what a normal UASF would
> or should look like.
>
> I remain convinced the community very much wants segwit activated and that
> the UASF movement in general has gained a lot of traction. While support for
> BIP148 is surprisingly high, there are definitely important players who
> support UASF in general but do not like BIP148 approach (which you rightly
> point out is a UASF to force a MASF).
[...]
> With BIP8 we could perform a UASF segwit deployment. Due to some
> complexities in the peering logic, I recommend a new deployment with a fresh
> bit that starts right after November 15th (when BIP9 segwit timesout) with a
> BIP8 timeout for April 2018. The code can deployed much earlier. For example
> if code was deployed today, it would give the economy a year to upgrade.
> Activation could still occur safely by MASF any time from now until April
> 2018 (SEGWIT until Nov, then UASEGWIT from Nov until April 2018).
>
> I am still working on the finer implementation details, but you can see a
> rough draft from this diff (which includes BIP8 in the first commit, and the
> proposed bip-segwit-uasf in the second commit).
>
> https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday
>
> I believe this approach would satisfy the more measured approach expected
> for Bitcoin and does not have the issues you brought up about BIP148.

I have not reviewed it carefully yet, but I agree that it addresses my
main concern!  I think this is a much better approach. Thanks.