Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U5I7F-00079M-4B for bitcoin-development@lists.sourceforge.net; Tue, 12 Feb 2013 15:49:53 +0000 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; Received: from mail-lb0-f174.google.com ([209.85.217.174]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1U5I7C-0008D1-LZ for bitcoin-development@lists.sourceforge.net; Tue, 12 Feb 2013 15:49:53 +0000 Received: by mail-lb0-f174.google.com with SMTP id l12so227515lbo.19 for ; Tue, 12 Feb 2013 07:49:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.134.164 with SMTP id pl4mr7672879lab.54.1360684183998; Tue, 12 Feb 2013 07:49:43 -0800 (PST) Received: by 10.112.96.164 with HTTP; Tue, 12 Feb 2013 07:49:43 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 07:49:43 -0800 Message-ID: From: Gregory Maxwell To: Raph Frank Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1U5I7C-0008D1-LZ Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:49:53 -0000 On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank 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.