From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QoxtV-0005k5-U2 for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 13:23:25 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com; helo=mail-ww0-f53.google.com; Received: from mail-ww0-f53.google.com ([74.125.82.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QoxtV-0003BT-1w for bitcoin-development@lists.sourceforge.net; Thu, 04 Aug 2011 13:23:25 +0000 Received: by wwf26 with SMTP id 26so1710773wwf.10 for ; Thu, 04 Aug 2011 06:23:18 -0700 (PDT) Received: by 10.216.154.144 with SMTP id h16mr610009wek.104.1312464198859; Thu, 04 Aug 2011 06:23:18 -0700 (PDT) Received: from dvr.localnet (mail.360visiontechnology.com [92.42.121.178]) by mx.google.com with ESMTPS id r48sm1191087weq.26.2011.08.04.06.23.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 06:23:16 -0700 (PDT) From: Andy Parkins To: Bitcoin Dev Date: Thu, 4 Aug 2011 14:23:10 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.38-2-686; KDE/4.6.3; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4338600.LmtXrNMV4W"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201108041423.14176.andyparkins@gmail.com> 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 (andyparkins[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: 1QoxtV-0003BT-1w Subject: [Bitcoin-development] Double spend detection to speed up transaction trust 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, 04 Aug 2011 13:23:26 -0000 --nextPart4338600.LmtXrNMV4W Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Here's a scenario (it's contrived to make the players easy to identify, mor= e=20 likely this would be low value automated vendors): Two scammers get together to buy two Ferraris using only one set of BTC. T= hey=20 travel to opposite ends of the world to two car dealerships that accept=20 bitcoins without waiting for confirmations. They are in contact by mobile.= =20 They each buy the car and come to pay. At exactly the same moment, they bo= th=20 spend the same coins. They both walk away with a car. The current solution is the recommendation that vendors wait for six=20 confirmations before releasing goods. That's a long time though; more than= =20 most would be willing to wait. Some points: - The bitcoin network is essentially honest - If a block chain fork happens, the transactions that are orphaned get ad= ded to the pending transaction list again, meaning ... - A valid transaction will _eventually_ make it into the (longest) block chain. - Actual distribution time for a transaction through the network is in the order of seconds not minutes - A double spend attempt has to enter the network near simulateously at different places, otherwise the second spend will be rejected instantly = by the whole network. New transactions propagate through the network if they are found to be vali= d. =20 If they aren't valid, they are silently dropped. In the event of a double= =20 spend attempt one of those transactions goes to (say) half the network, the= =20 other goes to the other half. Whichever one reaches a node first is seen a= s=20 the real one, the second being seen as invalid. One or other of these will= =20 therefore end up in the "longest" chain; but there is no way to know which. Here's my proposal then: when a node drops a transaction, it should not be= =20 silent. It should be broadcast just as it always was going to be had it be= en=20 valid. Only it is broadcast with a new "inv" type, let's say=20 "MSG_DOUBLESPEND" instead of "MSG_TX". Now run the Ferrari test again. The vendor sees the transaction that pays = for=20 the car appear near instantly (within the propagation time of the network).= A=20 short while later they also see a MSG_DOUBLESPEND of the same coins that th= ey=20 have just accepted. They can then operate whatever policy they want: wait = for=20 six, ten, twenty confirmations. Call the police. Whatever. Miners can al= so=20 significantly lower the priority of any transactions that get flagged in th= is=20 way. When there isn't a double spend attempt message within the network propagat= ion=20 time, they can be sure that their transaction is the one that miners are=20 working on, and they'll eventually get their money. In other words, they c= an=20 accept the payment on zero confirmations. At first I was concerned that this would make it possible to DOS a=20 transaction, but of course it doesn't -- the transaction has to be internal= ly- valid to result in a MSG_DOUBLESPEND, meaning it can only be DOSed by someo= ne=20 with the appropriate private keys. Andy =2D-=20 Dr Andy Parkins andyparkins@gmail.com --nextPart4338600.LmtXrNMV4W Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk46nT4ACgkQwQJ9gE9xL21F4wCcCYwiEdHYl8P2gvgEXYBmm+rh VyEAoMUMcrjCDRxMrIRQgN9hPWYyU0qL =KKPK -----END PGP SIGNATURE----- --nextPart4338600.LmtXrNMV4W--