camosoul
Well-known member
I think this needs it's own thread... I don't want to hijack this one any further... I'm about to head out... Brainstorm in my brief absence.
V12 Release
- Thread starter eduffield
- Start date
bertlebbert
Well-known member
Thanks for that camo, this really helps put the potential of Dash into proper perspective.
Defacto
Member
v52 doesn't compile on latest FreeBSD (10.2-STABLE).
in v51 there was:
so there is clear conflict of data types.
# gmake
Making all in src
gmake[1]: Entering directory '/build/dash/src'
gmake[2]: Entering directory '/build/dash/src'
CXX libbitcoin_wallet_a-masternode-payments.o
masternode-payments.cpp:601:18: error: no matching function for call to 'max'
int nLimit = std::max(((int)mnodeman.size())*1.25, 1000);
^~~~~~~~
/usr/include/c++/v1/algorithm:2654:1: note: candidate template ignored: deduced conflicting types for
parameter '_Tp' ('double' vs. 'int')
max(const _Tp& __a, const _Tp& __b)
^
/usr/include/c++/v1/algorithm:2646:1: note: candidate function template not viable: requires 3 arguments,
but 2 were provided
max(const _Tp& __a, const _Tp& __b, _Compare __comp)
^
1 error generated.
Makefile:4402: recipe for target 'libbitcoin_wallet_a-masternode-payments.o' failed
gmake[2]: *** [libbitcoin_wallet_a-masternode-payments.o] Error 1
gmake[2]: Leaving directory '/build/dash/src'
Makefile:6778: recipe for target 'all-recursive' failed
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory '/build/dash/src'
Makefile:568: recipe for target 'all-recursive' failed
gmake: *** [all-recursive] Error 1
Making all in src
gmake[1]: Entering directory '/build/dash/src'
gmake[2]: Entering directory '/build/dash/src'
CXX libbitcoin_wallet_a-masternode-payments.o
masternode-payments.cpp:601:18: error: no matching function for call to 'max'
int nLimit = std::max(((int)mnodeman.size())*1.25, 1000);
^~~~~~~~
/usr/include/c++/v1/algorithm:2654:1: note: candidate template ignored: deduced conflicting types for
parameter '_Tp' ('double' vs. 'int')
max(const _Tp& __a, const _Tp& __b)
^
/usr/include/c++/v1/algorithm:2646:1: note: candidate function template not viable: requires 3 arguments,
but 2 were provided
max(const _Tp& __a, const _Tp& __b, _Compare __comp)
^
1 error generated.
Makefile:4402: recipe for target 'libbitcoin_wallet_a-masternode-payments.o' failed
gmake[2]: *** [libbitcoin_wallet_a-masternode-payments.o] Error 1
gmake[2]: Leaving directory '/build/dash/src'
Makefile:6778: recipe for target 'all-recursive' failed
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory '/build/dash/src'
Makefile:568: recipe for target 'all-recursive' failed
gmake: *** [all-recursive] Error 1
in v51 there was:
int nLimit = std::max(((int)mnodeman.size())*2, 1000);
so there is clear conflict of data types.
Pull and build from v0.12.0.x branch.
Fixes will be merged to master once flare figure out why bamboo refuses to bake new development builds.
moli
Well-known member
i don't think so. but we'll never know.
TroyDASH
Well-known member
There is already a natural cap because you need 1000 DASH and there is a limit to the number of coins that can ever be mined.
moli
Well-known member
ah true.. i didn't think of that... also, i think at the beginning there was talk that it should be capped at 2000.. that was before evan had his "eureka" moment... and InstantX was born..
EDIT: and more masternodes were needed because of InstantX, hence, more reward for mns...
Last edited by a moderator:
TroyDASH
Well-known member
GermanRed+, that's just the amount paid to masternodes in a day, with about 550 blocks - and therefore masternodes paid each day (Evan said that was the average we were getting) it equals just over 2 coins per masternode paid per day, which is about right. It's taking about 5 1/2 days now to get through the masternode list
No, the amount displayed at the bottom of dashninja.pl always used to be the average *per node*, not the total amount paid per 24 hours. Right now it says
Estimated daily payout for an active node (blocks with MN payments last 24h: 100%): 1309.6235 DASH/day (Last Refreshed: Wed Sep 02 2015 8:28:06 PM)
Before today it always used to display something around 3-6 DASH per day. What happened?
He has some troubles keeping node online and that breaks stats...:sad:
Still have no idea why his nodes eat more memory than it should be on average...
flare
Well-known member
I can offer an external dashd if that is of any help...
Thank you so very much! I'm sorry I disappeared, had to go. I did have to add the full path to dashd for some reason, but otherwise it worked. This is what I ended up with. If there is a mistake / bad design that you see could cause issue, please let me know
Code:
#!/bin/bash
while [ true ] ; do
if [ -z $(fuser -c ~usr1/.dash/dash.pid 2>&-) ]; then
/usr/local/bin/dashd 1>&-
fi
sleep 300
doneI've learned a lot trying to do this, again, thanks!
flare
Well-known member
Dashninja is wrong on this, current protocol version is still 70103. .52 is not released yet, use on your own risk.
ArpFlush
Member
Thanks, I'll stick with v51 for sure :wink:
Solarminer
Well-known member
We were also talking about a similar program on the bitcointalk thread here:Thank you so very much! I'm sorry I disappeared, had to go. I did have to add the full path to dashd for some reason, but otherwise it worked. This is what I ended up with. If there is a mistake / bad design that you see could cause issue, please let me know
Code:#!/bin/bash while [ true ] ; do if [ -z $(fuser -c ~usr1/.dash/dash.pid 2>&-) ]; then /usr/local/bin/dashd 1>&- fi sleep 300 done
I've learned a lot trying to do this, again, thanks!
https://bitcointalk.org/index.php?topic=421615.105600
It you want to use the process id, instead of the dash.pid file. Replace the if statement with this.
if [ -z `pidof dashd` ]; then
I like your idea of the dash.pid. With the process id it would change if it needed to restart, so your way should allow multiple restarts.
I think with your way you would need to leave your terminal window open for this to work. So I suggested using the screen command to run in the background. UdjinM6 suggested using a crontab. Details from bitcointalk:
Copy code below and paste into mn_watch.sh file. Type nano mn_watch.sh, paste with right click, and control x, y, enter to save. Change dashuser to your user name.
Code:
#!/bin/bash
#run with: screen -dm /mn_watch.sh
#stop with: screen -ls to find number and screen -X -S 11111 kill
while true; do
if [ -z `pidof dashd` ]; then
echo Dashd is not running trying to start
/home/dashuser/dashd
sleep 600
else
echo Dashd is Running
sleep 600
fi
donetype:
chmod +x mn_watch.sh
You can test it by running:
./mn_watch.sh
It will stop working as soon as you logout though, so we need to install screen to have it run in the background. Run this to install screen. (Assuming you are running Ubuntu.)
apt-get install screen
to start with screen type:
screen -dm /mn_watch.sh
This will run forever, so if you want it to stop type
screen -ls and get the number replace that with the 11111 below.
screen -X -S 11111 kill
Last edited by a moderator:
Unfortunately, even if I started Dash Ninja with the goal of having support for multiple hubs, current code will probably break if used that way.
When I get some more time I will try to improve it so I can add off-site monitoring nodes.
Exactly! I started with the conversation on bitcointalk, and discovered that my daemons wouldn't start independently, if one should crash or stop, but the other continued. (I have one server, two users, 2 ip addresses, running 2 masternodes) So GR+ showed me how to test for the user's process id for dash (which I think is only possible because our developers made it pop up as a file in the .dash folder? It is checked with a cron job and if not running, it starts the daemon back up.
There is another way to check to see if the daemon stopped cleanly vs dirty, so that if you stopped the daemon (rather than it crashing) it would stay stopped until you started it again. This would be useful for updating, but I wasn't able to get it to work. I don't think it's worth the trouble either as I only usually need a second to restart the daemon after updating the files. I don't even stop it before updating. As long as we still have dashd and dash-cli, the older running version of dashd can shut down fine (it doesn't over write the new version on shutdown) and restarting updates the version. Plus, I check every 10 minutes, which is done by the clock, so if I start after a check (ie: X:00, X:10, X:20...etc...) I have plenty of time, even if I had to stop the daemon to update.
Anyway, I wrote a tutorial on it here: https://dashtalk.org/threads/keep-your-mn-up-and-running-after-crash-ubuntu-w-explainations.6063/
If it sucks too much, anyone is welcome to rewrite it and even better, give other ways and other choices on how to do it
Thanks for everyone's help!
Geert
Active member
ah true.. i didn't think of that... also, i think at the beginning there was talk that it should be capped at 2000.. that was before evan had his "eureka" moment... and InstantX was born..
EDIT: and more masternodes were needed because of InstantX, hence, more reward for mns...
If Dash appreciates till it's worth as much as BTC, and people clue into the fact that they can run several masternodes and live comfortably off the proceeds, masternodes may eat up most of the available Dash. Also, if there are too many masternodes, will that hamper the network's ability to reliably mix coins? I can't help feeling that at some point, there may be a real hard limit placed upon the total number of masternodes put in the code.