From: Gregory Maxwell <gmaxwell@gmail•com>
To: Raph Frank <raphfrk@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
Date: Tue, 12 Feb 2013 07:49:43 -0800 [thread overview]
Message-ID: <CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com> (raw)
In-Reply-To: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
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— it's not gauging consensus,
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— 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— it quite intentionally uses the consensus
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— 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— 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— script isn't
turing complete and look at all the issues it has had.
In summary— 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.
next prev parent reply other threads:[~2013-02-12 15:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 13:49 Raph Frank
2013-02-12 15:49 ` Gregory Maxwell [this message]
2013-02-13 14:58 ` Raph Frank
2013-02-13 15:42 ` Gregory Maxwell
2013-02-13 21:02 ` Gavin Andresen
2013-02-13 21:05 ` Gregory Maxwell
2013-02-13 23:10 ` Stephen Pair
2013-02-14 0:28 ` Gregory Maxwell
2013-02-14 2:44 ` Stephen Pair
2013-02-14 3:38 ` Gregory Maxwell
2013-02-14 5:36 ` Stephen Pair
2013-02-14 6:07 ` Peter Todd
2013-02-14 12:59 ` Stephen Pair
2013-02-18 16:22 ` Peter Todd
2013-02-14 1:02 ` Gregory Maxwell
2013-02-14 6:39 ` Peter Todd
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=CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=raphfrk@gmail$(echo .)com \
/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