diff options
| author | Gavin Andresen <gavinandresen@gmail.com> | 2011-09-15 12:19:45 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-09-15 16:19:52 +0000 |
| commit | 4251f7c0d9fb37e93f18954b0482c35d53b92935 (patch) | |
| tree | 57eb71e482c669635d0d05de7ca61f9c0647a830 | |
| parent | 164d61642d5f9efaa119df663c58b59de7c8eb06 (diff) | |
| download | pi-bitcoindev-4251f7c0d9fb37e93f18954b0482c35d53b92935.tar.gz pi-bitcoindev-4251f7c0d9fb37e93f18954b0482c35d53b92935.zip | |
Re: [Bitcoin-development] Request review: drop misbehaving peers
| -rw-r--r-- | 43/c6a321ea28411166be4d4376fb52c8384d4857 | 115 |
1 files changed, 115 insertions, 0 deletions
diff --git a/43/c6a321ea28411166be4d4376fb52c8384d4857 b/43/c6a321ea28411166be4d4376fb52c8384d4857 new file mode 100644 index 000000000..63c0ebfde --- /dev/null +++ b/43/c6a321ea28411166be4d4376fb52c8384d4857 @@ -0,0 +1,115 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gavinandresen@gmail.com>) id 1R4EfI-0002TM-74 + for bitcoin-development@lists.sourceforge.net; + Thu, 15 Sep 2011 16:19:52 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.161.47 as permitted sender) + client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com; + helo=mail-fx0-f47.google.com; +Received: from mail-fx0-f47.google.com ([209.85.161.47]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1R4EfH-0004EQ-F9 + for bitcoin-development@lists.sourceforge.net; + Thu, 15 Sep 2011 16:19:52 +0000 +Received: by fxi1 with SMTP id 1so1109767fxi.34 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 15 Sep 2011 09:19:45 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.223.63.8 with SMTP id z8mr36733fah.84.1316103585132; Thu, 15 + Sep 2011 09:19:45 -0700 (PDT) +Received: by 10.152.25.105 with HTTP; Thu, 15 Sep 2011 09:19:45 -0700 (PDT) +In-Reply-To: <201109151136.47485.luke@dashjr.org> +References: <CABsx9T2MKTYCeOqERXKBMYEqNEK4eo9jGt81gZE1=Fv=s3wEqA@mail.gmail.com> + <201109142206.40455.luke@dashjr.org> <4E71F5F8.2020807@jerviss.org> + <201109151136.47485.luke@dashjr.org> +Date: Thu, 15 Sep 2011 12:19:45 -0400 +Message-ID: <CABsx9T2kQTAA77Q=qYc2iKNftQSd8ficfhcXL2W6kX0JUhe3Dw@mail.gmail.com> +From: Gavin Andresen <gavinandresen@gmail.com> +To: bitcoin-development@lists.sourceforge.net +Content-Type: text/plain; charset=ISO-8859-1 +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (gavinandresen[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature + 0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service + -0.0 AWL AWL: From: address is in the auto white-list +X-Headers-End: 1R4EfH-0004EQ-F9 +Subject: Re: [Bitcoin-development] Request review: drop misbehaving peers +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Thu, 15 Sep 2011 16:19:52 -0000 + +I hate to get specific about potential attacks on a public mailing +list, but I think the debate over what to do with non-standard +transactions means we need to. + +I agree with Gregory; if there are NO rules about what transactions +peers can send at you, then an attacker can trivially get around other +the DoS rules. + +I also agree we need to think hard about what will happen when new +'standard' transaction types are deployed. + +There are two significant DoS attacks I can imagine using transactions +that will never be included in blocks. The "will never be included in +blocks" bit is important, because if an attacker can make you do +significant work at no cost to themselves then they win. And if the +transactions will never be included in blocks the attacker can include +lots of transaction fees that will never be spent. + +1) Exhaust memory by filling up the transaction memory pool. I think +another patch needs to be written to deal with that (keep the size of +the transaction pool reasonable by evicting low-priority +transactions). + +2) Waste CPU time validating transactions They can make you use an +arbitrary amount of CPU time just by flooding you with a stream of +valid-but-won't-ever-get-into-a-block transactions. + +The code already refuses to relay non-standard transactions, and +doesn't check their signatures or add them to the memory pool, so I +think no DoS check is needed for them (and would be harmful when we do +start supporting new standard transactions). + +It also drops transactions with "too few fees" before checking +signatures or doing other CPU-intensive work, so no I think no DoS +check is needed there, either (and again, would be harmful when +transaction fee rules change). + +I'm ignoring bandwidth DoS attacks-- we already have the +-maxreceivebuffer option to deal with those. + + +PS: I'll add Gregory's comment: + +"There should be nothing I can give a node that it will +forward on that will make that node's peers drop it. (and this needs +to remain true while forwarding rules evolve)" + +... as a comment in the code so hopefully we don't forget it. + +-- +-- +Gavin Andresen + + |