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
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <keziahw@gmail.com>) id 1X8yEv-0003Bp-D4
for bitcoin-development@lists.sourceforge.net;
Sun, 20 Jul 2014 21:01:49 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.49 as permitted sender)
client-ip=209.85.218.49; envelope-from=keziahw@gmail.com;
helo=mail-oi0-f49.google.com;
Received: from mail-oi0-f49.google.com ([209.85.218.49])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X8yEu-0002wE-4h
for bitcoin-development@lists.sourceforge.net;
Sun, 20 Jul 2014 21:01:49 +0000
Received: by mail-oi0-f49.google.com with SMTP id u20so2868396oif.8
for <bitcoin-development@lists.sourceforge.net>;
Sun, 20 Jul 2014 14:01:42 -0700 (PDT)
X-Received: by 10.182.205.231 with SMTP id lj7mr4258104obc.37.1405890102668;
Sun, 20 Jul 2014 14:01:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.98.11 with HTTP; Sun, 20 Jul 2014 14:01:22 -0700 (PDT)
From: Kaz Wesley <keziahw@gmail.com>
Date: Sun, 20 Jul 2014 14:01:22 -0700
Message-ID: <CA+iPb=GVyfYAjSRitt8LW-LLvi8U5F=noQ9igOQKmHyi8-DACA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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
(keziahw[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: 1X8yEu-0002wE-4h
Subject: [Bitcoin-development] Trickle and transaction propogation
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: Sun, 20 Jul 2014 21:01:49 -0000
The inv trickling mechanism currently serves two purposes:
- protect casual users' privacy by slightly obscuring a tx's originating node
- reduce invs unnecessarily sent both directions for a connection
It has some drawbacks:
- it slows transaction propagation
- it delays knowledge between two nodes of what txes are mutually known
These drawbacks will be especially costly once optimizations based on
mutually-known transactions are available (in progress, see "sparse
blocks" thread).
Both of the benefits of trickling can be achieved more efficiently and
without the costs to transaction propagation and mutual transaction
knowledge.
Privacy: trickling helps hide the origin of 3/4 of the transactions a
node is pushing by preventing most of the node's neighbors from seeing
the transactions from that node right away; by the time a peer becomes
the trickle node, it may have received the same inv from another of
its peers.
This staggering of introduction of new invs to the network could be
made more effective by scheduling staggered pushes of wallet
transactions to each peer in a structure similar to mapAskFor.
This does have the drawback that someone who has established multiple
connections to a node can observe that some invs are pushed at
different times, suggesting they are in the stagger set. I don't see
any straightforward way to remedy this, but trickling is also
vulnerable to sybil attacks, and floods 1/4 of its transactions
immediately anyway -- so I think staggered push would be an overall
privacy improvement.
Likelihood of a partial sybil obtaining inv origin information could
be reduced by a policy of ending staggering and pushing to all peers
once another peer has received the tx from elsewhere and inved the
transaction back to the original node; if the staggering is
sufficiently slow, only one or two nodes would receive the initial
push to the network and after that the inv would be treated
indistinguishably from if it originated externally.
Redundant invs: without trickling, when two nodes receive transactions
at around the same time they may each send each other an inv before
receiving the other's. Trickling reduces this by giving all
non-trickleSend nodes a chance to send first. Thus just eliminating
trickling would at most double inv traffic. Although invs are small
they are numerous, being the only common message potentially sent from
every node to all its neighbors.
A more efficient solution to the who-sends-first problem would be for
connections to have directional parity:
- a node initiating a connection would announce its parity (even or odd)
- an inv is sent right away to peers with matching parity, but only
sent against parity if a certain timeout has elapsed without the inv
being received
In order to allow for nodes with few peers (i.e. -connect) or nodes on
local connections that might as well flood everything to each other,
parity could be specified as a mask (fEven << 1 & fOdd). Peers from
pre-directional-parity versions can be treated as having the mask
fully set.
Both push staggering and directional parity admit simple
implementations. The specific staggering delay distribution would need
some thought; it could be set slower than the typical trickle cycle
period for better than current privacy, since general transaction
propagation would not impeded by heavy staggering. What do you think
of this approach? Any gotchas/improvements/alternatives?
|
