[Bitcoin-development] Setting the record straight on Proof-of-Publication

Alex Mizrahi alex.mizrahi at gmail.com
Fri Dec 12 17:50:48 UTC 2014


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141212/7dd1f4ef/attachment.html>


More information about the bitcoin-dev mailing list