diff options
| author | Mike Hearn <mike@plan99.net> | 2013-04-18 12:19:43 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-04-18 10:19:50 +0000 |
| commit | 45350f686e2b378be5d4307ffdaeada4d1c10087 (patch) | |
| tree | 88fd1b283b0325a19ae0068fe6043c3a163698fa /60/8726ed1a271d883cc638cedd371bfa05efc720 | |
| parent | 1a46f22d5e214f228b6de642b6b9131abacf0796 (diff) | |
| download | pi-bitcoindev-45350f686e2b378be5d4307ffdaeada4d1c10087.tar.gz pi-bitcoindev-45350f686e2b378be5d4307ffdaeada4d1c10087.zip | |
Re: [Bitcoin-development] Anti DoS for tx replacement
Diffstat (limited to '60/8726ed1a271d883cc638cedd371bfa05efc720')
| -rw-r--r-- | 60/8726ed1a271d883cc638cedd371bfa05efc720 | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/60/8726ed1a271d883cc638cedd371bfa05efc720 b/60/8726ed1a271d883cc638cedd371bfa05efc720 new file mode 100644 index 000000000..380aad1b7 --- /dev/null +++ b/60/8726ed1a271d883cc638cedd371bfa05efc720 @@ -0,0 +1,139 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1USlwU-0004oD-CH + for bitcoin-development@lists.sourceforge.net; + Thu, 18 Apr 2013 10:19:50 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.219.46 as permitted sender) + client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com; + helo=mail-oa0-f46.google.com; +Received: from mail-oa0-f46.google.com ([209.85.219.46]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1USlwT-0006q3-H1 + for bitcoin-development@lists.sourceforge.net; + Thu, 18 Apr 2013 10:19:50 +0000 +Received: by mail-oa0-f46.google.com with SMTP id h2so2573069oag.19 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 18 Apr 2013 03:19:44 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.182.60.136 with SMTP id h8mr5010760obr.47.1366280384109; + Thu, 18 Apr 2013 03:19:44 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.167.169 with HTTP; Thu, 18 Apr 2013 03:19:43 -0700 (PDT) +In-Reply-To: <20130418100806.GA13908@savin> +References: <CANEZrP1yKeQMayFHsEUWtA3=q+v5rPAutjzEFVVHopPGNZ4jGQ@mail.gmail.com> + <453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com> + <CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com> + <CAPaL=UVJd3mdd0bs6Oo9vFHnv_6RbFowjmp0tD-ZbOzZxJEJ3g@mail.gmail.com> + <CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com> + <20130418090444.GA30995@savin> + <CANEZrP0AYaWnVhrAbMXP0BGhb=CZMg_-PYVzwKbcCoRKC9V2rw@mail.gmail.com> + <20130418100806.GA13908@savin> +Date: Thu, 18 Apr 2013 12:19:43 +0200 +X-Google-Sender-Auth: ePaEmuD66Z5qsNCfguHJTnFqHRw +Message-ID: <CANEZrP0T7y8jqhMDUsf-HNw1sJnVuXngMa3x5+O5qgRE6eswew@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Peter Todd <pete@petertodd.org> +Content-Type: multipart/alternative; boundary=001a11c1c420f5667104da9ff00e +X-Spam-Score: -0.5 (/) +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 + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + 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 +X-Headers-End: 1USlwT-0006q3-H1 +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Anti DoS for tx replacement +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, 18 Apr 2013 10:19:50 -0000 + +--001a11c1c420f5667104da9ff00e +Content-Type: text/plain; charset=UTF-8 + +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. + +--001a11c1c420f5667104da9ff00e +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div= + style>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 f= +or the calculations, that isn't exactly unlimited. My home internet con= +nection 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 replacement= +s, an attacker would have a hard time matching up his flood with when a blo= +ck is actually solved.</div> +<div><br></div><div style>On the wider point - how many people DoS things w= +ith 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 gigabi= +t+, 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 openin= +g up new DoS attacks, but we should also be realistic about what can be acc= +omplished. The kind of people trying to manipulate Mt Gox could nuke the en= +tire P2P network off the face of the internet with the flick of a switch, p= +resumably the reason they aren't doing that it would to use Satoshi'= +;s phrasing "undermine the validity of their own wealth".</div> +<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = +0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l= +eft-style:solid;padding-left:1ex"> +<div class=3D"im"><span style=3D"color:rgb(34,34,34)">sure it's worth d= +oing, at least immediately. Weakening the non-final =3D=3D</span><br></div>= +</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = +0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-= +style:solid;padding-left:1ex"> + +non-standard test to give a window of, say, 3 blocks, would be fine I<br> +think.<br></blockquote><div><br></div><div style>Sure. I think Gavin wants = +some kind of wider memory pool limiter policy which would encompass such a = +thing already.</div></div></div></div> + +--001a11c1c420f5667104da9ff00e-- + + |