• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Which masternodes voted and what exactly voted on various proposals (v2)

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 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.
Welcome dear robot. How are you?
 
MNO holders who hold a few Masternodes (one to three) abstained from voting in this budget cycle.
Approximately 101 individuals (+myself) refused to vote in this budget cycle!!!
This is huge, if you take into account that the Dash electorate is approximately 300 individuals .

This is a strong warning for the stupid whales who rule this place.
The budget system needs to be redesigned, in order to attract the sardines.

2020-12-28-00-52-43
The first operator includes all people who dont vote at all. All the rest are identified by the way they vote.
1 operator(s) control(s) 003280 masternode(s)
1 operator(s) control(s) 000195 masternode(s)
1 operator(s) control(s) 000127 masternode(s)
1 operator(s) control(s) 000108 masternode(s)
1 operator(s) control(s) 000095 masternode(s)
1 operator(s) control(s) 000066 masternode(s)
1 operator(s) control(s) 000054 masternode(s)
1 operator(s) control(s) 000047 masternode(s)
1 operator(s) control(s) 000041 masternode(s)
1 operator(s) control(s) 000038 masternode(s)
1 operator(s) control(s) 000030 masternode(s)
1 operator(s) control(s) 000028 masternode(s)
1 operator(s) control(s) 000027 masternode(s)
1 operator(s) control(s) 000026 masternode(s)
2 operator(s) control(s) 000024 masternode(s)
1 operator(s) control(s) 000021 masternode(s)
1 operator(s) control(s) 000018 masternode(s)
2 operator(s) control(s) 000016 masternode(s)
4 operator(s) control(s) 000015 masternode(s)
2 operator(s) control(s) 000014 masternode(s)
1 operator(s) control(s) 000013 masternode(s)
2 operator(s) control(s) 000012 masternode(s)
2 operator(s) control(s) 000011 masternode(s)
4 operator(s) control(s) 000010 masternode(s)
2 operator(s) control(s) 000009 masternode(s)
6 operator(s) control(s) 000008 masternode(s)
6 operator(s) control(s) 000007 masternode(s)
6 operator(s) control(s) 000006 masternode(s)
13 operator(s) control(s) 000005 masternode(s)
16 operator(s) control(s) 000004 masternode(s)
26 operator(s) control(s) 000003 masternode(s)
42 operator(s) control(s) 000002 masternode(s)
149 operator(s) control(s) 000001 masternode(s)


2020-12-29-00-52-22
The first operator includes all people who dont vote at all. All the rest are identified by the way they vote.
1 operator(s) control(s) 003519 masternode(s) <--- 239 more masternodes abstained from voting!!!
1 operator(s) control(s) 000195 masternode(s)
1 operator(s) control(s) 000108 masternode(s)
1 operator(s) control(s) 000095 masternode(s)
1 operator(s) control(s) 000088 masternode(s)
1 operator(s) control(s) 000067 masternode(s)
1 operator(s) control(s) 000065 masternode(s)
1 operator(s) control(s) 000064 masternode(s)
1 operator(s) control(s) 000048 masternode(s)
1 operator(s) control(s) 000041 masternode(s)
1 operator(s) control(s) 000031 masternode(s)
1 operator(s) control(s) 000028 masternode(s)
1 operator(s) control(s) 000026 masternode(s)
3 operator(s) control(s) 000024 masternode(s)
1 operator(s) control(s) 000021 masternode(s)
2 operator(s) control(s) 000018 masternode(s)
3 operator(s) control(s) 000017 masternode(s)
2 operator(s) control(s) 000016 masternode(s)
1 operator(s) control(s) 000015 masternode(s)
1 operator(s) control(s) 000013 masternode(s)
1 operator(s) control(s) 000012 masternode(s)
2 operator(s) control(s) 000011 masternode(s)
2 operator(s) control(s) 000010 masternode(s)
3 operator(s) control(s) 000009 masternode(s)
3 operator(s) control(s) 000008 masternode(s)
5 operator(s) control(s) 000007 masternode(s)
8 operator(s) control(s) 000006 masternode(s)
9 operator(s) control(s) 000005 masternode(s)
10 operator(s) control(s) 000004 masternode(s)
13 operator(s) control(s) 000003 masternode(s) <-- 13 individuals left !
24 operator(s) control(s) 000002 masternode(s) <--- 18 individuals left !!!
78 operator(s) control(s) 000001 masternode(s) <--- 71 individuals left !!!!!!!
 
Last edited:
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. :p
 
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. :p

Vigor?

 
Last edited:
Now mnowatch.sh can connect to a remote dash-cli


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).
 
Last edited:
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.
Mnowatch is up and running again.
 
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?
 
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 --->
  1. DASH DAO Summary (mnowatch.org)
  2. DASH Proposal Owners (mnowatch.org)
 
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 --->
  1. DASH DAO Summary (mnowatch.org)
  2. DASH Proposal Owners (mnowatch.org)

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. But yeah, I guess your solution also works. Are you getting a lot of web traffic?
 
Last edited:
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.
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.

We rely on bash scripts and on an rdbms, when collecting and formating the data. The web API is an http technology. Why add another overhead (a webserver) on all this?
I feel sorry because we use bash scripts (or rdbms calls), instead of using pure assembly, machine code or at least c++ when creating the reports.
But my skills are limited, I cannot talk directly to the machine. So unfortunately I rely on the code libraries others created, and thus my reports are not created as fast as they possibly could be.

But yeah, I guess your solution also works. Are you getting a lot of web traffic?
I dont know. @xkcd may answer this. But I assume https://apogee.dynu.net has no big traffic.
 
Last edited:
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.
 
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.

We are already using sqlite3, this is our rdbms. But in order to have a web API, it requires both sqlite3 and a webserver. So why adding the webserver overhead and security hole?
I think connecting via rpc is faster and more secure than connecting through nginx or anyother webserver. Isnt it?
 
Last edited:
Back
Top