Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SnEjP-0001ZK-3o for bitcoin-development@lists.sourceforge.net; Fri, 06 Jul 2012 20:02:23 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.175 as permitted sender) client-ip=209.85.215.175; envelope-from=gavinandresen@gmail.com; helo=mail-ey0-f175.google.com; Received: from mail-ey0-f175.google.com ([209.85.215.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SnEjO-0005rU-E4 for bitcoin-development@lists.sourceforge.net; Fri, 06 Jul 2012 20:02:23 +0000 Received: by eaal1 with SMTP id l1so3655207eaa.34 for ; Fri, 06 Jul 2012 13:02:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.27.202 with SMTP id e50mr7500749eea.186.1341604936189; Fri, 06 Jul 2012 13:02:16 -0700 (PDT) Received: by 10.14.209.73 with HTTP; Fri, 6 Jul 2012 13:02:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 16:02:16 -0400 Message-ID: From: Gavin Andresen To: Mark Friedenbach Content-Type: text/plain; charset=ISO-8859-1 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 (gavinandresen[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: 1SnEjO-0005rU-E4 Cc: Bitcoin Development Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase 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: Fri, 06 Jul 2012 20:02:23 -0000 > But those issues are solvable through other, non-backwards incompatible > means. For example, mandate that a refers > to the first such pair that is not already spent. No? Yes, that is essentially what BIP 30 did. We want to do this also, partly for "belt and suspenders" security but mostly for two reasons: 1. To test using block/transaction version numbers to smoothly roll out changes. The next change we need to make might be prompted by some crisis; better to learn any lessons now, when we have the luxury of time to fix problems that might crop up. 2. We think we'll all appreciate the change in a year or three, when the whole network has upgraded and we can start writing code that assumes all new blocks past a certain checkpoint contain their height; that should make it easier to do things like figure out whether or not an orphan chain can possibly be part of the main chain. -- -- Gavin Andresen