MIME-Version: 1.0
Sender: earonesty@gmail.com
In-Reply-To: <201704251846.10793.luke@dashjr.org>
References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
	<X8k9ENqIddjVtibis1I8dLjHNxIUao0rLwZzpyoCNuWlc6Umgu7huGsbBWGhVY6Jd2XEUOVO8MxkgYKTyaNJ23nJbrE8dz7b8JKTBoE5Ljo=@protonmail.ch>
	<CAAS2fgQzd9J3iNMRfW+x1QnqMFAHx89+GTXEt0SWm6+USZniDA@mail.gmail.com>
	<201704251846.10793.luke@dashjr.org>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 2 May 2017 12:54:35 -0400
Message-ID: <CAJowKg+zdXgeBAmY4WhW-P3WWfqze7G+B3AAwxxVtKeTsoB81g@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=94eb2c07cd4609da66054e8d65c7
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
Precedence: list

--94eb2c07cd4609da66054e8d65c7
Content-Type: text/plain; charset=UTF-8

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--94eb2c07cd4609da66054e8d65c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>If the flag day for a wtxid commitment is t=
imed before the current segwit period end, I suspect segwit would activate =
within the current period.<br></div></div></div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Tue, Apr 25, 2017 at 2:46 PM, Luke =
Dashjr via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tuesday =
25 April 2017 6:28:14 PM Gregory Maxwell via bitcoin-dev wrote:<br>
&gt; &gt; <a href=3D"https://github.com/bitcoin/bitcoin/compare/master...sh=
aolinfry:uasegwit-f" rel=3D"noreferrer" target=3D"_blank">https://github.co=
m/bitcoin/<wbr>bitcoin/compare/master...<wbr>shaolinfry:uasegwit-f</a><br>
<span class=3D"">&gt; &gt; lagday<br>
&gt; &gt;<br>
&gt; &gt; I believe this approach would satisfy the more measured approach =
expected<br>
&gt; &gt; for Bitcoin and does not have the issues you brought up about BIP=
148.<br>
&gt;<br>
&gt; I have not reviewed it carefully yet, but I agree that it addresses my=
<br>
&gt; main concern!=C2=A0 I think this is a much better approach. Thanks.<br=
>
<br>
</span>FWIW, I disagree in this case. I think given the circumstances, if w=
e are<br>
going to do a UASF for segwit at all, we need a clearly decisive outcome,<b=
r>
which is given by BIP 148. Using the approach in BIP 8 makes sense in many<=
br>
cases, but in this case, it is liable to simply create a prolonged uncertai=
nty<br>
where nobody knows the outcome when segwit&#39;s rules are challenged by a<=
br>
malicious miner.<br>
<br>
If BIP 148 fails to achieve widespread support, we could do a BIP 8-based U=
ASF<br>
with Segwit v2 (along with some other changes I suggested in the other<br>
thread), but I think the tradeoffs right now favour BIP 148 as the best UAS=
F<br>
deployment.<br>
<br>
Luke<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--94eb2c07cd4609da66054e8d65c7--