From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qp7xA-00052b-Vx for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 00:07:52 +0000 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; Received: from mail-pz0-f42.google.com ([209.85.210.42]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1Qp7xA-0004J3-48 for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 00:07:52 +0000 Received: by pzk37 with SMTP id 37so2895552pzk.1 for ; Thu, 04 Aug 2011 17:07:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.216.14 with SMTP id o14mr1287864wfg.204.1312502866236; Thu, 04 Aug 2011 17:07:46 -0700 (PDT) Received: by 10.142.212.13 with HTTP; Thu, 4 Aug 2011 17:07:46 -0700 (PDT) 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> <1312496513.3109.57.camel@Desktop666> Date: Fri, 5 Aug 2011 10:07:46 +1000 Message-ID: From: Gavin Andresen To: Matt Corallo Content-Type: multipart/alternative; boundary=000e0cd22d101bd6b204a9b6e3cf X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Qp7xA-0004J3-48 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Double spend detection to speed up transaction trust X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:07:53 -0000 --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:

RE: detecting double spe= nds: =A0I 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/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 "fill memor= y with bogus transactions" attack.

RE: badly-behaved nodes: =A0I'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.

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

--000e0cd22d101bd6b204a9b6e3cf--