From: Gavin Andresen <gavinandresen@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Request review: drop misbehaving peers
Date: Wed, 14 Sep 2011 21:57:00 -0400 [thread overview]
Message-ID: <CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com> (raw)
I'm looking for review of this pull request:
https://github.com/bitcoin/bitcoin/pull/517
The big idea: if a peer is sending you obviously wrong information,
punish it by maybe dropping your connection to it, and ban it's IP
address so it cannot immediately re-connect.
The probability of dropping the connection, and the length of the ban,
depend on how how potentially wasteful/damaging the peer is behaving.
So sending an extra 'version' message is a minor transgression that is
usually tolerated, sending a more-than MAX_BLOCK_SIZE block is a major
transgression that gets the peer disconnected immediately.
Detailed how-it-works, using "I got a version message I wasn't
expecting" as the specific example:
Getting an unexpected version message from a peer increases that
peer's 'misbehaving' score by 10, and (assuming that is the peer's
first bad behavior) gives it a 10% chance of being disconnected. If
it is disconnected, then that peer's IP address is banned from
connecting for a couple of hours. If it is not disconnected, then
nothing happens unless the peer misbehaves again; if it does, then its
chances of being disconnected go up, and the length of time it will be
banned increases.
Misbehavior/ban information is stored only in memory, and information
about misbehaving peers is never broadcast. Also, peers that are
disconnected/banned are just dropped, there is no warning or reason
sent.
I think this will eliminate a lot of potential denial-of-service
attacks, and could be a good framework for responding to other
potential attacks. "We" should still look through the code and limit
the potential size of any data structures that an attacker might
target (transaction pool, orphan block pool); the DoSprevention
changes are meant to make it harder for an attacker to stay connected
long enough to pull off an attack.
The danger is that I got something wrong; what if an attacker can
leverage the DoSprevention code to split or shatter the network?
Here's my thinking on that, please help check my work:
+ I'm relying on TCP to prevent IP address spoofing (otherwise an
attacker could force you to disconnect from your peers by pretending
to be them and sending you a bad block).
+ Peers are only penalized for sending messages that won't, and
shouldn't, get relayed. So an attacker shouldn't be able to poison the
network with a bad message that is propogated and then causes
everybody to disconnect from everybody else.
+ I specifically do not punish peers for relaying what look like
double-spend transactions. If I did, then an attacker could try to
segment the network into two pieces by broadcasting a series of
double-spends from two halves of the network, and waiting until the
nodes "in the middle" disconnected/banned across the 'seam'.
So: please let me know if or how I'm being an idiot.
--
--
Gavin Andresen
next reply other threads:[~2011-09-15 1:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 1:57 Gavin Andresen [this message]
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
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='CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.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