summaryrefslogtreecommitdiff
path: root/6c/36bdd3f028906569d93b1d8673071ac24ef2e3
blob: 5005d8a7ffa8bfde4b1f840835e750517009bf11 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
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 <bitcoin-list@bluematt.me>) 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 <bitcoin-list@bluematt.me>
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 <john.dillon892@googlemail.com>
References: <5279D89D.5000609@bluematt.me>
	<CAPaL=UXyARJ21w6W2dGxJ23wgsGL3O9LD0yT0Ai7GJyJmKFZBw@mail.gmail.com>
In-Reply-To: <CAPaL=UXyARJ21w6W2dGxJ23wgsGL3O9LD0yT0Ai7GJyJmKFZBw@mail.gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <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, 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.
> 
>