From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XzUMh-0007zs-6P for bitcoin-development@lists.sourceforge.net; Fri, 12 Dec 2014 17:50:55 +0000 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; Received: from mail-wg0-f50.google.com ([74.125.82.50]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XzUMg-0003GZ-6q for bitcoin-development@lists.sourceforge.net; Fri, 12 Dec 2014 17:50:55 +0000 Received: by mail-wg0-f50.google.com with SMTP id a1so9808446wgh.9 for ; Fri, 12 Dec 2014 09:50:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.6.7 with SMTP id w7mr28704797wjw.25.1418406648168; Fri, 12 Dec 2014 09:50:48 -0800 (PST) Received: by 10.27.203.198 with HTTP; Fri, 12 Dec 2014 09:50:48 -0800 (PST) In-Reply-To: References: <20141212090551.GA8259@muck> <548ADED1.6060300@gmail.com> Date: Fri, 12 Dec 2014 19:50:48 +0200 Message-ID: From: Alex Mizrahi To: Mark Friedenbach Content-Type: multipart/alternative; boundary=047d7b5d4188694520050a0888ed X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (alex.mizrahi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XzUMg-0003GZ-6q Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 17:50:55 -0000 --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

=
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?

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

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!

You assume t= hat an ability to operate with zero maintenance is very important, but is t= his 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-da= te, but at the same time claim that keeping very old versions is critically= important.
How does this make sense? Is this an exercise at doub= le-think?

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.

It looks like people make a cargo cult out of B= itcoin's emergent properties.=C2=A0
--047d7b5d4188694520050a0888ed--