<p></p>
<blockquote>
<p>Why would a Bisq node need to send so much data to its seednode(s)?</p>
</blockquote>
<ul>
<li>
<p>sorry, I took that as common knowledge, because that is how Bisq always worked</p>
</li>
<li>
<p>let the ELI5 commence:</p>
<ol>
<li>on startup, the Bisq app asks the seed node for a "distributed-database update"</li>
<li>In order to not burden the seednode to send all the data (> 12MB), Bisq tells the seednode which objects it already has (ie. sends data to the seednode).</li>
<li>The seed node then only sends the data the bisq app does not have already.</li>
</ol>
</li>
<li>
<p>The trouble comes with success: We now have more than 100k objects in the "distributed database" which makes bisq send 100k "keys" to the seednode (100k * 20byte hash = 2MByte = substantial, and rising).</p>
</li>
<li>
<p>And because that is not enough: for redundancy purposes, the Bisq app asks two seednodes for data</p>
</li>
<li>
<p>given a "bad" internet connection, Bisq simply fails to start</p>
<ul>
<li>ie. if net upstream is < 35kB/s = 280kb/s (= 4MB/120 second connection timeout)</li>
<li>does not seem like a lot, but there are bug reports (labeled critical bug) out there and I encountered it myself while not at home</li>
<li>Tor is not at fault: p50 of tor speed is <a href="https://metrics.torproject.org/advbwdist-perc.html?start=2020-01-02&end=2020-04-01&p=100&p=50" rel="nofollow">28Mb/s</a></li>
<li>we need more bandwidth as time goes on (because the database grows -> the number of objects grows -> the request size grows)</li>
<li>if we succeed with bisq, the required bandwidth will outgrow infrastructure development</li>
</ul>
</li>
</ul>
<blockquote>
<p>Do you intend here to check these binary blobs into the main Bisq repository, or something else? I would really like to avoid adding more binary data to the repository (as we're already doing with all the stuff in <code>p2p/src/main/resources</code>).</p>
</blockquote>
<p>yes, I intend to check these binary blobs into the main Bisq repository. It is exactly about the stuff in <code>p2p/src/main/resources</code> which is a snapshot of the "distributed-database" we ship with each release.</p>
<ul>
<li>Atm, there is only one blob that gets bigger and bigger. Plus it replaces the old one, so repo size grows with <code>size(t) = size(t-1)+size(newData)</code> per release. (actually, it is several files for different message types, but overall, it is one blob of data)</li>
<li>after this project is done, a new blob will be added for every release with <code>size(t) = size(newData)</code>, the "old" blobs are left untouched and are used as they are (historical data does not change)</li>
<li>doing it that way is a very minimal change to the current release processes and we can focus on fixing the real issue quickly</li>
</ul>
<blockquote>
<p>I'd like us to look into doing this properly with Git LFS instead</p>
</blockquote>
<ul>
<li>I totally agree that we have to move away from committing binary data to the repo, but
<ul>
<li>using [<em>insert your favorite storage technology here</em>] does not collide with this project</li>
<li>can be done later</li>
<li>should be done sooner than later</li>
<li>will look into Git LFS as a followup-project</li>
</ul>
</li>
</ul>
<p>All in all, this project aims for making small steps towards a more reliable service. Rethinking the storage synchronization is a whole other can of worms.</p>
<p>Btw. just checked. We have 110k objects now, at the time of project creation it has been 104k -> approx. +5% in 25 days.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/projects/issues/25#issuecomment-607206262">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNWXBSJNAUM2E3DXFF3RKMT7JANCNFSM4LCOORUA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNTDDJWZJHCCIBWSRZTRKMT7JA5CNFSM4LCOORUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEQYTW5Q.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/projects/issues/25#issuecomment-607206262",
"url": "https://github.com/bisq-network/projects/issues/25#issuecomment-607206262",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>