Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.210.42 as permitted sender)
	client-ip=209.85.210.42; envelope-from=gavinandresen@gmail.com;
	helo=mail-pz0-f42.google.com; 
MIME-Version: 1.0
In-Reply-To: <1312496513.3109.57.camel@Desktop666>
References: <201108041423.14176.andyparkins@gmail.com>
	<201108041922.16956.andyparkins@gmail.com>
	<1312483196.3109.38.camel@Desktop666>
	<201108042042.55214.andyparkins@gmail.com>
	<82CEB610-9821-4928-8A13-30088A59223C@andrewschaaf.com>
	<1312490305.3109.46.camel@Desktop666>
	<4E3B18F3.4010605@justmoon.de>
	<CAAS2fgSmHJOd38FicROapfcYoxooCvg_Hh1Cc1r1WjOkGW+yjA@mail.gmail.com>
	<1312496513.3109.57.camel@Desktop666>
Date: Fri, 5 Aug 2011 10:07:46 +1000
Message-ID: <CABsx9T3hkdOo9fwpKzAAX6MiVWV7Fr3HGi8Bkhfm9ZV77xvpEg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=000e0cd22d101bd6b204a9b6e3cf
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Double spend detection to speed up
 transaction trust
Precedence: list

--000e0cd22d101bd6b204a9b6e3cf
Content-Type: text/plain; charset=ISO-8859-1

Couple of semi-random thoughts:

RE: detecting double spends:  I agree that extending the protocol to make
double-spend detection better is probably a bad idea.

That said, I could see extending the information reported by the
listtransactions/gettransaction API calls to report detected double spends (
== transaction uses the same inputs as another transaction in the block
chain or memory pool). IIRC, now the code just drops double spends, so if
this was done the implementation would have to be careful about being
vulnerable to a "fill memory with bogus transactions" attack.

RE: badly-behaved nodes:  I'd really like somebody to start experimenting
with algorithms for detecting well-behaved and ill-behaved nodes-- maybe
starting with a dns-seed implementation.  I suspect people are starting to
experiment with various types of Sybil attacks, which might explain why
network connectivity has been so bad.

(sent from the Sydney airport, before a very LOOONG flight back to
Massachusetts)
-- 
--
Gavin Andresen

--000e0cd22d101bd6b204a9b6e3cf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Couple of semi-random thoughts:<div><br></div><div>RE: detecting double spe=
nds: =A0I agree that extending the protocol to make double-spend detection =
better is probably a bad idea.</div><div><br></div><div>That said, I could =
see extending the information reported by the listtransactions/gettransacti=
on API calls to report detected double spends ( =3D=3D transaction uses the=
 same inputs as another transaction in the block chain or memory pool). IIR=
C, now the code just drops double spends, so if this was done the implement=
ation would have to be careful about being vulnerable to a &quot;fill memor=
y with bogus transactions&quot; attack.<br>
<br></div><div>RE: badly-behaved nodes: =A0I&#39;d really like somebody to =
start experimenting with algorithms for detecting well-behaved and ill-beha=
ved nodes-- maybe starting with a dns-seed implementation. =A0I suspect peo=
ple are starting to experiment with various types of Sybil attacks, which m=
ight explain why network connectivity has been so bad.</div>
<div><br><div class=3D"gmail_quote">(sent from the Sydney airport, before a=
 very LOOONG flight back to Massachusetts)</div>-- <br>--<br>Gavin Andresen=
<br><br>
</div>

--000e0cd22d101bd6b204a9b6e3cf--