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

vazaki3

Active Member
Jul 1, 2019
305
106
113
33
apogee.dynu.net
Dash Address
XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
Last edited:

vazaki3

Active Member
Jul 1, 2019
305
106
113
33
apogee.dynu.net
Dash Address
XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
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:

vazaki3

Active Member
Jul 1, 2019
305
106
113
33
apogee.dynu.net
Dash Address
XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
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.
 
  • Like
Reactions: xkcd

GrandMasterDash

Grizzled Member
Masternode Owner/Operator
Jul 12, 2015
3,063
1,190
1,183
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?
 

vazaki3

Active Member
Jul 1, 2019
305
106
113
33
apogee.dynu.net
Dash Address
XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
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)
 
  • Love
Reactions: xkcd

GrandMasterDash

Grizzled Member
Masternode Owner/Operator
Jul 12, 2015
3,063
1,190
1,183
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:

vazaki3

Active Member
Jul 1, 2019
305
106
113
33
apogee.dynu.net
Dash Address
XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
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:
  • Like
Reactions: GrandMasterDash

GrandMasterDash

Grizzled Member
Masternode Owner/Operator
Jul 12, 2015
3,063
1,190
1,183
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.
 

vazaki3

Active Member
Jul 1, 2019
305
106
113
33
apogee.dynu.net
Dash Address
XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
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:

GrandMasterDash

Grizzled Member
Masternode Owner/Operator
Jul 12, 2015
3,063
1,190
1,183
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?
If you're using sqlite3 then there is no background service, most of the load is when inserting new rows. As for security holes, I don't know. If you're allowing random node commands, albeit secured, then it might be argued that a wrapped https call is more secure as you get to control which commands can or can not be called and from which IP. But honestly, you could be right.