From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
Date: Thu, 18 Apr 2013 05:04:44 -0400 [thread overview]
Message-ID: <20130418090444.GA30995@savin> (raw)
In-Reply-To: <CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3799 bytes --]
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 churning
> 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 how
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 == 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 ==
non-standard anyway?
> BTW $500 is rather low for the amount of work required. If you added a zero
> 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.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-04-18 9:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 17:39 Mike Hearn
2013-04-16 18:43 ` Peter Todd
2013-04-17 9:48 ` Mike Hearn
2013-04-17 19:44 ` Alan Reiner
2013-04-18 6:07 ` John Dillon
2013-04-18 8:14 ` Peter Todd
2013-04-19 4:38 ` John Dillon
2013-04-19 4:55 ` Jeff Garzik
2013-04-18 8:32 ` Mike Hearn
2013-04-18 9:04 ` Peter Todd [this message]
2013-04-18 9:28 ` Peter Todd
2013-04-18 9:32 ` Mike Hearn
2013-04-18 9:28 ` Mike Hearn
2013-04-18 9:34 ` Mike Hearn
2013-04-18 10:08 ` Peter Todd
2013-04-18 10:19 ` Mike Hearn
2013-04-18 13:37 ` Gavin Andresen
[not found] ` <CAD0SH_WOG8jQvzsNzwud3fYjaxqTJo0CS7yP6XZeKvap_yqtqg@mail.gmail.com>
2013-04-17 9:19 ` Mike Hearn
2013-04-20 1:48 Jeremy Spilman
2013-07-18 11:13 ` Peter Todd
2013-07-18 12:53 ` Jeff Garzik
2013-07-18 13:43 ` Peter Todd
2013-07-18 16:09 ` Peter Todd
2013-04-20 20:51 Jeremy Spilman
2013-04-22 11:07 ` Mike Hearn
2013-04-23 12:40 ` John Dillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130418090444.GA30995@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox