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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
Return-Path: <naumenko.gs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 557ACEE2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Apr 2018 22:18:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl0-f50.google.com (mail-pl0-f50.google.com
[209.85.160.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4AC085F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Apr 2018 22:18:22 +0000 (UTC)
Received: by mail-pl0-f50.google.com with SMTP id v18-v6so4054969ply.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 02 Apr 2018 15:18:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=date:from:to:message-id:subject:mime-version;
bh=z2sxXtT/vwLT7mLIuX66a6Ms3h6IBu7c5vB8ADtm+hw=;
b=M1RXXgCDNvAVqSjtYteOvBGQaKqF+hOBEznloub35mPvZjcSCx1/bmEQFW4rw38UCA
4h1S608u0jC5Y0NjNCQmhq97D5S2DhIj8in7QgN16qQNnWQOhHR5p7m0UFwSo/p58hwN
nIZpcq8KX1QTUuYqKGX9d5hNOE1bJ5mkYSwnqCATEMrVNMf08gMg+V6VcdNheY87tnUy
DM7kJbwVN+3GZeu7RZjcYRxYstUgb1TQEvniPdZWcvRHCr2DIcf2J+uRUmMVMuW5kd7J
AtS6I+Y9EiW8b0sy3ViTZCyyU8A8Ms4r7bp1wwVRkpRUbg+fAChVvOY0v77VpymZbyha
rk0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:message-id:subject:mime-version;
bh=z2sxXtT/vwLT7mLIuX66a6Ms3h6IBu7c5vB8ADtm+hw=;
b=BYRHFM6IAlBrwZK1FRa6iZozZR0H/2EbmSM+hVA7Dq9o75idlHQW4zx8bOWir6ONwU
zF2xFpiyXciD7I1rbNxyIrWssW50Pyequ2XAZRshTOIjSv8dq1w++EjrYrc2uYcEwqko
u1pcJffzd6N1kPfsXi3vD68Sr8flD0sGJE2uUyIZiYrToxlRSX0huuwKqBDDtHTcxIgh
6b+o3GcdAGFJGU69gLW9FUx+ueXKNmM6UDHQDi3N/CCq0QZoPq5WZ1PMhFm5i/bQyVPr
yD7NeIKGaiyX50sMDqvfb46sLI9DvuY0Cs3pzIREjSkgRilIuWmQmlpk6N66wjjRdYY5
Pczw==
X-Gm-Message-State: AElRT7HJKujtp6iPpLCGhGST4uK+TUEm1Y9je3du2u2fYt7sRDkLBa0h
qxCPTGQwQ5mOoWYqIwfpL8P1X0Br
X-Google-Smtp-Source: AIpwx48CZO+i2wwtP39XrTQHpI6gIQ2kYsOjHMjLKzg5ml1YyJ/b3n9RdYk2NQiFfPZE1Kje5KbMlQ==
X-Received: by 2002:a17:902:988f:: with SMTP id
s15-v6mr11251727plp.57.1522707501434;
Mon, 02 Apr 2018 15:18:21 -0700 (PDT)
Received: from [206.87.122.5] (dhcp-206-87-122-5.ubcsecure.wireless.ubc.ca.
[206.87.122.5]) by smtp.gmail.com with ESMTPSA id
g11sm2076901pfi.15.2018.04.02.15.18.19
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 02 Apr 2018 15:18:20 -0700 (PDT)
Date: Mon, 2 Apr 2018 15:18:07 -0700
From: Gleb Naumenko <naumenko.gs@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <9ab6e32e-db51-4ce4-8f3c-3a77f7b1f9bd@Spark>
X-Readdle-Message-ID: 9ab6e32e-db51-4ce4-8f3c-3a77f7b1f9bd@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5ac2ac88_628c895d_7d7e"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 03 Apr 2018 00:05:40 +0000
Subject: [bitcoin-dev] Low-bandwidth transaction relay
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2018 22:18:23 -0000
--5ac2ac88_628c895d_7d7e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi all,
I have a couple of ideas regarding transaction relay protocol and wanted =
to share it with and probably get some feedback.
I did some emulation and simulation and found out that around 90% of INV =
messages sent by public-IP nodes are idle (duplicate), obviously because =
each node creates 8 connections. =C2=A0I also realized that sending INV m=
essages is a significant part of the overall bandwidth consumed by a publ=
ic-IP node. At a larger scale, this will result in people not able to run=
a public-IP node.
My idea is in some sense similar to BIP37 but applied to public-IP nodes.=
Here I want to emphasize that all the nodes will still receive *all* of =
the transactions. A new protocol should also keep the same zero-trust, ro=
bustness, decentralization guarantees and latency.
Idea: while joining the network, a new node agrees on some filter with ea=
ch of 8 nodes it connects to. So that NewNode <-> Node=5FA will be used t=
o relay only a subset of transactions, NewNode <-> Node=5FB for another s=
ubset. This will significantly decrease the redundancy.
To keep the guarantees, I would keep some redundancy (for example, each t=
ransaction INV is sent over 2 links).
To make it robust to attacks, I have 2 extensions in my mind:
1. Set reconciliation (for a subset of transactions) with *other* nodes. =
Getting a bloom filter of a subset of the mempool transactions from Node=5F=
B may help to figure out whether Node=5FA is malicious, very slow, etc.
2. Rotating the filters every N minutes (N < 10)
I can see some issues with latency here, but I believe this problem has a=
solution.
=46eedback is appreciated=21
If you want to look at a draft of the proposal =E2=80=94 please let me kn=
ow.
If there were any similar ideas =E2=80=94 please let me know.
Best,
Gleb
--5ac2ac88_628c895d_7d7e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22 style=3D=22font-size: 14px; font-fam=
ily: -apple-system, BlinkMacSystem=46ont, sans-serif;=22>
<div>Hi all,</div>
<div>I have a couple of ideas regarding transaction relay protocol and wa=
nted to share it with and probably get some feedback.</div>
<div><br /></div>
<div>I did some emulation and simulation and found out that around 90% of=
INV messages sent by public-IP nodes are idle (duplicate), obviously bec=
ause each node creates 8 connections. &=23160;I also realized that sendin=
g INV messages is a significant part of the overall bandwidth consumed by=
a public-IP node. At a larger scale, this will result in people not able=
to run a public-IP node.</div>
<div><br /></div>
<div>My idea is in some sense similar to BIP37 but applied to public-IP n=
odes. Here I want to emphasize that all the nodes will still receive *all=
* of the transactions. A new protocol should also keep the same zero-trus=
t, robustness, decentralization guarantees and latency.</div>
<div><br /></div>
<div>Idea: while joining the network, a new node agrees on some filter wi=
th each of 8 nodes it connects to. So that NewNode <-> Node=5FA wil=
l be used to relay only a subset of transactions, NewNode <-> Node=5F=
B for another subset. This will significantly decrease the redundancy.</d=
iv>
<div><br /></div>
<div>To keep the guarantees, I would keep some redundancy (for example, e=
ach transaction INV is sent over 2 links).</div>
<div><br /></div>
<div>To make it robust to attacks, I have 2 extensions in my mind:&=23160=
;</div>
<div>1. Set reconciliation (for a subset of transactions) with *other* no=
des. Getting a bloom filter of a subset of the mempool transactions from =
Node=5FB may help to figure out whether Node=5FA is malicious, very slow,=
etc.</div>
<div>2. Rotating the filters every N minutes (N < 10)</div>
<div><br /></div>
<div>I can see some issues with latency here, but I believe this problem =
has a solution.</div>
<div><br /></div>
<div>=46eedback is appreciated=21</div>
<div><br /></div>
<div>If you want to look at a draft of the proposal =E2=80=94 please let =
me know.</div>
<div>If there were any similar ideas =E2=80=94 please let me know.</div>
<div><br /></div>
<div>Best,</div>
<div>Gleb</div>
</div>
<div name=3D=22messageReplySection=22 style=3D=22font-size: 14px; font-fa=
mily: -apple-system, BlinkMacSystem=46ont, sans-serif;=22><br />
<div></div>
</div>
</body>
</html>
--5ac2ac88_628c895d_7d7e--
|
