From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: <453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com> <20130418090444.GA30995@savin> <20130418100806.GA13908@savin> Date: Thu, 18 Apr 2013 12:19:43 +0200 X-Google-Sender-Auth: ePaEmuD66Z5qsNCfguHJTnFqHRw Message-ID: From: Mike Hearn To: Peter Todd 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.

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".
=C2=A0
sure it's worth d= oing, at least immediately. Weakening the non-final =3D=3D
=
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--