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
77
78
79
80
81
82
83
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1XJRpO-0004rM-O6
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 18:38:46 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.181 as permitted sender)
client-ip=209.85.213.181; envelope-from=laanwj@gmail.com;
helo=mail-ig0-f181.google.com;
Received: from mail-ig0-f181.google.com ([209.85.213.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XJRpO-0006SS-4H
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 18:38:46 +0000
Received: by mail-ig0-f181.google.com with SMTP id h3so8477336igd.14
for <bitcoin-development@lists.sourceforge.net>;
Mon, 18 Aug 2014 11:38:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.39.8 with SMTP id l8mr701121igk.13.1408387120606; Mon, 18
Aug 2014 11:38:40 -0700 (PDT)
Received: by 10.64.1.209 with HTTP; Mon, 18 Aug 2014 11:38:40 -0700 (PDT)
In-Reply-To: <CAAS2fgT5-s-uukP8uTRKJ+pzwG-f9knetH44qQ78HsctG9_cZA@mail.gmail.com>
References: <20140818164543.GB31175@localhost.localdomain>
<CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
<CAPg+sBgzEMAQ03GTE2j82+K2B+Dia6T0z14ZYWsBQ8z8QSVoLg@mail.gmail.com>
<CAAS2fgRT8OQzUkneKwpjD15aLZDivT=hgBMTB63EjN8RBrp+RQ@mail.gmail.com>
<CAAS2fgT5-s-uukP8uTRKJ+pzwG-f9knetH44qQ78HsctG9_cZA@mail.gmail.com>
Date: Mon, 18 Aug 2014 20:38:40 +0200
Message-ID: <CA+s+GJAV+YBDmDVk9Nvo_qAjk=WEBPhX-kqkX1fiUsLfGvEUkw@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: text/plain; charset=UTF-8
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
(laanwj[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
X-Headers-End: 1XJRpO-0006SS-4H
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Outbound connections rotation
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: Mon, 18 Aug 2014 18:38:46 -0000
> The optimal strategy for avoiding linkages (ignoring tor, again), is
> to randomly pick a different peer for each transaction and relay the
> transaction only to that peer. This can (and probably should) be
> distinct from your normal network connectivity.
It already happens with 8 peers that if you have lousy peers, the
transaction doesn't reach the network on the first broadcasting. When
sending to only one random peer it will likely be even worse.
I guess the wallet could send out the transaction 'staggered' over
time. It could pick a random new node, broadcast the transaction, wait
a bit, pick a new node, broadcast the transaction until it is comes
back through one of the other peers.
Separating the transaction broadcasting (of the wallet) from, for
example, the nodes used to request blocks from could make sense. Maybe
doubly so if bloom filters are involved.
Wladimir
|
