Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1S39gT-0005fN-0p for bitcoin-development@lists.sourceforge.net; Thu, 01 Mar 2012 17:20:53 +0000 Received: from mail-qw0-f47.google.com ([209.85.216.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1S39gN-0000Pi-Gm for bitcoin-development@lists.sourceforge.net; Thu, 01 Mar 2012 17:20:52 +0000 Received: by qadz30 with SMTP id z30so3275244qad.13 for ; Thu, 01 Mar 2012 09:20:42 -0800 (PST) Received-SPF: pass (google.com: domain of support@pi.uk.com designates 10.224.111.142 as permitted sender) client-ip=10.224.111.142; Authentication-Results: mr.google.com; spf=pass (google.com: domain of support@pi.uk.com designates 10.224.111.142 as permitted sender) smtp.mail=support@pi.uk.com Received: from mr.google.com ([10.224.111.142]) by 10.224.111.142 with SMTP id s14mr5577635qap.78.1330622442046 (num_hops = 1); Thu, 01 Mar 2012 09:20:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.111.142 with SMTP id s14mr4655490qap.78.1330622441881; Thu, 01 Mar 2012 09:20:41 -0800 (PST) Received: by 10.229.27.137 with HTTP; Thu, 1 Mar 2012 09:20:41 -0800 (PST) X-Originating-IP: [81.187.238.52] In-Reply-To: References: <20120229232029.GA6073@vps7135.xlshosting.net> <20120229234558.GA6573@vps7135.xlshosting.net> Date: Thu, 1 Mar 2012 17:20:41 +0000 Message-ID: From: Ben Reeves To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQngVy4ZOK/Puujk/orikie2KmfGTteplUoYDXMCbQgxPUefyxtonhUP9Vyf81iMJTgImbQP X-Spam-Score: -1.4 (-) 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.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1S39gN-0000Pi-Gm 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 17:20:53 -0000 >I am not following you here, can you explain what you're thinking? If I mine a duplicate coinbase of an old block (whether spent or not) if that block is then invalidated DisconnectBlock() will erase both the coinbase of the new block and of the old block. This leaves the blockchain is in an inconsistent state because with the coinbase missing the old block will no longer pass CheckBlock(). When affected clients are restarted LoadBlockIndex() will try and verify all blocks in the main chain, failing at the block with the missing coinbase. 1) If an attacker was to do this with an early block it would force all affected clients to redownload the majority of the blockchain. 2) If the attacker was able to do this on a block after the March 1st deadline (future block A). If they mined a fake copy of block A (block B) with the same coinbase but a different hash clients who received block B before block A will refuse to accept block A because of the unspent duplicate coinbase in block B. The attacker can then fork the chain at this point despite the real chain being longer. I am just think out load here so I could be wrong, but maybe it would be better to go for the full block height fix now? On Thu, Mar 1, 2012 at 2:27 PM, Gregory Maxwell wrote: > On Thu, Mar 1, 2012 at 8:09 AM, 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 am not following you here, can you explain what you're thinking? > >> Is there a reason not to disallow duplicate coinbases entirely? > > Because this would make it impossible for nodes to prune the vaules. > They'd all forever have to keep a set of all the coinbase hashes in > order to perform the test. The height-in-coinbase BIP will make > duplicates effectively impossible to create, which is a much more > clean behavior.