MIME-Version: 1.0
From: Mark Friedenbach <mark@friedenbach.org>
Date: Sat, 15 Apr 2017 09:42:25 -0400
Message-ID: <CAOG=w-saibrGeOSaLFtcFo_D+2Gw4zoNA-brS=aPuBoyGuPCZA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113a673cb2a5e3054d34bb72
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
Precedence: list

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

Greg,

If I understand correctly, the crux of your argument against BIP148 is that
it requires the segwit BIP9 activation flag to be set in every block after
Aug 1st, until segwit activates. This will cause miners which have not
upgrade and indicated support for BIP141 (the segwit BIP) to find their
blocks ignored by UASF nodes, at least for the month or two it takes to
activate segwit.

Isn't this however the entire point of BIP148? I understand if you object
to this, but let's be clear that this is a design requirement of the
proposal, not a technical oversight. The alternative you present (new BIP
bit) has the clear downside of not 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.

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.

Mark Friedenbach

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

<div dir=3D"ltr"><span style=3D"background-color:rgba(255,255,255,0)">Greg,=
<br><br>If I=20
understand correctly, the crux of your argument against BIP148 is that=20
it requires the segwit BIP9 activation flag to be set in every block=C2=A0<=
a dir=3D"ltr">after Aug 1st</a>,
 until segwit activates. This will cause miners which have not upgrade=20
and indicated support for BIP141 (the segwit BIP) to find their blocks=20
ignored by UASF nodes, at least for the month or two it takes to=20
activate segwit.<br><br>Isn&#39;t this however the entire point of BIP148? =
I
 understand if you object to this, but let&#39;s be clear that this is a=20
design requirement of the proposal, not a technical oversight. The=20
alternative you present (new BIP bit) has the clear downside of not=20
triggering BIP141 activation, and therefore not enabling 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><br>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.<div class=3D"gmail-yj6qo=
 gmail-ajU"><div id=3D"gmail-:1jd" class=3D"gmail-ajR" tabindex=3D"0"><img =
class=3D"gmail-ajT" src=3D"https://ssl.gstatic.com/ui/v1/icons/mail/images/=
cleardot.gif"><br></div><div id=3D"gmail-:1jd" class=3D"gmail-ajR" tabindex=
=3D"0">Mark Friedenbach<br></div></div></span></div>

--001a113a673cb2a5e3054d34bb72--