<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?</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 updates: client simply stops working at a certain block, and user is required to download an update.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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!</div></blockquote><div><br></div><div>You assume that an ability to operate with zero maintenance is very important, but is this 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-date, 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 double-think?</div><div><br></div><div>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.</div><div><br></div><div>It looks like people make a cargo cult out of Bitcoin&#39;s emergent properties. </div></div></div></div>