On Tue, May 23, 2017 at 2:55 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote: >> Essentially, if we make a potentially very harmful option easy to >> enable for users, we are putting them at risk, so yes, this is about >> protecting users of the base Bitcoin Core implementation. > > In this case, NOT enforcing BIP148 puts users at more risk. Since devs are > divided in opinion, we should at the very least have an option to let users > decide one way or the other.
Well, it's putting users at more risk only if for those users who actively decided to put themselves at risk. I also feel bip148 is rushed and that makes it more risky. I don't want to reiterate points other have made but I don't fully agree with all of them. I prefer the way it is over the way it was (just activating at a given date without forcing mining signaling), but I still think it's rushed and unnecessarily risky (unless activating segwit was urgent, which I think it's not, no matter how much I want it to become active as soon as possible). On the other hand, I support uasf and bip8 to replace bip9 for future deployments, since bip9 made assumptions that weren't correct (like assuming miners would always signal changes that don't harm any user and are good for some of them). Perhaps bip149 can be modified to activate earlier if the current proposal is perceived as unnecessarily cautious. Luke, I've seen you say in other forums that "bip148 is less risky than bip149", but I think that's clearly false. As a reminder, one of my complains about bip109 was precisely that it was also rushed in how fast it could activate. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev