From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFqPN-0000Ec-0f for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 18:28:13 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UFqPM-0001R9-2f for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 18:28:12 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id 7B74333C896; Wed, 13 Mar 2013 19:28:06 +0100 (CET) Date: Wed, 13 Mar 2013 19:28:06 +0100 From: Pieter Wuille To: Michael Gronager Message-ID: <20130313182805.GA7921@vps7135.xlshosting.net> References: <20130313174838.GA22621@savin> <2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com> X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -1.2 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1UFqPM-0001R9-2f Cc: bitcoin-development@lists.sourceforge.net 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 18:28:13 -0000 On Wed, Mar 13, 2013 at 07:01:02PM +0100, Michael Gronager wrote: > Please note that it was not 0.8 that had issues, but 0.7(and downwards). > > I really think changing features in 0.8 aiming for a fluffy limit to avoid lock object errors on 0.7 is the wrong way to go, and it will never cover for a similar situations in the future. The current behaviour in 0.7 and before is indeed broken, and we cannot afford to keep that as an implicitly-defined rule on the network. I fully agree with that, but it will require a hardfork. 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. IMHO, the way to go is first get a 0.8.1 out that mimics the old behaviour - just as a stopgap solution. That will allow miners to safely use 0.8-based code at least. We can also get patches for 0.7 and previous branches that fix the lock limit issue, but enforce the same limit as 0.8.1 does, simply as band-aid for those who do not yet wish to upgrade to 0.8. Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This is something that requires widespread community consensus - far more than just miners and developers - but as this is about fixing a bug that would otherwise prevent most evolution, I hope it can be a very non-controversial one. To that end, I would prefer to limit this hard fork to only direct bug fixes, and leave the block limit issue for later. By now, I think it is clear that a hard fork will be inevitable, and by doing one, I think we can learn a lot that can make later ones easier. -- Pieter