From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R3xMm-0003pG-Ij for bitcoin-development@lists.sourceforge.net; Wed, 14 Sep 2011 21:51:36 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.175 as permitted sender) client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com; helo=mail-qy0-f175.google.com; Received: from mail-qy0-f175.google.com ([209.85.216.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1R3xMl-0001nc-Sx for bitcoin-development@lists.sourceforge.net; Wed, 14 Sep 2011 21:51:36 +0000 Received: by qyk10 with SMTP id 10so4581250qyk.13 for ; Wed, 14 Sep 2011 14:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.226.209 with SMTP id ix17mr315816qcb.147.1316037090472; Wed, 14 Sep 2011 14:51:30 -0700 (PDT) Received: by 10.229.49.12 with HTTP; Wed, 14 Sep 2011 14:51:30 -0700 (PDT) In-Reply-To: References: <4E6F83C3.9020108@jerviss.org> Date: Wed, 14 Sep 2011 17:51:30 -0400 Message-ID: From: Gregory Maxwell To: Alex Waters Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.3 (-) 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 0.3 AWL AWL: From: address is in the auto white-list X-Headers-End: 1R3xMl-0001nc-Sx Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues 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, 14 Sep 2011 21:51:36 -0000 On Wed, Sep 14, 2011 at 5:36 PM, Alex Waters wrote: > On Wed, Sep 14, 2011 at 4:28 PM, Gavin Andresen = wrote: > >> What do other people think? =C2=A0I think it is too high risk for too >> little benefit and shouldn't be done until we have a really compelling >> reason to introduce a forking change. > > Could we bundle this and potential future blockchain-splitting changes > - to implement them in a major release (down the road)? Or save them > for when they are very necessary? > > TL;DR shelf it until needed, have it written just in case. I'm generally opposed to doing "too much" at once in this kind of change. Some changes, like this one, are completely uncontroversial (except some argument about having fork causing change at all) where some have more complicated social/economic impacts (the block size being among them, though probably not the worst). Moreover, the longer we go between such changes the more the cost is perceived to be infinite. Better to take one per year, with six months of gap between implementation, and give everyone the right expectations than to have prolonged arguments due to our inexperience that only get trumped by emergency changes. General network health and user security _requires_ periodic upgrades in any case, and will for the foreseeable future. The whole notion that old versions will _stop working_ would be a pretty good thing at this point in bitcoin's existence, judging by the high number of pre-.24 listeners still reported.