From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdNDG-0003qT-0r for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 17:13:30 +0000 X-ACL-Warn: Received: from triton.rz.uni-saarland.de ([134.96.7.25]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WdNDE-0000Fx-0m for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 17:13:29 +0000 Received: from [192.168.178.27] (dslb-188-107-014-010.pools.arcor-ip.net [188.107.14.10]) (authenticated bits=0) by triton.rz.uni-saarland.de (8.14.1/8.14.0) with ESMTP id s3OHD43M023972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 24 Apr 2014 19:13:15 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at HIZ-Mailrelay triton.rz.uni-saarland.de Message-ID: <53594624.70807@stud.uni-saarland.de> Date: Thu, 24 Apr 2014 19:13:08 +0200 From: Jannis Froese User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "bitcoin-development@lists.sourceforge.net" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (triton.rz.uni-saarland.de [134.96.7.25]); Thu, 24 Apr 2014 19:13:16 +0200 (CEST) X-Spam-Score: -0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WdNDE-0000Fx-0m Subject: Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory 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, 24 Apr 2014 17:13:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24.04.2014 14:15, Mike Hearn wrote: > Beyond needing to double balances, what if the shop is selling me a > phone on contract? So the actual cost of the phone is lower than > the real price on the assumption of future revenue. Alice double > spends (aka steals) the phone, paying double the artifically lower > cost but still making a good saving. Bob does not end up with > "nothing", he ends up in the red. Nearly every payment system in existence has this problem: you have to be able to enforce the contract out-of-band. The scenario you describe is no worse than a payment network with instant, secure confirmations because Alice could just as well refuse to make the second payment. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTWUYdAAoJEBrvn3PsoRcmT28QAJNbxjLRPYvkIfizeHoAFRH2 pNfd9458/AECJ6muGAs+tYeDw9uhYMVPnbMLZOwzgPl8HE5NN9XbGjCpwpNzsEK4 a8zb5CsonBh+xBNgbx1CIjCNYYQLd2qmgxMVaH4R7VWS+DgVBjfKq5MnM0vdSNcw SSzb9dMEjgl1cOZa07CG4GuPwEUIFiCVygjYSrGP2E8qCepKvH+0webIXk7COqZK SyhTdhS+dsdgGW5Mm8cA8zIVPaWYXMo88kOq2S4fIs5HiWtnVXQ9ljJ4r2Py1SEO H3u4lMWc7Hu0PUW6b6K+uDQfyJtRNi0diJSswseA37v6BeQW4zYMNfL40AsnG+Fv MusJFtBqHzXKhAeE/zpwi5QWs/qHvRYlETifIMKMrQldssDJo15ed/M8wNCZRobv Q7K3XKOt228nUUP2FrZl1I4wGWwkBMpzP89t8HMrTZYV2EFWqE+lu9oXcEjz9k12 64UXiWXU0jRAhMiCAvQUL7fKaOb9TXfGPy+3+bZOAtKM5M582+0d94EObA67SBsm O4H5vLTwS041x1cndW0NDxDbtM+IAuu2Jorzqzcie3ld7cqsKAyDbSk3i1C7zQzG hvI6FxIy0n6GA9ciw8RM44Q4zPVxYQ4e/MMby9ko7otmL5HLlOCnOUmJ/JHn+QJG Z7MDRkKAslLUUEqzgQWb =HNO6 -----END PGP SIGNATURE-----