<blockquote>
<pre><code>* base compensation: operating costs + 50 BSQ?
  * might prevent the use of cheap hosting providers
  * but might need an upper limit though. Maybe insert common operating costs of DigitalOcean, Linode, ...?
</code></pre>
</blockquote>
<p>sounds good, it does not prevent the use of cheap hosting providers but also doesn't encourage it. People will just choose the best tool for the job. Upper limit probably around 70/100 BSQ</p>
<blockquote>
<pre><code>* setup 400 BSQ (so people do a decent job)
</code></pre>
</blockquote>
<p>Not so sure, not doing a good job during setup will impact availability, which is a monthly bounty so setup fee is not so important. I propose not to pay this.</p>
<blockquote>
<pre><code>* bonus on 95% availability: 150 BSQ (to be discussed on how we evaluate that)
</code></pre>
</blockquote>
<p>this is 36 hours of outage (if I calculated correctly). Should this get a bounty?</p>
<blockquote>
<pre><code>* bonus on 99% availability: 350 BSQ (to be discussed on how we evaluate that)
</code></pre>
</blockquote>
<p>This is 7 hours of outage. Probably ok to give a bounty.</p>
<p>In short I'm fine with this, of course what if your seednode is down due to bugs, tor errors, ... - measuring will be the hard part. You can easily measure if you're better than needed, but if worse than needed you might need to give some proof in your componsation request that the downtime was due to bisq and not you or your hosting situation.</p>
<p>In the long run my opinion is that seednodes should not be precious porcelain servers that need 99% uptime, too easy to disrupt the network. Ideally they are just the longest running bisq instances. If they are down, clients connect to the next one. The BSQ changes with full nodes/blocknotify didn't bring this dream any closer of course, but IMHO it should be a long term goal, so we shouldn't get too attached to our bonuses ;)</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/proposals/issues/102?email_source=notifications&email_token=AJFFTNSMAQCYZH7QT7SYPXLQBLICPA5CNFSM4ICIQKA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD24HFZQ#issuecomment-515404518">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNQU4PVJKO6YOAYQL6DQBLICPANCNFSM4ICIQKAQ">mute the thread</a>.<img src="https://github.com/notifications/beacon/AJFFTNSVSUGO576RXWKLLMTQBLICPA5CNFSM4ICIQKA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD24HFZQ.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/proposals/issues/102?email_source=notifications\u0026email_token=AJFFTNSMAQCYZH7QT7SYPXLQBLICPA5CNFSM4ICIQKA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD24HFZQ#issuecomment-515404518",
"url": "https://github.com/bisq-network/proposals/issues/102?email_source=notifications\u0026email_token=AJFFTNSMAQCYZH7QT7SYPXLQBLICPA5CNFSM4ICIQKA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD24HFZQ#issuecomment-515404518",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>