diff options
| author | Peter Todd <pete@petertodd.org> | 2013-04-18 05:04:44 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-04-18 09:05:02 +0000 |
| commit | 8bec78cb502ee66061c2483882ce2a37a746f695 (patch) | |
| tree | 6f2b21c2b93372a73e171e2adefa0186054b9666 /ff | |
| parent | b697401f79d28bbadfa3b22d467a5ecf96c51bcc (diff) | |
| download | pi-bitcoindev-8bec78cb502ee66061c2483882ce2a37a746f695.tar.gz pi-bitcoindev-8bec78cb502ee66061c2483882ce2a37a746f695.zip | |
Re: [Bitcoin-development] Anti DoS for tx replacement
Diffstat (limited to 'ff')
| -rw-r--r-- | ff/3fd8d5dc58850eaff1b02aff0e79c5be82f492 | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/ff/3fd8d5dc58850eaff1b02aff0e79c5be82f492 b/ff/3fd8d5dc58850eaff1b02aff0e79c5be82f492 new file mode 100644 index 000000000..44eb6df1c --- /dev/null +++ b/ff/3fd8d5dc58850eaff1b02aff0e79c5be82f492 @@ -0,0 +1,177 @@ +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 <pete@petertodd.org>) 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 <pete@petertodd.org> +To: Mike Hearn <mike@plan99.net> +Message-ID: <20130418090444.GA30995@savin> +References: <CANEZrP1yKeQMayFHsEUWtA3=q+v5rPAutjzEFVVHopPGNZ4jGQ@mail.gmail.com> + <453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com> + <CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com> + <CAPaL=UVJd3mdd0bs6Oo9vFHnv_6RbFowjmp0tD-ZbOzZxJEJ3g@mail.gmail.com> + <CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" +Content-Disposition: inline +In-Reply-To: <CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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-- + + |