Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.174 as permitted sender)
	client-ip=209.85.217.174; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f174.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
References: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
Date: Tue, 12 Feb 2013 07:49:43 -0800
Message-ID: <CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Raph Frank <raphfrk@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Incorporating block validation rule
 modifications into the block chain
Precedence: list

On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank <raphfrk@gmail.com> wrote:
> Has this been considered?
>
> If made sufficiently general, older clients could support any
> extension of the rules.
>
> Various "hard" parameters within the protocol are defined in main.h of
> the official client.
>
> In BIP-34, there is a suggested way to make changes, based on consensus.
> https://en.bitcoin.it/wiki/BIP_0034

You misunderstand what BIP_0034 is doing=E2=80=94 it's not gauging consensu=
s,
it's making sure that the change is safe to enforce. This is a subtle
but important difference.  The mechanism happens to be the same, but
we're not asking for anyone's approval there=E2=80=94 the change is needed =
to
make Bitcoin as secure as people previously believed it to be, there
have been no serious alternatives tendered. As far as I can tell the
proposal has always had universal agreement from anyone who's thought
about it.  The only open question was if it was safe to deploy, and
thats what that process solves.

Bitcoin is not a democracy=E2=80=94 it quite intentionally uses the consens=
us
mechanism _only_ the one thing that nodes can not autonomously and
interdependently validate (the ordering of transactions). This
protects the users of Bitcoin by making most of the system largely
nonvolatile "constitutional" rules instead of being controlled by
popular whim where 'two wolves may vote to have the one sheep for
dinner'. If it were possible to run the whole thing autonomously it
would be, but alas...

Even if you accept the premise that voting is a just way of making
decisions (it isn't; it's just often the least unjust when something
must be done), mining is not a particularly just way of voting:
'Hashpower isn't people', and currently the authority to control the
majority of the hashpower is vested in a only a half dozen people.
Moreover, the incentives to abuse hashpower are sharply curtailed by
its limited authority (all one can do with it is reorder
transactions... which is powerful but still finite) and allowing
arbitrary rule changes would vastly increase that power.

There are some more subtle issues=E2=80=94 if the acceptance of chain B
depends on if you've seen orthogonal chains A or A' first then there
can be a carefully timed announcement of A and A' which forever
prevents global convergence (thanks to a finite speed of light an
attacker can make sure some nodes see A first, some A').  If a rule
change can be reorged out, then it's not really a rule=E2=80=94 any actual
rule prohibits otherwise valid blocks that violate it (and without
this distinction you might as well implement the 'rule' as miner
preferences). Additionally there is the very hard software engineering
QA problem for a sufficiently complex rule language=E2=80=94 script isn't
turing complete and look at all the issues it has had.

In summary=E2=80=94 this sort of thing, which has come up before, is
technically interesting and fun to think about but it would make for
substantial engineering challenges and would not be obviously
compatible with the economic motivations which make Bitcoin secure nor
would it be morally compatible with the social contract embedded in
the system today.