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 ) id 1VgmSZ-0000Wo-8A for bitcoin-development@lists.sourceforge.net; Thu, 14 Nov 2013 02:15:07 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bluematt.me designates 192.241.179.72 as permitted sender) client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from mail.bluematt.me ([192.241.179.72]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1VgmSX-0008BO-8o for bitcoin-development@lists.sourceforge.net; Thu, 14 Nov 2013 02:15:07 +0000 Received: from [10.232.233.22] (vps.bluematt.me [173.246.101.161]) by mail.bluematt.me (Postfix) with ESMTPSA id 43F7548FA3; Thu, 14 Nov 2013 02:14:59 +0000 (UTC) Message-ID: <52843221.8010606@bluematt.me> Date: Wed, 13 Nov 2013 21:14:57 -0500 From: Matt Corallo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: John Dillon References: <5279D89D.5000609@bluematt.me> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1VgmSX-0008BO-8o Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network 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, 14 Nov 2013 02:15:07 -0000 In the short-term, maybe. Keep in mind that the code for tx relay is fairly different and the bandwidth for transaction relay on these nodes is already lower than it is for blocks (by design). That said, I'd like to look into doing tx-less block relays for transactions that peers already have to limit block relay times even for large blocks, in which case tx relay is very much required. Matt On 11/13/13 15:13, John Dillon wrote: > You should split the block-only and block+tx not only by port > number, but also by DNS address. DoS attack by flooding blocks is > fundamentally more difficult than DoS attack by flooding > transctions, so doing the split by IP address ensures that in the > event of an attack the more important block relaying functionality > is less likely to be damaged. In the meantime point both DNS > addresses to the same IP until it becomes an issue. > >