MIME-Version: 1.0
In-Reply-To: <EE96B281-464B-4B17-BAF6-25F3E30AB238@gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<CALqxMTFEme9gYHTAVVLtFc4JCK4hoBLXEhMCRdEXK9cWso_pUA@mail.gmail.com>
	<CA+w+GKQ8xos6S_BBMqZy6wieFCG=eNxahKXrx3mVKuZcxzjruw@mail.gmail.com>
	<4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com>
	<CA+w+GKSm2Np92+NA77nNMB5LqSyO0=W8dziiMtGO=Jf+7KidHQ@mail.gmail.com>
	<C0E61EA6-76BE-45E0-8983-A3BC26CC64CF@gmail.com>
	<CA+w+GKS74iF2FNuHtds=3R9++sx9ZP-0tcq_j5XqZw9-6uHkVQ@mail.gmail.com>
	<EE96B281-464B-4B17-BAF6-25F3E30AB238@gmail.com>
Date: Tue, 29 Sep 2015 14:02:59 +0200
Message-ID: <CA+w+GKTK=ceY_-e_upVJfJ3uRdGnHwTxHwAGUpLaK4VVNZgr2A@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a1141fb906567310520e19859
Cc: Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

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

>
> Other than the fact that doing this as a soft fork requires an extra
> OP_DROP, how would doing this as a hard fork make any difference to SPV
> clients? If, as others have suggested, all clients warn the user on
> unrecognized nVersion
>

All clients do *not* do this. Why would they? What action would they take?
Try and simulate a hard fork in some complicated roundabout manner? Why not
just do the real thing and keep things simple?


> and make unknown noops nonstandard
>

They are already non-standard. That change was made last time I brought up
the problems with soft forks. It brought soft forks that use OP_NOPs a bit
closer to the ideal of a hard fork, but didn't go all the way. I pointed
that out above in my reply to Peter's mail.

So to answer your question, no, it wouldn't satisfy my concerns. My logic
is this:

Hard forks - simple, well understood, SPV friendly, old full nodes do not
calculate incorrect ledgers whilst telling their users (via UI, RPC) that
they are fully synced. Emphasis on simple: simple is good.

Soft forks - to get the benefits of a hard fork back requires lots of extra
code, silently makes IsStandard() effectively a part of the consensus rules
when in the past it hasn't been, SPV unfriendly. Benefits? As far as I can
tell, there are none.

If someone could elucidate *what* the benefits actually are, that would be
a good next step. So far everyone who tried to answer this question gave a
circular answer of the form "soft forks are good because they are soft
forks".

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>Other than the fact that doing this as a so=
ft fork requires an extra OP_DROP, how would doing this as a hard fork make=
 any difference to SPV clients? If, as others have suggested, all clients w=
arn the user on unrecognized nVersion</div></blockquote><div><br></div><div=
>All clients do <i>not</i> do this. Why would they? What action would they =
take? Try and simulate a hard fork in some complicated roundabout manner? W=
hy not just do the real thing and keep things simple?</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div> and make unknown noops nonstandard</d=
iv></blockquote><div><br></div><div>They are already non-standard. That cha=
nge was made last time I brought up the problems with soft forks. It brough=
t soft forks that use OP_NOPs a bit closer to the ideal of a hard fork, but=
 didn&#39;t go all the way. I pointed that out above in my reply to Peter&#=
39;s mail.</div><div><br></div><div>So to answer your question, no, it woul=
dn&#39;t satisfy my concerns. My logic is this:</div><div><br></div><div>Ha=
rd forks - simple, well understood, SPV friendly, old full nodes do not cal=
culate incorrect ledgers whilst telling their users (via UI, RPC) that they=
 are fully synced. Emphasis on simple: simple is good.</div><div><br></div>=
<div>Soft forks - to get the benefits of a hard fork back requires lots of =
extra code, silently makes IsStandard() effectively a part of the consensus=
 rules when in the past it hasn&#39;t been, SPV unfriendly. Benefits? As fa=
r as I can tell, there are none.</div><div><br></div><div>If someone could =
elucidate <i>what</i>=C2=A0the benefits actually are, that would be a good =
next step. So far everyone who tried to answer this question gave a circula=
r answer of the form &quot;soft forks are good because they are soft forks&=
quot;.</div></div></div></div>

--001a1141fb906567310520e19859--