Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 173.246.101.161 as permitted sender)
	client-ip=173.246.101.161;
	envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; 
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
In-Reply-To: <201108041922.16956.andyparkins@gmail.com>
References: <201108041423.14176.andyparkins@gmail.com>
	<1312479917.3109.25.camel@Desktop666>
	<201108041922.16956.andyparkins@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1";
	protocol="application/pgp-signature";
	boundary="=-NTHpBLNYZWKoqR7SlnSM"
Date: Thu, 04 Aug 2011 20:39:56 +0200
Message-ID: <1312483196.3109.38.camel@Desktop666>
Mime-Version: 1.0
Subject: Re: [Bitcoin-development] Double spend detection to speed up
 transaction trust
Precedence: list


--=-NTHpBLNYZWKoqR7SlnSM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-08-04 at 19:22 +0100, Andy Parkins wrote:
> On Thursday 04 August 2011 18:45:17 Matt Corallo wrote:
> > There really is no reason to add the extra network complexity for this.
>=20
> It's hardly complex.  It's exactly as it is now, with exactly the message=
s=20
> there are now, but with an extra type added to the inventory list.  A=20
> transaction _already_ propagates using inv messages with MSG_TX, is it=
=20
> really so "complex" to add MSG_DOUBLESPEND to the enum?  What's more it's=
=20
> backward compatible because clients that don't understand MSG_DOUBLESPEND=
=20
> will ignore the inv ending up exactly where we are now.
But why? It results in slightly more network traffic which is exactly
what we don't want, and it adds yet another message people have to know
about.
>=20
> > 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
>=20
> Vending machine, newspaper salesman, ice creams, a beer.  The list of sma=
ll=20
> vendors is endless.  I picked Ferrari's out of the air.
Ferraris aren't exactly small ;)
>=20
> > 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 o=
r
> > 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".
>=20
> I think you've missed the point.  Double spend transactions that enters t=
he=20
> network at two reasonably evenly connected points are each only seen by h=
alf=20
> the network, since the first one locks out the second from propagation.
No one cares about what the network thinks is the right transaction, its
only what miners believe that matters.
>=20
> > 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.
>=20
> There is no "target" node.  There is only a vending machine listening for=
=20
> transactions.  It's unlikely that vending machines will even have incomin=
g=20
> connections enabled.  They certainly won't be keeping a full copy of the=
=20
> block chain or be mining.
Even if the vending machine doesn't keep the full chain and doesn't
accept incoming connections, its still the target node.  What other
nodes on the network think doesn't matter as long as you get the target
to think a transaction that won't be confirmed will be.  If it doesn't
accept incoming connections you want to find nodes that do that are
connected to your target.
>=20
> > If you are the vending machine, your goal is not to figure out any
> > transactions which are yours, but to figure out which transactions whic=
h
>=20
> It is a little bit.  Your job is _first_ to figure out which are yours;=
=20
> then, as you say, to see which are going to be confirmed.  Well: once you=
've=20
> seen a transaction on the net you know it's going to be confirmed... unle=
ss=20
> a matching double spend transaction was accepted by the next miner to=20
> generate a block.
That is exactly my point.
>=20
> > 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
>=20
> It hasn't happened, and yet it seems to be that this non-existant thing i=
s=20
> your solution to the problem.
Its much easier to create than to change the network code to relay info
on double-spend transactions.
>=20
> > 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.
>=20
> Well that's what happens now.  But that doesn't help the poor sap who's j=
ust=20
> handed over some goods.  I want it so that small businesses can use the=
=20
> client to give them practical answers instead of this "0/unconfirmed" stu=
ff=20
> which requires understanding of the system.
No, thats not what happens now.  Currently if your node gets a
transaction which conflicts with one it already knows about, it silently
drops it without a second thought.  My point is if you actually dealt
with such cases and made good connections, you would be able to prevent
double spends nearly perfectly.
>=20
> > 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.
>=20
> I'm not really trying to prevent double spends -- bitcoin _already_ preve=
nts=20
> double spends.  Also: the only difference between your suggestion (don't=
=20
> drop) and my suggestion (don't drop but mark with MSG_DOUBLESPEND) is a=
=20
> single number in the inv.  I really don't get the objection.
No, my suggestion is not to relay the second transaction.  The second
transaction should continue to not be relayed as it currently is,
however receiving such a transaction should trigger the node to notify
the user that the transaction should not be accepted until it makes it
into a block (in fact, you could already do this if you implemented a
debug.log parser and made well-placed connections).
>=20
> > Additionally, in the future, when(/if) Bitcoin payment processors exist=
,
>=20
> "In the future" is all well and good.  What if there is no future because=
=20
> bitcoin is still too difficult for average joe to use?
Bitcoin is absolutely still an experiment and no one thinks that any
kind of future is guaranteed.  This was not meant as an argument, but
simply as "if bitcoin does end up going somewhere, it will likely be
done like this".

Matt

--=-NTHpBLNYZWKoqR7SlnSM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAABAgAGBQJOOud6AAoJEBrh01BD4I5UdtYP/AireQfHxJ9H7+DSrDUV4RvX
mdKrT4NWkKr6M846/s7v9r7Und5ocf304Mf0lw//s0j4G0/UiGVsCUln+76s5pCH
ojyQojCxiZNWEipcdgliILUMFxDI0yVXRKuTJ+6FOQNpNW/agrSAftBivCHFLYZZ
dQR34MImo68GdMkVwxgm2wWKQK/uKPbITLVIPw2WTWqxiSxQgzVfrBzNVwbhghLo
QM2goYt70rzn00/MPvtfBwOJtG1aBEtHXhsuC/PmI77NQrEvo1SAbNFdB3b+NsdO
JWKUBygOkNMQH2ogkDlfZZyUrKYdhFU76Z9mWnEmCt8/ZoKrQ/ens6pObPZWNxvA
fJD5AXQMtzIBckhMKIRXT0XmE5cdvg1aGLT5zrOEr2RCBCRi2qx67olQISO6eCJ/
GCMKIKBr/v+2zEwx9y5F2YrpAYxigtmswJPNwoxzBKTkN+kUHe/xiVg2C+UF/AEZ
BloXh4MeW74pWRayMYDH+VxAHEfUGhGERm7Rf5Bae/OJevO1zfeTC07X7IAciHNp
5jCvZo1YN+2pOV5up+nZ8ewAGc+hRQTr4mADozLPE8IO++0Istd8CcjQPgnDVvF2
QDDYH7waPWpfNPfv2mmpaH5/NsoH4ak9ZSHYTvUDuZUYdqZOXlXnWnPP/TI0Bw+V
lWswMOOmt/Bk6VIYM18C
=PvJ6
-----END PGP SIGNATURE-----

--=-NTHpBLNYZWKoqR7SlnSM--