From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VAKoi-0000nQ-ES for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 14:15:52 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.84 as permitted sender) client-ip=62.13.149.84; envelope-from=pete@petertodd.org; helo=outmail149084.authsmtp.net; Received: from outmail149084.authsmtp.net ([62.13.149.84]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VAKog-0003kX-Jl for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 14:15:52 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r7GEFiKd003671; Fri, 16 Aug 2013 15:15:44 +0100 (BST) Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r7GEFab7036720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 16 Aug 2013 15:15:39 +0100 (BST) Date: Fri, 16 Aug 2013 10:15:36 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20130816141536.GD16201@petertodd.org> References: <20130816140116.GB16201@petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mJm6k4Vb/yFcL9ZU" Content-Disposition: inline In-Reply-To: <20130816140116.GB16201@petertodd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 541f51bd-067e-11e3-b5c5-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwQUGUATAgsB AmUbWlFeUVh7Wmo7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxt2 c2hPAB5ydANBen4+ bU9qVj5eWEUscEcv FlNUE2pTeGZhPWMC AkULch5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4kFyA9 QV8ZVS0oBlFAH2Ni ZyABBnlUGEcKLgN0 dzMA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1VAKog-0003kX-Jl Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list... 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, 16 Aug 2013 14:15:52 -0000 --mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote: > Doing this also makes it more difficult to sybil the network - for > instance right now you can create "SPV honeypots" that allow incoming > connections only from SPV nodes, thus attracting a disproportionate % of > the total SPV population given a relatively small number of nodes. You > can then use that to harm SPV nodes by, for instance, making a % of > transactions be dropped deterministicly, either by the bloom matching > code, or when sent. Users unlucky enough to be surrounded by sybil nodes > will have their transactions mysteriously fail to arrive in their > wallets, or have their transactions mysteriously never confirm. Given > how few full nodes there are, it probably won't take very many honeypots > to pull off this attack, especially if you combine it with a > simultaneous max connections or bloom io attack to degrade the capacity > of honest nodes. Oh, here's an even better way to do the "tx drop" attack: when you drop a transaction, make a fake one that pays the same scriptPubKeys with the same amount, and send it to the SPV peer instead. They'll see the transaction go through and show up in their wallet, but it'll look like it got stuck and never confirmed. They'll soon wind up with a wallet full of useless transactions, effectively locking them out of their money. Here's another question for you Mike: So does bitcoinj have any protections against peers flooding you with useless garbage? It'd be easy to rack up a user's data bill for instance by just creating junk unconfirmed transactions matching the bloom filter. --=20 'peter'[:-1]@petertodd.org 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55 --mJm6k4Vb/yFcL9ZU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlIONAgACgkQpEFN739thoxfKwCfQMNeLdXAMq9hBbTpdY4UwRjb kVcAoIC6EGCw7k60uChWru66g/ju71Yr =TMdz -----END PGP SIGNATURE----- --mJm6k4Vb/yFcL9ZU--