[bisq-network/proposals] Add bonus payment for seed nodes operators when node has 99.9% availibility (#102)

[Manfred Karrer]

>base compensation: operating costs + 50 BSQ?

I think we can use a fixed number. With the space requirement I think its 50-100 EUR/ month hosting costs on most providers. 
On Digital Ocean its 20 EUR for 4GB and 40 EUR for 400 GB space. So 60 EUR in total. I think 100 EUR should be a fair payment.

> might prevent the use of cheap hosting providers

I think it is not really the price but those hosters who offer anonymous accounts (payable in BTC). They are usually used by shady clients as well and then react more harsh (shutting down service without notification) or getting ddos'ed, etc. We had basically always problems in the past when people used such hosters. I would recommend to use only high quality hosters like Digitals Ocean, Linode, AWS,... 

>this is 36 hours of outage
That is way too much.... 

> This is 7 hours of outage. 
This is still a lot. 

I think a good seed should only have its downtimes while it restarts (as long that is required), which is about 2 minutes each day -> 1 hour/months. If we count in one update with rebuild its another 10 minutes max. So offline time of 2 hours max I think is what we should aim for and that is what deserves a bounty. Not sure if we need 2 levels of bounties. All seeds should run as smooth as possible. If not it has to be fixed. If the operator cannot fix it a dev need to fix it.

Of course the problems are often not the operators fault but if there is a financial incentive I think they will kick the devs faster as it was in the past. So I recommend to keep it strict. If not < 2 hours offline/months - no bounty. Bounty should be for now quite high, high enough so that an operator gets frustrated enough with devs that they push them if there are code problems as they risk to lose their bounty. Maybe 500-1000 BSQ might be a level where that happens?

>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. 

Yes of course. There is built in resilience (you connect to multiple nodes and if all are offline to any normal node) but the BSQ block delivery is still not at the resilience level as it should be and that is currently the main issue. Due lack of dev resources we cannot count that this gets improved soon so keeping the server stable (as they have been in April, May) seems the easier way to guarantee that people are not experiencing problems with BSQ. 

And dont forget the biggest bonus/malus is implicit to all contributors. If BSQ is not working well people cannot use it for fee payment and will not buy then from contributors and drive down the BSQ price. So there is a bonus/malus for any BSQ stakeholder and should motivate all to get that infrastructure as stable as possible. 

> to ensure that seed nodes are fragile

Yes basically the seeds are not considered as servers but as nodes which might be offline as well. So the Bisq node connects to multiple nodes anyway and if one fails it picks the next. But with the BSQ block request it is a bit more complicate as once you receive the blocks you process them. If you would have multiple requests the processing must not be interrupted... There is some timeout when you dont get a response that you request from another node, but seems that is too long or somehow not working well... All in all that is definitely code are to be improved but its complex and tricky and there might be more important tasks atm (protection tools, new trade protocol,...). But maybe you want to look into that if you feel attracted.... RequestBlocksHandler is the main class for requesting BSQ blocks....
  


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/102#issuecomment-515477376
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190726/abc6daff/attachment.html>