<div dir="ltr">Hey. This idea sounds quite interesting. It'd be helpful to see some more numbers to evaluate it.<div><br></div><div>- How much bandwidth is consumed by redundant tx INVs currently? What is this as a % of overall bandwidth usage?</div><div>- How would filtering txs through N=2 links affect network propagation? This probably requires simulation to determine.</div><div>- Do you propose setting filters on inbound peers as well?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 2, 2018 at 3:18 PM, Gleb Naumenko via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">
<div>Hi all,</div>
<div>I have a couple of ideas regarding transaction relay protocol and wanted 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 because each node creates 8 connections. I also realized that sending 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 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, robustness, decentralization guarantees and latency.</div>
<div><br></div>
<div>Idea: while joining the network, a new node agrees on some filter with each of 8 nodes it connects to. So that NewNode <-> Node_A will be used to relay only a subset of transactions, NewNode <-> Node_B for another subset. This will significantly decrease the redundancy.</div>
<div><br></div>
<div>To keep the guarantees, I would keep some redundancy (for example, each 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: </div>
<div>1. Set reconciliation (for a subset of transactions) with *other* nodes. Getting a bloom filter of a subset of the mempool transactions from Node_B may help to figure out whether Node_A 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>Feedback is appreciated!</div>
<div><br></div>
<div>If you want to look at a draft of the proposal — please let me know.</div>
<div>If there were any similar ideas — please let me know.</div>
<div><br></div>
<div>Best,</div>
<div>Gleb</div>
</div>
<div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><br>
<div></div>
</div>
</div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>