MIME-Version: 1.0
In-Reply-To: <20150928144318.GA28939@savin.petertodd.org>
References: <20150927185031.GA20599@savin.petertodd.org>
	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
	<20150928132127.GA4829@savin.petertodd.org>
	<CA+w+GKTCZDNVJ-XEmsCAWGXUV3xOzVYmqMQYm0x+ihyYWQN0Gg@mail.gmail.com>
	<20150928142953.GC21815@savin.petertodd.org>
	<CA+w+GKTUz2eVJOpixSebWiQ59ovoELNhsZWSsbLHXWqk2eCn0A@mail.gmail.com>
	<20150928144318.GA28939@savin.petertodd.org>
Date: Mon, 28 Sep 2015 16:51:22 +0200
Message-ID: <CA+w+GKSuO2v+92hJUckcYdHcjkPVNg4opDL98yygGp-gqB9Jtg@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bdc09f6b8d8bd0520cfd4d3
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

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

>
> Ok, so again, if that's your security criteria, what's the issue
> with soft-forks?


Please read my article as it's all explained there.

But to reiterate: the risk is that miners will build invalid blocks on top
of the best work chain, instead of an ignored lower work side chain. This
opens users to payment fraud. With a hard fork, all the blocks by miners
that aren't checking all the rules anymore get neatly collected together on
a side chain after the split, and wallets all know how to ignore that chain.

Yes, you made OP_NOPs be non-standard. So out of the box, miners won't
create invalid blocks, as long as they're running Core past that version.
But this makes the IsStandard function very much like a part of the
consensus rules, as bypassing it can result in invalid blocks being
created. Miners have always understood that they can modify this function,
or even bypass it entirely, without affecting the validity of their blocks.
And some miners do exactly that.

So I'll repeat the question that I posed before - given that there are
clear, explicit downsides, what is the purpose of doing things this way?
Where is the gain for ordinary Bitcoin users?

--047d7bdc09f6b8d8bd0520cfd4d3
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">Ok, so again, if that&#39;s your security criter=
ia, what&#39;s the issue with=C2=A0soft-forks?</blockquote><div><br></div><=
div>Please read my article as it&#39;s all explained there.</div><div><br><=
/div><div>But to reiterate: the risk is that miners will build invalid bloc=
ks on top of the best work chain, instead of an ignored lower work side cha=
in. This opens users to payment fraud. With a hard fork, all the blocks by =
miners that aren&#39;t checking all the rules anymore get neatly collected =
together on a side chain after the split, and wallets all know how to ignor=
e that chain.</div><div><br></div><div>Yes, you made OP_NOPs be non-standar=
d. So out of the box, miners won&#39;t create invalid blocks, as long as th=
ey&#39;re running Core past that version. But this makes the IsStandard fun=
ction very much like a part of the consensus rules, as bypassing it can res=
ult in invalid blocks being created. Miners have always understood that the=
y can modify this function, or even bypass it entirely, without affecting t=
he validity of their blocks. And some miners do exactly that.</div><div><br=
></div><div>So I&#39;ll repeat the question that I posed before - given tha=
t there are clear, explicit downsides, what is the purpose of doing things =
this way? Where is the gain for ordinary Bitcoin users?</div></div></div></=
div>

--047d7bdc09f6b8d8bd0520cfd4d3--