vazaki3
Well-known member
Updated table with latest data.
Summary of the changes over the last few months.
It would be nice to mention the crowdnodes in the above table.
Updated table with latest data.
Summary of the changes over the last few months.
Welcome dear robot. How are you?I post some data from the banned mnowatch github site.
I am afraid some of them are not accurate, because initially the shellscript took into account not only the active proposals but also the zombies ones.
I do agree with the above, what I am seeing behind the scenes is masternodes are being turned over (sold and bought back) but the newbies are not voting. I have some theories, one of which I share here. Warning, please don your tinfoil hat now. My theory is DASH is in the midst of a corporate take over of sorts. While many MNOs are capitulating here and selling this dog awful asset, someone is remarkably buying the DASH and spinning nodes out of it. I think once this person has enough votes, they will vote down all the DCG proposals are start to restructure DCG, the DIF and TP in a sensible way such that DASH can turn a new leaf and start to refresh itself with new energy and vigor that comes with a new DCG team and new POs that go ahead and build DASH2.0 from the ruins of DASH1.0.
Personally I am excited and look forward to the day when the new oligarchy reveals itself.
Mnowatch is out of order due to the new remote dash-cli feature, that is not compatible to our provider which considers remote procedure calls (rpc) as DDOS!
We have an issue with the F/W of the VPS provider of mnowatch. It seems the provider blocks the access from the webserver to the dashd for a while, intermittent . We enquired with the VPS provider, they said it is the fault of their DDOS protection system . We are now looking at tunneling the dashd rpc via stunnel or similar.
So in case you know how we can do an stunnel or smth similar, please help.
Or alternatively tip us , for mnowatch to move to a better provider (that accepts crypto as payment).
The issue was resolved without using stunnel. We used secure rpc (remote procedure call).Why are you complicating things with stunnel? Can't you just do the data gathering on the node and write an API to fetch it?
The issue was resolved without using stunnel. We used secure rpc (remote procedure call).
We have the mnowatch web server in a computer, and by using rpc calls we connect to another computer which has the dashd, in order to receive the dash data and form the reports.
This is because we want the mnowatch web server to be as light as possible. Also another reason is because if we put into the same machine both the mnowatch web server and the dashd server, then we need a powerfull machine, and powerfull machines are not cheap.
By the way, have a look at the new work of @xkcd --->
The overhead and bottleneck is mainly when collecting and formating the data. Another overhead is dashd itself. We need to make things as light as possible, and as cheap as possible. Because a big server is more expensive than two small ones, we choosed the two servers solution, one for the dashd and another for collecting and formating the data.I guess I didn't explain that well. I meant, you collect and format the data locally (on the node) and then make a private API that only you can remotely access.
I dont know. @xkcd may answer this. But I assume https://apogee.dynu.net has no big traffic.But yeah, I guess your solution also works. Are you getting a lot of web traffic?
I'm not entirely convinced but okay, understood.
Depending which database you're using, I wouldn't be surprised if it used more resources than a web server. There's almost nothing you can't do with sqlite and by orders of magnitude far easier to manage and backup than your typical rdbms. sqlite forces you to to design more efficiently.
Nginx is light and very fast serving static files and not that slow with scripting. I don't have much experience with bash scripts, it's a bit ugly.