Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1USl8x-0002F4-64 for bitcoin-development@lists.sourceforge.net; Thu, 18 Apr 2013 09:28:39 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.43 as permitted sender) client-ip=62.13.149.43; envelope-from=pete@petertodd.org; helo=outmail149043.authsmtp.co.uk; Received: from outmail149043.authsmtp.co.uk ([62.13.149.43]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1USl8v-0002v7-IT for bitcoin-development@lists.sourceforge.net; Thu, 18 Apr 2013 09:28:39 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r3I9SVkJ092395; Thu, 18 Apr 2013 10:28:31 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r3I9SOVf054743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 10:28:27 +0100 (BST) Date: Thu, 18 Apr 2013 05:28:24 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20130418092824.GA10184@savin> References: <453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com> <20130418090444.GA30995@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20130418090444.GA30995@savin> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 537bb9ad-a80a-11e2-b5c5-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwoUGUUGAgsB AmUbWlReUlV7W2Q7 bAxPbAVDY01GQQRq WVdMSlVNFUsqAmUI ZWF4BBl3cwJCezB4 bERqEHVYWxYofBcp Xx9cFTwbZGY1an1N VRNdagNUcgZDfk5E bwQuUz1vNG8XDQg5 AwQ0PjZ0MThBJSBS WgQAK04nCW8NAj90 axc5VTsoBwUZV20p IgQiI1URGUsXLi0A X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/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: 1USl8v-0002v7-IT Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Anti DoS for tx replacement 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: Thu, 18 Apr 2013 09:28:39 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 18, 2013 at 05:04:44AM -0400, Peter Todd wrote: > An attack still shuts down useful tx replacement though. For instance in > the adjusting payments example an attacker sets up a legit adjusting > payment channel, does a bunch of adjustments, and then launches their > attack. They broadcast enough adjustments that their adjustment session > looks like part of an attack, and then don't have to pay for the full > adjusted amount. =2E..and actually, that's not a problem if the defender is online, because they can just broadcast the highest sequence numbered tx, which blocks further broadcasts by the attacker. You still need some way of distinguishing the two acts, by time is probably fine, but it'd make a real attack difficult. Of course, regardless you are still asking nodes to set aside however many KB/second to tx replacement transactions, and they're all going to use different settings, which makes overall network convergence impossible to guarantee as legit replacement transactions outnumber non-legit ones. Any protocol requiring the broadcast of more than one or two replacements, either normally or against an attacker, just isn't going to be reliable. But many don't, so they're probably doable. But lets see some working code first... --=20 'peter'[:-1]@petertodd.org --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRb7y3AAoJEH+rEUJn5PoEA7IH/AyhRVWdgLfet5//Wl3An3P1 qjtRZvAMFCQHB7Nx73TXHuZbMTXuQV4F2LsZB790sI0FE6vLFVKHhjov0g06a00X YW9WNDkIXMOX3vVLRuhBMAaltrSZKE57q8z3ctkfMu0+21d2G4T9jpaoDKBrcm7u o9h4HUni3WVB5mj9K9HgMZZQxFjAm4ozkGe3WrVY4+Z2iWGsfnaAIDtQ/IKnyUnQ qTHgg7+OUjpZW0DgNrs9MHttFqipgeOrl66ogWC9SxLJ3oWlxnnYHq4JlCT9+r2C J6mk3qrjQWCRdBDLzo6gP5+65ueivDPols6VXf7UNoRR2eNYd+RsGaXqgSfnC9M= =Tsha -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi--