MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CAOG=w-saibrGeOSaLFtcFo_D+2Gw4zoNA-brS=aPuBoyGuPCZA@mail.gmail.com>
References: <CAOG=w-saibrGeOSaLFtcFo_D+2Gw4zoNA-brS=aPuBoyGuPCZA@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Sat, 15 Apr 2017 18:50:17 +0000
Message-ID: <CAAS2fgSGNErAHmZCeKr+agnS4YEwf57yAmvv70XzkkqRfvdDig@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=f403043c4d308de507054d390731
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
Precedence: list

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

On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> triggering BIP141 activation, and therefore not enabling the new consensus
> rules on already deployed full nodes. BIP148 is making an explicit choice
> to favor dragging along those users which have upgraded to BIP141 support
> over those miners who have failed to upgrade.
>

I do not follow the argument that a critical design feature of a particular
"user activated soft fork" could be that it is users don't need to be
involved.  If the goal is user activation I would think that the
expectation would be that the overwhelming majority of users would be
upgrading to do it, if that isn't the case, then it isn't really a user
activated softfork-- it's something else.


> On an aside, I'm somewhat disappointed that you have decided to make a
> public statement against the UASF proposal. Not because we disagree -- that
> is fine -- but because any UASF must be a grassroots effort and
> endorsements (or denouncements) detract from that.
>

So it has to be supported by the public but I can't say why I don't support
it? This seems extremely suspect to me.

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

<div dir=3D"ltr">On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitc=
oin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><span style=3D"background-colo=
r:rgba(255,255,255,0)">triggering BIP141 activation, and therefore not enab=
ling the new=20
consensus rules on already deployed full nodes. BIP148 is making an=20
explicit choice to favor dragging along those users which have upgraded=20
to BIP141 support over those miners who have failed to upgrade.<br></span><=
/div></blockquote></div><div class=3D"gmail_quote"><br><div>I do not follow=
 the argument that a critical design feature of a particular &quot;user act=
ivated soft fork&quot; could be that it is users don&#39;t need to be invol=
ved.=C2=A0 If the goal is user activation I would think that the expectatio=
n would be that the overwhelming majority of users would be upgrading to do=
 it, if that isn&#39;t the case, then it isn&#39;t really a user activated =
softfork-- it&#39;s something else.<br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><span style=3D"background-color:rgba(255=
,255,255,0)">On
 an aside, I&#39;m somewhat disappointed that you have decided to make a=20
public statement against the UASF proposal. Not because we disagree --=20
that is fine -- but because any UASF must be a grassroots effort and=20
endorsements (or denouncements) detract from that.</span></div></blockquote=
><div><br></div><div>So it has to be supported by the public but I can&#39;=
t say why I don&#39;t support it? This seems extremely suspect to me.</div>=
<br><div>=C2=A0</div></div></div></div>

--f403043c4d308de507054d390731--