public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Double spend detection to speed up transaction trust
Date: Thu, 4 Aug 2011 14:23:10 +0100	[thread overview]
Message-ID: <201108041423.14176.andyparkins@gmail.com> (raw)

[-- Attachment #1: Type: Text/Plain, Size: 3096 bytes --]

Hello,

Here's a scenario (it's contrived to make the players easy to identify, more 
likely this would be low value automated vendors):

Two scammers get together to buy two Ferraris using only one set of BTC.  They 
travel to opposite ends of the world to two car dealerships that accept 
bitcoins without waiting for confirmations.  They are in contact by mobile.  
They each buy the car and come to pay.  At exactly the same moment, they both 
spend the same coins.  They both walk away with a car.

The current solution is the recommendation that vendors wait for six 
confirmations before releasing goods.  That's a long time though; more than 
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 added
   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 valid.  
If they aren't valid, they are silently dropped.  In the event of a double 
spend attempt one of those transactions goes to (say) half the network, the 
other goes to the other half.  Whichever one reaches a node first is seen as 
the real one, the second being seen as invalid.  One or other of these will 
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 
silent.  It should be broadcast just as it always was going to be had it been 
valid.  Only it is broadcast with a new "inv" type, let's say 
"MSG_DOUBLESPEND" instead of "MSG_TX".

Now run the Ferrari test again.  The vendor sees the transaction that pays for 
the car appear near instantly (within the propagation time of the network).  A 
short while later they also see a MSG_DOUBLESPEND of the same coins that they 
have just accepted.  They can then operate whatever policy they want: wait for 
six, ten, twenty confirmations.  Call the police.  Whatever.  Miners can also 
significantly lower the priority of any transactions that get flagged in this 
way.

When there isn't a double spend attempt message within the network propagation 
time, they can be sure that their transaction is the one that miners are 
working on, and they'll eventually get their money.  In other words, they can 
accept the payment on zero confirmations.

At first I was concerned that this would make it possible to DOS a 
transaction, but of course it doesn't -- the transaction has to be internally-
valid to result in a MSG_DOUBLESPEND, meaning it can only be DOSed by someone 
with the appropriate private keys.



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

             reply	other threads:[~2011-08-04 13:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 13:23 Andy Parkins [this message]
2011-08-04 17:45 ` [Bitcoin-development] Double spend detection to speed up transaction trust Matt Corallo
2011-08-04 18:22   ` Andy Parkins
2011-08-04 18:39     ` Matt Corallo
2011-08-04 19:42       ` Andy Parkins
2011-08-04 20:07         ` Andrew Schaaf
2011-08-04 20:38           ` Matt Corallo
2011-08-04 22:10             ` Stefan Thomas
2011-08-04 22:18               ` Gregory Maxwell
2011-08-04 22:21                 ` Matt Corallo
2011-08-05  0:07                   ` Gavin Andresen
2011-08-04 20:08         ` Gregory Maxwell
2011-08-04 20:33         ` Matt Corallo
2011-08-04 21:36         ` Mike Hearn
2011-08-04 22:16           ` Matt Corallo
2011-08-05  0:14             ` Stefan Thomas
2011-08-05 11:05               ` Mike Hearn
2011-08-05 11:58                 ` Andy Parkins
2011-08-05 12:06                   ` Matt Corallo
2011-08-05 13:03                     ` Andy Parkins
2011-08-05 21:23                       ` Gregory Maxwell
2011-08-05 21:30                       ` Matt Corallo
2011-08-05 12:00               ` Matt Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201108041423.14176.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox