From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFs4N-0002Fj-Rb for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 20:14:39 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129] helo=mail.ceptacle.com) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UFs4M-000588-OG for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 20:14:39 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id 41A7A2B97AA2; Wed, 13 Mar 2013 21:14:31 +0100 (CET) X-Virus-Scanned: amavisd-new at ceptacle.com Received: from mail.ceptacle.com ([127.0.0.1]) by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAkN13VOATNV; Wed, 13 Mar 2013 21:14:26 +0100 (CET) Received: from [10.0.1.67] (2508ds5-oebr.1.fullrate.dk [90.184.5.129]) by mail.ceptacle.com (Postfix) with ESMTPSA id 5CB4D2B97A8D; Wed, 13 Mar 2013 21:14:26 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Gronager In-Reply-To: <20130313182805.GA7921@vps7135.xlshosting.net> Date: Wed, 13 Mar 2013 21:14:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130313174838.GA22621@savin> <2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com> <20130313182805.GA7921@vps7135.xlshosting.net> To: Pieter Wuille X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1UFs4M-000588-OG Cc: bitcoin-development@lists.sourceforge.net, Michael Gronager Subject: Re: [Bitcoin-development] Blocksize and off-chain transactions 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: Wed, 13 Mar 2013 20:14:40 -0000 I hear consensus that at some point we need a hardfork (=3D=3D creating = blocks that will not be accepted by <0.7 clients). Miners generate block, hence they are the ones who should filter = themselves though some consensus.=20 > But we cannot just drop support for old nodes. It is completely = unreasonable to put the > _majority_ of the network on a fork, without even as much as a = discussion about it. > "Oh, you didn't get the memo? The rules implemented in your client are = outdated." - that > is not how Bitcoin works: the network defines the rules. Consensus was rapidly reached a day ago: To ensure the majority (all = of?) the network could accept the blocks mined, and not just 0.8. This = was the right decision! Too many was dependent on <=3D0.7 So, the question is not if, but when to do a hardfork. We need to define = and monitor the % of nodes running different versions (preferably a = weighted average - some nodes, like e.g. blockchain.info & mtgox serve = many...). Once there was the rowit bitcoinstatus page - do we have = another resource for this ? Then the second question is how to ensure we don't create a fork again? = Pieter (and others?) are of the opinion that we should mimic a 0.7 = lock-object-starvation-reject-rule. I don't like this for three reasons: 1. I find it hard to ensure we have actually coined the bug precisely 2. I expect that similar issues will happen again 3. The current issue was between two versions, but in the future it = could be between two implementations - then trying implement or even to = coordinate strange rules becomes very unlikely. Hence the scheme for "considerate mining" - it is the only scheme that = guarantees 100% that no block are released that will not be accepted by = a supermajority of the install base. Another nice thing about it - it requires no development :) So simply run in serial in front of all considerate miners nodes of = different versions until a certain threshold of the install base is = reached. /M