On Thu, Apr 20, 2017 at 6:39 PM, shaolinfry <shaolin...@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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev