From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wwvmi-0003Mk-Ci for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 15:58:56 +0000 X-ACL-Warn: Received: from quidecco.de ([81.169.136.15]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Wwvme-0002cs-Lh for bitcoin-development@lists.sourceforge.net; Tue, 17 Jun 2014 15:58:56 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id 8177ADFC55C; Tue, 17 Jun 2014 17:58:45 +0200 (CEST) From: Isidor Zeuner To: Paul Goldstein References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Message-Id: <20140617155845.8177ADFC55C@quidecco.de> Date: Tue, 17 Jun 2014 17:58:45 +0200 (CEST) X-Spam-Score: -1.0 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1Wwvme-0002cs-Lh Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 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: Tue, 17 Jun 2014 15:58:56 -0000 quote: > Mike Hearn, why don't we just have all nodes report attempted double spends > through the node network. No need to involve the miners at all really, or > do your suggestion but also report the double spend attempt. By waiting > maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can > be more sure that a double spend attack was not tried. Attacker would have > to hold back second tx by 10-60 seconds and hope that that second tx (with > higher fee) get's into a solved block before the first one. This forced > delay time ought to make the attack less successful (but not impossible). > What prevents the following steps from happening: 1. attacker sends first transaction, paying to the merchant 2. merchant waits 10-60 seconds 3. merchant confirms the payment as received 4. attacker sees merchant's confirmation 5. attacker sends double spend The security improvement seems to be pretty much exactly the chance that during the 10-60 seconds, a block is solved. Am I missing something? Regarding "reporting double spends", this would only help if it comes with some kind of penalty for the double spend. Now what if the double spend was not done on malicious motives? Maybe someone posted a transaction which does not confirm for some reason, and wants to recover his funds? Should we regard transactions which do not confirm as forever lost, in order to get to an "every double spend is a misbehaviour" policy? Best regards, Isidor