MIME-Version: 1.0
In-Reply-To: <CAE28kUQ4ebyo1WrMJTq658u4CZnLmnw40oZrNwRGHG+oW3UYbA@mail.gmail.com>
References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com>
	<20170406023123.GA1071@savin.petertodd.org>
	<CA+KqGkqSxeAUZFVFqM_QkEWcGFHgZXwGuOE==7HpXp1+D_Tj3Q@mail.gmail.com>
	<20170406024910.GA1271@savin.petertodd.org>
	<CAFVRnyrqiNY_JOqhv2ysm2WsBMYsU3tTAASAtHzMbA68_9Yx8g@mail.gmail.com>
	<F5F02B94-E094-4C16-80B6-8B0876E423E4@toom.im>
	<CAE28kUQ4ebyo1WrMJTq658u4CZnLmnw40oZrNwRGHG+oW3UYbA@mail.gmail.com>
From: Jannes Faber <jannes.faber@gmail.com>
Date: Fri, 7 Apr 2017 14:59:13 +0200
Message-ID: <CABeL=0hv3=Ak6soja8Am0+OOg6a8MUeHPi=YJnMdMsHNMG6HKQ@mail.gmail.com>
To: Alex Mizrahi <alex.mizrahi@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c06e5fa779013054c9332cf
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the
 Bitcoin POW function
Precedence: list

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

On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Ethically, this situation has some similarities to the DAO fork.
>
>
> Much better analogy:
>
> 1. An ISV make software which makes use of an undocumented OS feature.
> 2. That feature is no longer present in the next OS release.
> 3. ISV suffers losses because its software cannot work under new OS, and
> thus people stop buying it.
>
> I think 99% of programmers would agree that this loss was inflicted by a
> bad decision of ISV, and not by OS vendor changing OS internals. Relying on
> undocumented features is something you do on your own risk.
>

Right. And in this case, code still is law: if the code specifies a version
number field and some miner finds an optimization that only works when the
version number == 1 then it's his own problem once the network upgrades to
version 2. In no way is there anything ethical about blocking the upgrade.

History is not an indicator of the possible values any field can hold in
the future. Limiting your operation to some arbitrary subset is at your own
risk.

Regarding the comparison: I haven't heard anyone even suggest rolling back
the last year of the blockchain to undo the damage already done, any
comparison can end there. If Jonathan wants to persist with this comparison
it would be more like people deciding to stop further funding of the hacked
contract. Yeah, that evil.

--
Jannes Faber

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D""><br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ethica=
lly, this situation has some similarities to the DAO fork.=C2=A0</blockquot=
e><div><br></div></span><div>Much better analogy:</div><div><br></div><div>=
1. An ISV make software which makes use of an undocumented OS feature.</div=
><div>2. That feature is no longer present in the next OS release.</div><di=
v>3. ISV suffers losses because its software cannot work under new OS, and =
thus people stop buying it.</div><div><br></div><div>I think 99% of program=
mers would agree that this loss was inflicted by a bad decision of ISV, and=
 not by OS vendor changing OS internals. Relying on undocumented features i=
s something you do on your own risk.</div></div></div></div></blockquote><d=
iv><br></div><div>Right. And in this case, code still is law: if the code s=
pecifies a version number field and some miner finds an optimization that o=
nly works when the version number =3D=3D 1 then it&#39;s his own problem on=
ce the network upgrades to version 2. In no way is there anything ethical a=
bout blocking the upgrade.</div><div><br></div><div>History is not an indic=
ator of the possible values any field can hold in the future. Limiting your=
 operation to some arbitrary subset is at your own risk.</div><div><br></di=
v><div>Regarding the comparison: I haven&#39;t heard anyone even suggest ro=
lling back the last year of the blockchain to undo the damage already done,=
 any comparison can end there. If Jonathan wants to persist with this compa=
rison it would be more like people deciding to stop further funding of the =
hacked contract. Yeah, that evil.</div><div><br></div><div>--</div><div>Jan=
nes Faber</div><div><br></div></div></div></div>

--94eb2c06e5fa779013054c9332cf--