Received-SPF: pass (sog-mx-3.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-development@lists.sourceforge.net
Date: Thu, 4 Aug 2011 19:22:16 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; )
References: <201108041423.14176.andyparkins@gmail.com>
	<1312479917.3109.25.camel@Desktop666>
In-Reply-To: <1312479917.3109.25.camel@Desktop666>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201108041922.16956.andyparkins@gmail.com>
Subject: Re: [Bitcoin-development] Double spend detection to speed up
	transaction trust
Precedence: list

On Thursday 04 August 2011 18:45:17 Matt Corallo wrote:
> There really is no reason to add the extra network complexity for this.

It's hardly complex.  It's exactly as it is now, with exactly the messages 
there are now, but with an extra type added to the inventory list.  A 
transaction _already_ propagates using inv messages with MSG_TX, is it 
really so "complex" to add MSG_DOUBLESPEND to the enum?  What's more it's 
backward compatible because clients that don't understand MSG_DOUBLESPEND 
will ignore the inv ending up exactly where we are now.

> First of all (as you point out) no one buying a Ferrari will refuse to
> wait an hour for the payment to confirm.  If someone is attempting to
> pull a similar trick on, say, a vending machine however it might make
> sense.  But that changes the equation.  In order for these two scammers

Vending machine, newspaper salesman, ice creams, a beer.  The list of small 
vendors is endless.  I picked Ferrari's out of the air.

> to pull it off, some effort is required in terms of communicating the
> time to send the coins and the nodes of the targets (vending machines or
> whatever) must be figured out.  So now its less of "make it impossible"
> and more of "make it really hard to the point that it is no where near
> worth the effort".

I think you've missed the point.  Double spend transactions that enters the 
network at two reasonably evenly connected points are each only seen by half 
the network, since the first one locks out the second from propagation.

> Lets simplify the scenario a bit so that one scammer can pull it off.
> Send one copy of your transaction to the target node and another to
> large mining operations so that the payment transaction is considered
> invalid to miners and a transaction which pays you is confirmed.

There is no "target" node.  There is only a vending machine listening for 
transactions.  It's unlikely that vending machines will even have incoming 
connections enabled.  They certainly won't be keeping a full copy of the 
block chain or be mining.

> If you are the vending machine, your goal is not to figure out any
> transactions which are yours, but to figure out which transactions which

It is a little bit.  Your job is _first_ to figure out which are yours; 
then, as you say, to see which are going to be confirmed.  Well: once you've 
seen a transaction on the net you know it's going to be confirmed... unless 
a matching double spend transaction was accepted by the next miner to 
generate a block.

> are yours are going to be confirmed.  So, you peer with the largest
> miners (a "Bitcoin backbone" or large miners and merchants has been
> suggested over and over again and really hasn't happened) and modify

It hasn't happened, and yet it seems to be that this non-existant thing is 
your solution to the problem.

> your client to, instead of dropping transactions which are
> double-spends, keep both in memory pool and consider them both invalid
> until one of them confirms.

Well that's what happens now.  But that doesn't help the poor sap who's just 
handed over some goods.  I want it so that small businesses can use the 
client to give them practical answers instead of this "0/unconfirmed" stuff 
which requires understanding of the system.

> This will work with 1, 2, or n scammers, doesn't require any additional
> network messages, and offers just as good, if not better security over a
> double spend message.

I'm not really trying to prevent double spends -- bitcoin _already_ prevents 
double spends.  Also: the only difference between your suggestion (don't 
drop) and my suggestion (don't drop but mark with MSG_DOUBLESPEND) is a 
single number in the inv.  I really don't get the objection.

> Additionally, in the future, when(/if) Bitcoin payment processors exist,

"In the future" is all well and good.  What if there is no future because 
bitcoin is still too difficult for average joe to use?


Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com