From: Gregory Maxwell <gmaxwell@gmail•com>
To: "Warren Togami Jr." <wtogami@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Date: Fri, 16 Aug 2013 07:56:12 -0700 [thread overview]
Message-ID: <CAAS2fgQTbrYUz2XWtu2SApPT8tAaKxquuDgp9RjaNent+rnjdA@mail.gmail.com> (raw)
In-Reply-To: <CAEz79PqpQ0NG3WHHo7gqoZJVWqAQ4GwUaqSD_7LzWSvSQCHHig@mail.gmail.com>
On Fri, Aug 16, 2013 at 6:41 AM, Warren Togami Jr. <wtogami@gmail•com> wrote:
> If you disallow the same IP and/or subnet from establishing too many TCP
> connections with your node,
[...]
> has almost zero drawbacks,
There are whole countries who access the internet from single IP
addresses. There are major institution with hundreds or even thousands
of hosts that could be running Bitcoin who are visible to the public
internet as a single IP address (/single subnet). Most tor traffic
exits to the internet from a dozen of the largest exits, common
local-network configurations have people addnode-ing local hosts from
many systems on a subnet, etc.
Prioritizing the availability of inbound slots based on source IP is
reasonable and prudent, but it does not have almost zero drawbacks.
Outright limiting is even worse.
As a protective measure its also neigh useless for IPv6 connected
hosts and hidden service hosts. It's also ineffective at attacks
which exhaust your memory, cpu, IO, or bandwidth without trying to
exhaust your sockets.
So I am not opposed to prioritizing based on it (e.g. when full pick
an inbound connection to drop based on criteria which includes network
mask commonality), but I would not want to block completely based on
this.
next prev parent reply other threads:[~2013-08-16 14:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 1:00 Gavin Andresen
2013-08-16 4:06 ` Melvin Carvalho
2013-08-16 12:11 ` Mike Hearn
2013-08-16 12:24 ` Mike Hearn
2013-08-16 13:41 ` Warren Togami Jr.
2013-08-16 13:46 ` Mike Hearn
2013-08-16 13:53 ` Warren Togami Jr.
2013-08-16 14:06 ` Peter Todd
2013-08-16 14:56 ` Gregory Maxwell [this message]
2013-08-16 14:01 ` Peter Todd
2013-08-16 14:15 ` Peter Todd
2013-08-16 14:27 ` Warren Togami Jr.
2013-08-16 14:36 ` Mike Hearn
2013-08-16 14:59 ` Peter Todd
2013-08-16 15:06 ` Warren Togami Jr.
2013-08-16 15:11 ` Mike Hearn
2013-08-16 15:13 ` Mike Hearn
2013-08-16 15:59 ` Peter Todd
2013-08-17 0:08 ` Warren Togami Jr.
2013-08-17 12:35 ` Mike Hearn
2013-08-17 13:41 ` Jeff Garzik
2013-08-19 3:09 ` John Dillon
2013-08-19 3:17 ` Peter Todd
2013-08-19 5:00 ` John Dillon
2013-08-19 5:34 ` John Dillon
2013-08-19 5:11 ` Mark Friedenbach
2013-08-19 9:16 ` Mike Hearn
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=CAAS2fgQTbrYUz2XWtu2SApPT8tAaKxquuDgp9RjaNent+rnjdA@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=wtogami@gmail$(echo .)com \
/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