From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1USkm6-0005Xi-Pl for bitcoin-development@lists.sourceforge.net; Thu, 18 Apr 2013 09:05:02 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.110 as permitted sender) client-ip=62.13.148.110; envelope-from=pete@petertodd.org; helo=outmail148110.authsmtp.com; Received: from outmail148110.authsmtp.com ([62.13.148.110]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1USkm4-0007MX-P8 for bitcoin-development@lists.sourceforge.net; Thu, 18 Apr 2013 09:05:02 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r3I94rQt007520; Thu, 18 Apr 2013 10:04:53 +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 r3I94iNm040107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 10:04:47 +0100 (BST) Date: Thu, 18 Apr 2013 05:04:44 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20130418090444.GA30995@savin> References: <453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 05918ffe-a807-11e2-b5c5-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwoUGUUGAgsB AmUbWlReUFl7XWs7 bAxPbAVDY01GQQRq WVdMSlVNFUsqAmUI AkdgDxl2dwRGfzBy ZE5kXj5bWU17fRAr F1MFHW0BeGZhPWIC AkULch5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4iGCI9 DzwFJn0hGldNWzV7 NRE+LlcXEUMcNFla 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: 1USkm4-0007MX-P8 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:05:03 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 18, 2013 at 10:32:24AM +0200, Mike Hearn wrote: > RE: shutting down services dependent on replacement. No, good users of > replacement would still end up taking priority over the constantly churni= ng > DoS replacements. The most you can shut down is one contract. Obviously, = if > there's no form of tx replacement at all then the "tried and doesn't work" > state is the same as "never tried", which doesn't seem like a win. Yeah, an attack is a bit more subtle than perhaps John Dillon realizes. Assuming that nodes prioritize the transactions with the fewest total replacements first it becomes a multiplier on the standard attack of just broadcasting transactions. So for non-replacement users it's probably not that bad. 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. What's worse, the attack itself can be just a large number of these micropayment sessions, IE, no bogus sessions at all. > The testnet is trivially DoSable today by anyone who cares to do so, there > are hardly any nodes and most people get coins from the faucet. Look at h= ow It's *easily* DoSable, not trivially. Testnet has all the same fee/priority rules that Bitcoin has, so any attack still costs some amount of coins. For instance I did the math once on what it would cost to flood testnet with 1MB blocks, and it came out to IIRC $100/month or so in terms of lost mining revenue. Small, but still not trivial. non-final nLockTime floods and timewarp assisted can be easily done mind you, but the former is easy to fix and the latter is relatively tricky to pull off and still requires some mining expenditure. > Your proposed alternative doesn't seem any different DoS wise. Someone can > still broadcast a long series of incrementally different transactions and > have miners replace them. So you still need prioritisation of work. It's > useful anyway for other reasons. And as you point out yourself, it's still > susceptible to the problem that you end up running out of money because > it's all been spent on fees. John's proposing something that would work in conjunction with fees, so it's no different than the MIN_RELAY_FEE that has quite successfully prevented flooding on mainnet. For that matter, what he proposed can be used even with non-final =3D=3D non-standard, which means the replacement transactions can't be broadcast onto the network at all until they can be mined. Actually, that's an interesting point: one way to do replacement anti-DoS would be to only allow each input a given number of chances to do a replacement. Provided your design is asymmetric in who the attacker would be, and the inputs controlled by the defender outnumber the attacker, the defender can always count on doing the last replacement. You would need some way of determining which input was responsible for a replacement though - I can't think of an obvious way to within the current transaction format, but I haven't thought hard about it yet. How exactly do you envision replacement working with non-final =3D=3D non-standard anyway? > BTW $500 is rather low for the amount of work required. If you added a ze= ro > onto that there might be more takers. If he's reasonable about the scope, IE just a initial implementation for further evaluation, I figure it's about two days work. $250/day is enough that I'd give it a go - I already looked into how to implement it anyway. --=20 'peter'[:-1]@petertodd.org --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRb7crAAoJEH+rEUJn5PoEPegH/Atzltgd5shwlTjc3FMR99BY oN1k5j89fHI0EYYQpYGeMBFEW3FXZ4X4BSPhoR/juf+nUj69567m7d5XbJm+U96Z S97jIjk/sqMh5/MQXu1GC0MdfVKOCRXT1GG65pfeKNMUminFKwHCB+QUw5NuXhaO 2i+DHZRSO3o2hqiC75tUfANe8gE/RGr/0fRBZA1vZsdqz4KHTh5po1qqWWtOwSpo 9n18+Hghx7qlDdp627Qs0pwEXjyBuQTpukjpVTBAIy82hT9Yh0fLC5NFMSxx6nsb mnGCTNf+ow/hU83BXSnNP+GEmpJdmdy0/WtaafESf8rKMIIRTL9GrFXq07ktlM4= =i+kQ -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o--