Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.50 as permitted sender)
	client-ip=74.125.82.50; envelope-from=alex.mizrahi@gmail.com;
	helo=mail-wg0-f50.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
References: <20141212090551.GA8259@muck> <548ADED1.6060300@gmail.com>
	<CAE28kUR-PLzMGC23ETesc2Bz1_F1JfgcqyMW4qFvV5Vjk+ubbg@mail.gmail.com>
	<CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
Date: Fri, 12 Dec 2014 19:50:48 +0200
Message-ID: <CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=047d7b5d4188694520050a0888ed
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Setting the record straight on
	Proof-of-Publication
Precedence: list

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

> I think what Gareth was getting at was that with client-side validation
> there can be no concept of a soft-fork. And how certain are you that the
> consensus rules will never change?
>

Yes, it is true that you can't do a soft-fork, but you can do a hard-fork.
Using scheduled updates: client simply stops working at a certain block,
and user is required to download an update.

In Bitcoin we can operate with some assurance that hard-forks will almost
> never happen, exactly because extensions are more likely to occur via
> soft-fork mechanisms. In such a case, old non-updated clients will still
> generate a correct view of the ledger state. But this is not so with client
> side validation!
>

You assume that an ability to operate with zero maintenance is very
important, but is this a case?

There was a plenty of critical bugs in bitcoind, and in many cases people
were strongly encouraged to upgrade to a new version.
So, you urge people to keep their clients up-to-date, but at the same time
claim that keeping very old versions is critically important.
How does this make sense? Is this an exercise at double-think?

An alternative to this is to make updates mandatory. You will no longer
need to maintain compatibility with version 0.1 (which is impossible) and
you can also evolve consensus rules over time.

It looks like people make a cargo cult out of Bitcoin's emergent
properties.

--047d7b5d4188694520050a0888ed
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"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think what Gareth was get=
ting at was that with client-side validation there can be no concept of a s=
oft-fork. And how certain are you that the consensus rules will never chang=
e?</div></blockquote><div><br></div><div>Yes, it is true that you can&#39;t=
 do a soft-fork, but you can do a hard-fork.</div><div>Using scheduled upda=
tes: client simply stops working at a certain block, and user is required t=
o download an update.</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">In Bitcoin we can operate with some assurance that hard-fork=
s will almost never happen, exactly because extensions are more likely to o=
ccur via soft-fork mechanisms. In such a case, old non-updated clients will=
 still generate a correct view of the ledger state. But this is not so with=
 client side validation!</div></blockquote><div><br></div><div>You assume t=
hat an ability to operate with zero maintenance is very important, but is t=
his a case?</div><div><br></div><div>There was a plenty of critical bugs in=
 bitcoind, and in many cases people were strongly encouraged to upgrade to =
a new version.</div><div>So, you urge people to keep their clients up-to-da=
te, but at the same time claim that keeping very old versions is critically=
 important.</div><div>How does this make sense? Is this an exercise at doub=
le-think?</div><div><br></div><div>An alternative to this is to make update=
s mandatory. You will no longer need to maintain compatibility with version=
 0.1 (which is impossible) and you can also evolve consensus rules over tim=
e.</div><div><br></div><div>It looks like people make a cargo cult out of B=
itcoin&#39;s emergent properties.=C2=A0</div></div></div></div>

--047d7b5d4188694520050a0888ed--