The masternodes exist to serve the network but let's not forget that DCG exists to serve the MNOs. When someone is having trouble with the software provided by DCG, it doesn't make sense to expect them to write the documentation for it that they themselves so desperately need. And it's understandable that it feels like a slap in the face to suggest that, especially while people are losing money.
Who is suggesting that MNOs write the documentation for the core wallet? That’s just silly. There was plenty of documentation available for the v13 and v14 updates. I am glad to see that it is being continuously improved, but the docs were sufficient beforehand. Otherwise we would have far far more than 200~300 MNs out of 5000 banned. Myself and many others (as evidenced by 90%+ of nodes staying up) have not had a problem maintaining a PoSe score of 0. Since I doubt many were reading through the code this demonstrates the veracity of the documentation. A small percentage (like 5%) of MNOs didn’t follow the provided directions and got banned... that’s it.
You have noticed that i posted this in context with contributing to DMT documentation? DMT is a open source tool written by @Bertrand256, unrelated to Core wallet. @masternube: I'd appreciate if you stop to quote me out of context and (mis)using my statement to make bold claims.
I think it is pretty clear what was meant. @masternube I don't see how that statement can be honestly misconstrued to mean that DCG is suggesting that MNOs write their own documentation for the core wallet.
camosoul was complaining about software in general. Same. It was pretty clear that camosoul was stressed about all "his" nodes going down. Sure he should have been more polite but suggesting that he write documentation for any project was not helpful at all. I'm sorry I missed that that was about DMT but that doesn't make your comment any more useful. I'm sorry for your limited imagination. And I'm sorry that I missed that was about DMT. It still was an unhelpful comment.
Sigh.... if this is the tact you are going to take then this is a pointless conversation. I will bow out here. The fact that the documentation was a non-issue is clear from looking at the numbers and the fact that said documentation came from DCG (and not the MNOs) is undeniable. If you aren’t seeing my point from those facts then there is nothing else I can say.
camosoul is stressed out about almost everything related to Dash since he got "stabbed in the back" by Evan back in 2015. Since then he is complaining about everything and everyone - but regularly coming back if he runs into issues with his nodes and needs free support (free as in "free beer") .. Because lefthead dickheads conspiracy yadda yadda, bla bla.... Btw: He was the first to come up with https://lowendbox.com for hosting masternodes for $1/month - so my educated guess is that the lack of hardware resources finally shot him in the foot. If someone is complaining about the quality of the documentation of a open source project, which someone is doing in his free time - how can suggesting to contribute not be useful? I agree that it was not useful for camosoul, but for above reasons I am not even willing to help him with his matter. Case camosoul is closed for me, this is a thread about v0.14.0, so lets stop to derail it.
I'm not aware of any history of camosoul so I didn't have that context. Thanks for reaching out in private to offer help with my MN. All good. Sorry if I offended anyone. Have a nice day!
That was a fun read - definitely some issues predating my time here The Dash source code and binaries are distributed with terse documentation in the style of Unix man pages. I am responsible for maintaining the user-facing step-by-step documentation at https://docs.dash.org - both of these products are developed and released by DCG. The user documentation was developed (with significant help from the community in the form of testing and pull requests) during the testnet phase, and was available from day one of the mainnet release. If anyone has specific or constructive feedback, I am constantly updating the documentation - drop me a message any time
Latest stats (from parsing debug.log): - unique masternode IDs punished: 1,159 (23.7%) - unique masternode IDs banned: 434 (8.9%) This chart is available at: http://sporked.seeger.net and is updated every 10 minutes.
I'm confused, how can we have 434 PoSe banned masternodes according to your info, when the number of active masternodes only dropped by some 200 masternodes? Link : http://178.254.23.111/~pub/masternode_count.png Also of the current 4715 active masternodes, only 128 masternodes have a PoSe Penalty score. Link : https://www.dashninja.pl/deterministic-masternodes.html Which should make total number of masternodes that has / had a PoSe Penalty score a lot less, then your mentioned 1,159 (below 400 seems more likely). Its almost like your are counting number of punishments instead of number of masternodes here. Your info is also in stark contrast to latest Dash News article, which only further consolidate my confusion with your info : Link : https://dashnews.org/hundreds-of-dash-masternodes-offline-as-network-tightens-performance-standards/
We are looking at different stats. Maybe you can help me rectify them as I don't want to spread misinformation. The data I am gathering is based on the debug.log from one of my masternodes that has been running since well before the spork activation. Everytime a masternode is punished we see an entry like this: 2019-06-13 08:40:50 CDeterministicMNList: PoSePunish -- punished MN cfb62e8bcd113017553d4d69c0f033fe57eca40e5dd5d6b77f336df8b2377da5, penalty 0->3257 (max=4936) If you count those up (e.g. $ grep "PoSePunish" ~/.dashcore/debug.log | wc -l) you get: 1,755 But, I only want to count the number of unique masternodes punished, not the total number of punishments, so I have a python script to de-dupe based on masternode ID, and the unique count is: 1,178 Everytime a masternode is banned we see an entry like this: 2019-06-13 08:06:38 CDeterministicMNList: PoSePunish -- banned MN 1729b477c347852397a21f17e2df9b6a032998ec50a7b85f9892ebf7599028f1 at height 1086358 Again, a raw count gives: 452, but the unique count is actually: 442. The difference can potentially be explained by the number of masternodes revived because some of them may have been banned multiple times. $ grep -i revive ~/.dashcore/debug.log | wc -l 159 Why do you think our information differs? I trust the debug.log more that the links you provided only because I'm looking directly at the debug.log and I'm not sure how those other sites are doing their calculations, but there is perhaps an error in my analysis. The number of active masternodes does seem to match the chart you provided: [email protected]:~$ dash-cli masternode list addr | wc -l 4715 -2 = 4713 (don't count the curly brace lines in the JSON output) Since I'm counting cumulative bans, the line is monotonic increasing which may be a little deceptive. But, the curve is tapering which is a good sign (once it's flat, no more bans are occurring). Interested to hear your feedback. Rick
The data i gathered with regards to PoSe Penalty is coming from dashninja Link : https://www.dashninja.pl/deterministic-masternodes.html By clicking on the PoSe score you can sort them from high to low and then its a simple matter of counting the number of pages with PoSe Penalty scores and multiplying that with 50 (each page contains 50 masternodes). I monitored dashninja regularly since the DKG spork activated and the largest number of pages with PoSe Penalty scores was about 7 i think (7x50 = 350 masternodes with a PoSe Penalty score). That number of pages started to diminish over time. In order to have over 1100 masternodes with a PoSe score, there would have been more then 22 pages of PoSe scores on dashninja (1100/50) at one point, which i believe was never the case. Maybe someone else can explain the differences in stats, but to be honest i put more value at what i saw at dashninja combined with the number of active masternodes graph, then whats getting extracted and concluded right now from your debug.log The difference in number of punished masternodes (350 versus 1100) and the difference in number of banned masternodes (5% versus 8,9%), just seems a bit too large a difference for me currently to solely rely on your debug.log data (normally i'm in favor of getting raw data through cli commands and using that, but in this case i'm not all that sure the data extraction has been performed correctly) It could also be that we are looking at two completely different set of measurements, that cant be easily converged into one outcome.
A couple ways to get MN numbers... All Masternodes: dash-cli protx list registered | wc -lNon-banned Masternodes: dash-cli protx list valid | wc -l You can use those 2 to figure out how many are banned. Also, to get the number with a non-zero PoSe score, you can do something like: Code: dash-cli protx list registered true | grep -i 'PosePenalty": [1-9][0-9]*' | wc -l If you want more info, you can do: Code: dash-cli protx list registered true | jq '.[] | select(.state.PoSePenalty>0)'
@qwizzie @Rick Seeger Also, based on what I see, one of the discrepancies comes from the fact that dashninja does not appear to show nodes with a score higher than <something>. I think it may be excluding nodes that are banned. Right now there are 335 nodes with a score > 0, but dashninja only shows ~120 with the highest score being 4105. $ dash-cli protx list registered true | jq '.[] | select(.state.PoSePenalty>0)' | grep -i "PosePenalty" | wc -l 335 $ dash-cli protx list registered true | jq '.[] | select(.state.PoSePenalty>4105)' | grep -i "PosePenalty" | wc -l 215
Thank you thephez. I'm getting the following info : Total registered masternodes : 4932 Command : ./dash-cli protx list registered | wc -l Total valid / non-banned masternodes : 4714 Command : ./dash-cli protx list valid | wc -l Masternodes banned : 218 (4932-4714) Masternodes with PoSe Penalty : 336 Command : ./dash-cli protx list registered true | grep -i 'PosePenalty": [1-9][0-9]*' | wc -l If above information could be put in some kind of daily query that keeps its history and updates itself every "x" time, we could indeed have some valuable information about number of banned masternodes and number of masternodes with a PoSe Penalty score progressing over time. Note : command ./dash-cli protx list registered true | jq '.[] | select(.state.PoSePenalty>0)' does not work at my side (error : -bash: jq: command not found)
Looks about right. The number potentially changes with every block depending on quorum formation, score decreases, etc. If you are using the Dash-Qt, you can get this info on the Masternodes tab. With the "Filter List" field empty you will see the full count and if you enter "POSE" you will see the banned nodes. I do not think it is possible to see just a list of nodes with non-zero scores there though. Regarding the last command, you probably just need to install jq ("apt install jq" or its equivalent on your platform).
dash-cli masternode status { "outpoint": "0000000000000000000000000000000000000000000000000000000000000000-4294967295", "service": "80.240.21.91:9999", "state": "WAITING_FOR_PROTX", "status": "Waiting for ProTx to appear on-chain" } What does it mean?
If you just gave a protx command, you will need to wait one proof of work confirmation i think. Your masternode does appear to have a PoSe Penalty score on dashninja (3445). At the same time it does show ENABLED with command : ./dash-cli masternode list full | grep -e 80.240.21.91 FYI
IIRC it may happen during a re-index too. My node shows that one as being enabled so I'm guessing you just need to wait for your node to catch up.
Yes, I think you're right. Also, I'm seeing the number of total bans flattening out now. For a while it looked like the bans were just going to keep happening, but in the end it looks like only a fraction of the network was/will be affected. I'm re-establishing my masternodes on upgraded hardware now. It's actually pretty impressive how smoothly the DASH network can upgrade as compared to other blockchains. Thanks for your info/feedback. chart: http://sporked.seeger.net
Then why spork 19 (chainlocks) is not active? The upgrade scenario clearly states that chainlocks is enforced with dip8 activation
From core dev @UdjinM6 on Discord: I am not sure how long mobile wallets and the like will require, but hopefully it is only a few days.
Well, this does not clarify how the "enforced chainlocks" is different from "active chainlocks", but I get the point
I'm glad we finally got an answer to that (i asked before and never got an answer, see page 3 & page 4). Looks like the Dash Core v0.14 Planned Upgrade Phases schedule was a bit too optimistic in that regard. I dont mind some delay or going at it in a slightly different way, but key is to just communicate clearly and in advance to the Dash community.
