From: Gavin Andresen <gavinandresen@gmail.com>
To: Stefan Thomas <moon@justmoon.de>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Request review: drop misbehaving peers
Date: Thu, 15 Sep 2011 10:06:37 -0400 [thread overview]
Message-ID: <CABsx9T1_rOTd+sSgBTnj2iGKC2t7Rrh_pFAGtmWwjAKxaT0jdQ@mail.gmail.com> (raw)
In-Reply-To: <4E71F6D6.2090208@justmoon.de>
> Should the DoS protection auto-disable if the node has less than a minimum
> number of connections? The idea being that if our node seems to be kicking
> everybody off the roster maybe there is something wrong with the
> protections.
Darn good question. If the protection fails, would it be better for it
to 'fail hard', leaving people complaining "bitcoin won't stay
connected!"
Or fail soft, so you at least have a couple of connections.
I think fail hard is better-- we'll immediately know about the
problem, and can fix it. Fail soft makes me nervous because I think
that would make it more likely a bug splits the network (and,
therefore, the blockchain).
> It would be nice if the node sent a message to the banned peer with a code
> indicating the reason for the ban
If I think you're trying to DoS me, why would I be nice to you? I
think response messages would just give an attacker another potential
attack vector, and it is clear from the debug.log what triggers a ban.
> Should sending lots of messages that don't pass the protocol-level checksum
> test be a bannable offense? Or generally sending garbage data?
Good question. Anybody see a reason not to? How much tolerance (if
any) should there be for sending garbage data (I assume the
lower-level network stack almost never garbles data, is that a good
assumption)?
--
--
Gavin Andresen
next prev parent reply other threads:[~2011-09-15 14:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 1:57 [Bitcoin-development] Request review: drop misbehaving peers Gavin Andresen
2011-09-15 2:06 ` Luke-Jr
2011-09-15 10:43 ` Christian Decker
2011-09-15 12:56 ` kjj
2011-09-15 15:36 ` Luke-Jr
2011-09-15 16:04 ` kjj
2011-09-15 16:41 ` solar
2011-09-15 17:29 ` Luke-Jr
2011-09-15 16:19 ` Gavin Andresen
2011-09-15 17:41 ` Douglas Huff
[not found] ` <CABsx9T3HCVAn5ECuPWfAyZ4zt3WCbyKPF-7DV1HY2j2TKjavrg@mail.gmail.com>
2011-09-15 18:36 ` Douglas Huff
2011-09-15 19:07 ` Gavin Andresen
2011-09-15 11:45 ` Mike Hearn
2011-09-15 12:25 ` Gavin Andresen
2011-09-15 13:00 ` Stefan Thomas
2011-09-15 14:06 ` Gavin Andresen [this message]
2011-09-15 14:21 ` Gregory Maxwell
2011-09-15 16:21 ` Mike Hearn
2011-09-16 12:57 ` Joel Joonatan Kaartinen
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=CABsx9T1_rOTd+sSgBTnj2iGKC2t7Rrh_pFAGtmWwjAKxaT0jdQ@mail.gmail.com \
--to=gavinandresen@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=moon@justmoon.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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