Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1S371k-00085U-Jk for bitcoin-development@lists.sourceforge.net; Thu, 01 Mar 2012 14:30:40 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1S371g-0004VZ-Ff for bitcoin-development@lists.sourceforge.net; Thu, 01 Mar 2012 14:30:40 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id 5F6F660EAC; Thu, 1 Mar 2012 15:30:30 +0100 (CET) Date: Thu, 1 Mar 2012 15:30:30 +0100 From: Pieter Wuille To: Ben Reeves Message-ID: <20120301143029.GA18168@vps7135.xlshosting.net> References: <20120229232029.GA6073@vps7135.xlshosting.net> <20120229234558.GA6573@vps7135.xlshosting.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) 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 -0.0 T_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: 1S371g-0004VZ-Ff Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability 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: Thu, 01 Mar 2012 14:30:40 -0000 On Thu, Mar 01, 2012 at 01:09:02PM +0000, Ben Reeves wrote: > One more thing to add. The implementation in the reference patch fixes > the blockchain forking issue however by still allowing spent coinbases > to be disconnected patched clients are still vulnerable to blockchain > corruption. While not an immediate issue it would mean > LoadBlockIndex() would error on restart and could cause problems for > new clients during the initial blockchain download. I don't understand this. > Is there a reason not to disallow duplicate coinbases entirely? Just disallowing duplicate coinbases is possible, but it requires keeping a set of all coinbases transaction around until infinity. That's not really a problem, but it can be avoided. One very reasonable proposed solution is adding the block height to the coinbase. However, as coinbases are used for all kinds of things already, this is harder to roll out network-wide. Hence, first this "emergency" solution that already prevents (afaik) all practical attacks, and in a later step forcing unique coinbases, so that transactions can be assumed to be unique identifiable by their hash again. -- Pieter