So far i know DIP8 activation enforces ChainLocks. But there is still a spork (19) that needs to be activated manually.
Dash Core v0.14 Planned Upgrade Phases scheme puts the spork 19 activation right after the DKG spork activation.
Dash Core v0.14 on Mainnet
- Thread starter tungfa
- Start date
- Status
Dash Core v0.14 Planned Upgrade Phases scheme puts the spork 19 activation right after the DKG spork activation.
Is it me or has the masternode's server memory usage and disk usage grown substantially in size lately ?
Memory usage is now per dashd between 800MB and 900MB ? Was it always this size ? I seem to remember a lower value per dashd (not totally sure)
Disk usage per masternode between 13 and 14 GB (Edit : this could actually be normal size now i think about it, as the blockchain itself should be approx that size)
On a side note : Number of active masternodes with a PoSe Penalty seems to have stabilized at around 310 masternodes.
Memory usage is now per dashd between 800MB and 900MB ? Was it always this size ? I seem to remember a lower value per dashd (not totally sure)
Disk usage per masternode between 13 and 14 GB (Edit : this could actually be normal size now i think about it, as the blockchain itself should be approx that size)
On a side note : Number of active masternodes with a PoSe Penalty seems to have stabilized at around 310 masternodes.
Last edited:
Before v0.14 memory usage was about 700 MB, now it is about 1 GB, so yes mem usage is grown, but i think its expected.
Disk usage is now 12.6 GB.
Leftist Dickhead said:
Bigger Leftist Dickhead said:
Exceptionally Large Leftist Dickhead said:
anyway...Gargantuan Leftist Dickhead said:
Of the ~150 nodes I was monitoring, only 2 remain online. I estimated 8 days to termination, but since I started posting about the problem the rate increased drastically.
It's almost like someone knows and has manual control, much like I theorized... Sporks are still under manual control, and a deterministic masternode list could extend that control...
If they were misconfigured how could they both still be online at this point? One with a flawless record?
Especially since the one with the flawless record is known for a fact to be misconfigured. It should have been flagged at least once by now... But, the ones that had nothing wrong with them, they're long gone...
I'm not going to bother asking how that's possible. Since it exposes something that isn't supposed to be exposed, there won't be a straight answer, probably more gaslighting, insults, etc...
War is Peace!
Freedom is Slavery!
Ignorance is Strength!
(you can't spell "freedom" without "ree.")
DASH is honked... smh
I have 2 MNs down today, and when restarting it loads block index and crash, reindex does not help.
I reported to @codablock and @UdjinM6 detailed report in privatemsg, lets wait.
I reported to @codablock and @UdjinM6 detailed report in privatemsg, lets wait.
Reason for this crashing was LOW memory, and because of that,
MN crashed and made a corrupted database, after that resync/reindex didnt help because of low memory.
I upgraded VPS memory from 1GB to 4 GB and started dashd again with -reindex, and it was succesful and MN is back to normal.
So if you have 1 GB memory in your VPS/MN, prepare to upgrade your memory, and/or make swap if that is possible.
Thanks to @codablock and @UdjinM6 for resolving this fast!
Edit: added /reindex
Last edited:
Ya, we got it: You are the gaslighted victim, everyone else is a dickhead and anybody who can't see the issue you identified must be a idiot.
Btw: So far every report of a banned node turned out to be either user error, misconfiguration or insufficient hardware resources. But as this does not fit your conspiracy theory driven world it must be the leftest dickheads who have a secret switch embedded in the code to kick every user/node to their liking ... and earth is flat.
Have a nice day.
Latest stats on DKG spork activation:
Slope: bans/day=72.23
Correlation: r=0.991
Estimated network death: 65 days
Masternodes banned: 372 (7.5%)
Masternodes revived: 74
Revived masternodes banned: 7 (9.5%)
Slope: bans/day=72.23
Correlation: r=0.991
Estimated network death: 65 days
Masternodes banned: 372 (7.5%)
Masternodes revived: 74
Revived masternodes banned: 7 (9.5%)
Past performance is not indicative of future results - but thanks for capturing some stats
There are still 70 "closed port" nodes plus 70 outdated Dash v0.13 nodes registered in the network, so these 140 will be at least added to the body count the next days/weeks.
Not to forget all the other hosting services available
https://docs.dash.org/de/latest/masternodes/hosting.html
True but with r=0.99 it's compelling. The slope is tapering slowly which means it's probably not truly linear, but asymptotic with a % of nodes banned per time period instead of a fixed number which makes more sense. This defines a masternode half-life under the DKG Spork, new stat coming soon!
The trend will revert soon: Nodes are getting updated, configurations reviewed and fixed, hardware/VMs upgraded to recommended specifications and firewall rules adjusted.
I have seen worse drops in node count during the last 5 years
Actually DKG works as expected: Finally a working PoSe scheme we have been looking for so long. "ProofOfPing" which was used before was a sham, there is even a sophisticated tool for faking (phantom)nodes out there: Earn masternode rewards without providing service to the network. These days are over.
Looking forward for the next stat update - thanks for taking the time to capture the data.
No, they are the same since Dash 12.1 - but some operators seem to run their nodes below minimum specs (1GB RAM) which is not sufficient since DKG got activated. 2GB RAM should still be on the safe side, i am hosting all my nodes on 4 GB RAM for more headroom. RAM is a commodity, you should not cut it short.
--> https://docs.dash.org/en/stable/masternodes/understanding.html#masternode-requirements
I'm glad i went overkill with my masternode specs awhile back in preparation for Dash Evolution.
Also good to hear that user error, misconfiguration or insufficient hardware resources are the main cause of PoSe banning.
Current number of active masternodes with a PoSe Penalty Score : 285 (diminishing)
Source : https://www.dashninja.pl/deterministic-masternodes.html
Also good to hear that user error, misconfiguration or insufficient hardware resources are the main cause of PoSe banning.
Current number of active masternodes with a PoSe Penalty Score : 285 (diminishing)
Source : https://www.dashninja.pl/deterministic-masternodes.html
Last edited:
@moocowmoo has been unresponsive for months and masternode.me is losing nodes to PoSe bans. Maybe masternode.me should be removed from that list?
The service works great for correctly configured MNs. I contacted moocowmoo a few days ago [email protected] and he helped me.
How did you contact him? I've been trying to contact him for months, through both email and discord. I've stopped using the service but since there's no way to pay him, there's no way to stop paying either.
- Apr 8, 2014
- 1,926
- 1,287
- 1,283
I'm using 8GB on the servers I host.
None of the hosted MNs went into penalty.
Spending a couple of bucks more at least cut you some problems out of your head.
I'd say recommended ram now is 4GB. Wait drive and other tools getting into play soon and 4GB will be the minimum
Start dashd with -reindex, it should help if it is blockchain/database/index corruption.
Also swapfile can help if its possible, not all VPS provider allow this.
New documentation on troubleshooting PoSe bans is here: https://docs.dash.org/en/stable/masternodes/maintenance.html#proof-of-service-bans
@camosoul I am not a programmer and do not read code, so it seems like a red herring to claim that these are prerequisites for contributing to the docs. If you are still interested in helping out, the documentation is open source under MIT license and accepts contributions in the form of issues or pull requests (currently to the 0.14 branch) in plain English here: https://github.com/dashpay/docs
As has been said many times here, all bans can be attributed to weak hardware, user error or incorrect configuration. This must be rectified to provide proper service to the network - remember that masternodes exist to serve the network, the network does not exist to pay masternode owners simply for holding Dash. This is Proof of Service, not Proof of Stake. Masternodes will also soon be serving DAPI to the broader internet - it is critical that all masternodes in the valid set are configured correctly and participating in DKG when interacting with real world users. Providing erroneous service to users would quickly erode trust in the network as a whole.
@camosoul I am not a programmer and do not read code, so it seems like a red herring to claim that these are prerequisites for contributing to the docs. If you are still interested in helping out, the documentation is open source under MIT license and accepts contributions in the form of issues or pull requests (currently to the 0.14 branch) in plain English here: https://github.com/dashpay/docs
As has been said many times here, all bans can be attributed to weak hardware, user error or incorrect configuration. This must be rectified to provide proper service to the network - remember that masternodes exist to serve the network, the network does not exist to pay masternode owners simply for holding Dash. This is Proof of Service, not Proof of Stake. Masternodes will also soon be serving DAPI to the broader internet - it is critical that all masternodes in the valid set are configured correctly and participating in DKG when interacting with real world users. Providing erroneous service to users would quickly erode trust in the network as a whole.
- Status