MIME-Version: 1.0
In-Reply-To: <CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
Date: Mon, 28 Sep 2015 13:47:25 +0100
Message-ID: <CAE-z3OVAVdOPAypOA0gndcRGbd74TChtsLW6u77Muxk6DJK16g@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113da7c87326910520ce19e0
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

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

On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 1) Drop the "everyone must agree to make changes" idea that people here
> like to peddle, and do it loudly, so everyone in the community is correctly
> informed
>

There never was a rule that soft-forks require total consensus.  It is
desirable but not mandatory.

A majority of miners can inherently implement a soft fork against the
wishes of the rest of the users.

Merchant/exchange/user checkpointing is the defense and therefore is a
perfectly valid response to miners taking such an action.  If a soft fork
is opposed by a large section of the users, then threatening (and
implementing) a checkpoint is the correct response.

No group can force through a hard fork, it inherently requires buy-in from
a large portion of the userbase.  That is where the "total consensus"
requirement comes from.  Naturally, absolute total consensus isn't actually
required but you do need very large consensus and also consensus across the
various sub-groups.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Sep 28, 2015 at 11:48 AM, Mike Hearn via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
>1) Drop the &quot;everyone must agree to make changes&quot; idea that peop=
le here like to peddle, and do it loudly, so everyone in the community is c=
orrectly informed</div></div></blockquote><div><br></div><div>There never w=
as a rule that soft-forks require total consensus.=C2=A0 It is desirable bu=
t not mandatory.=C2=A0 <br><br></div><div>A majority of miners can inherent=
ly implement a soft fork against the wishes of the rest of the users.<br><b=
r></div><div>Merchant/exchange/user checkpointing is the defense and theref=
ore is a perfectly valid response to miners taking such an action.=C2=A0 If=
 a soft fork is opposed by a large section of the users, then threatening (=
and implementing) a checkpoint is the correct response.<br><br></div><div>N=
o group can force through a hard fork, it inherently requires buy-in from a=
 large portion of the userbase.=C2=A0 That is where the &quot;total consens=
us&quot; requirement comes from.=C2=A0 Naturally, absolute total consensus =
isn&#39;t actually required but you do need very large consensus and also c=
onsensus across the various sub-groups. <br></div></div></div></div>

--001a113da7c87326910520ce19e0--