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>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5ac2ac88_628c895d_7d7e"
Subject: [bitcoin-dev] Low-bandwidth transaction relay
Precedence: list

--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 &lt;-&gt; Node=5FA wil=
l be used to relay only a subset of transactions, NewNode &lt;-&gt; 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 &lt; 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--