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; 
From: Andy Parkins <andyparkins@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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>
Subject: [Bitcoin-development] Double spend detection to speed up
	transaction trust
Precedence: list

--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--