public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alex Mizrahi <alex.mizrahi@gmail•com>
To: Mark Friedenbach <mark@friedenbach•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
Date: Fri, 12 Dec 2014 19:50:48 +0200	[thread overview]
Message-ID: <CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

> 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.

[-- Attachment #2: Type: text/html, Size: 1918 bytes --]

  parent reply	other threads:[~2014-12-12 17:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-12  9:05 Peter Todd
2014-12-12 12:25 ` Gareth Williams
2014-12-12 17:04   ` Alex Mizrahi
     [not found]     ` <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
2014-12-12 17:50       ` Alex Mizrahi [this message]
2014-12-13 13:32         ` Gareth Williams
2014-12-15  4:52           ` Peter Todd
2014-12-17 11:55             ` Gareth Williams
2014-12-21  6:12               ` Peter Todd
2014-12-15  4:17         ` Peter Todd
2014-12-12 13:41 ` odinn
2014-12-12 14:17   ` Justus Ranvier
2014-12-15  4:59   ` Peter Todd
2014-12-17  1:16     ` odinn
2014-12-20 14:48 ` [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles Peter Todd
     [not found]   ` <CAOG=w-vrHPY1aCNndmoW9QyCh9XnWyv8uZn2PyjZ6rNg2MoSSw@mail.gmail.com>
2014-12-21  5:52     ` Peter Todd
     [not found]       ` <CAOG=w-tZke--6OsqNjJhE9SOdCwdZYZM8iz1VBTFziegt9UZWw@mail.gmail.com>
2014-12-21  7:01         ` Peter Todd
     [not found]           ` <CAOG=w-s1_VXJAKxBpMOK=B50qnHjxSe4J=vwwSfFPRz0_Cb9rA@mail.gmail.com>
2014-12-21 15:32             ` Peter Todd
2014-12-21 11:25       ` Jorge Timón
2014-12-21 16:07         ` Peter Todd
2014-12-21 19:39           ` Jorge Timón
2014-12-21 10:01   ` Adam Back
2014-12-21 15:29     ` Peter Todd
2014-12-21 13:49   ` paul snow
2014-12-21 15:22     ` Peter Todd
2014-12-21 15:41       ` paul snow
2014-12-22  0:11   ` Peter Todd
2015-01-06 11:03     ` joliver
2014-12-22 20:05   ` Adam Back
2014-12-16 20:28 [Bitcoin-development] Setting the record straight on Proof-of-Publication paul snow
2014-12-17 22:20 paul snow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAE28kUSZcGrFL3OMf=uOJ2=NQ89M54FOhR_iOXkEubrb6qqVAg@mail.gmail.com' \
    --to=alex.mizrahi@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=mark@friedenbach$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox