From: Mike Hearn <mike@plan99•net>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
Date: Thu, 18 Apr 2013 12:19:43 +0200 [thread overview]
Message-ID: <CANEZrP0T7y8jqhMDUsf-HNw1sJnVuXngMa3x5+O5qgRE6eswew@mail.gmail.com> (raw)
In-Reply-To: <20130418100806.GA13908@savin>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
Indeed, as I mentioned in my first mail, nodes can be told how much
bandwidth they're allowed to use and then prioritize within that, so I
don't see any way convergence can fail. And regardless, I used 10mbit for
the calculations, that isn't exactly unlimited. My home internet connection
is better than that. It's just an arbitrary choice that lets us get a feel
for the numbers. We can see that even with a lot of replacements, an
attacker would have a hard time matching up his flood with when a block is
actually solved.
On the wider point - how many people DoS things with their own bandwidth?
The point of DNS reflection and/or botnets is you use other peoples
bandwidth. The attacks on Mt Gox are supposedly 80 gigabit+, which is
enough to take out all of the main network simultaneously. We can't do
anything about that. So I agree we should work to avoid opening up new DoS
attacks, but we should also be realistic about what can be accomplished.
The kind of people trying to manipulate Mt Gox could nuke the entire P2P
network off the face of the internet with the flick of a switch, presumably
the reason they aren't doing that it would to use Satoshi's phrasing
"undermine the validity of their own wealth".
> sure it's worth doing, at least immediately. Weakening the non-final ==
>
non-standard test to give a window of, say, 3 blocks, would be fine I
> think.
>
Sure. I think Gavin wants some kind of wider memory pool limiter policy
which would encompass such a thing already.
[-- Attachment #2: Type: text/html, Size: 2139 bytes --]
next prev parent reply other threads:[~2013-04-18 10:19 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
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 [this message]
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=CANEZrP0T7y8jqhMDUsf-HNw1sJnVuXngMa3x5+O5qgRE6eswew@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/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