rich1.0npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0njumphttps://nostr.ae📅 Original date posted:2017-05-02 📝 Original message:If the flag day for a wtxid commitment is timed before the current segwit period end, I suspect segwit would activate within the current period. On Tue, Apr 25, 2017 at 2:46 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > On Tuesday 25 April 2017 6:28:14 PM Gregory Maxwell via bitcoin-dev wrote: > > > https://github.com/bitcoin/bitcoin/compare/master... > shaolinfry:uasegwit-f > > > lagday > > > > > > 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. > > FWIW, I disagree in this case. I think given the circumstances, if we are > going to do a UASF for segwit at all, we need a clearly decisive outcome, > which is given by BIP 148. Using the approach in BIP 8 makes sense in many > cases, but in this case, it is liable to simply create a prolonged > uncertainty > where nobody knows the outcome when segwit's rules are challenged by a > malicious miner. > > If BIP 148 fails to achieve widespread support, we could do a BIP 8-based > UASF > with Segwit v2 (along with some other changes I suggested in the other > thread), but I think the tradeoffs right now favour BIP 148 as the best > UASF > deployment. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170502/0cee5728/attachment.html>