Welcome!

Our service, https://dashplace.art, automatically activates cost display on https://pirate.art in DASH cryptocurrency. This service is an enhanced version of the legendary service shatoshis.place. However, we offer the ability to pay for images using DASH and support instantsend. Additionally, we provide payment options for other cryptocurrencies such as Bitcoin, Litecoin, Dogecoin, zCash, PirateCash, and Cosanta.

After you create and pay for the drawing, it will automatically be published on the Telegram channel https://t.me/pirate_pixels. However, we plan to add automatic publication to the following platforms as well:

Twitter: https://twitter.com/pirate_pixels
Reddit: https://www.reddit.com/r/pirate_pixels/
Instagram: https://www.instagram.com/pirate_pixels/

The platform is already operational and has the capability to upload drawings. However, our team plans to add additional features. Additionally, funds are needed for hosting payments and further development. You can verify the payout address on our project's website: https://p.cash/en/donate/

Yes. You deserve it for the past 10 years.
Thx for all your work rango with supporting Dash Dao since the beginning!

Yes from me.

@rango
Are you going to fix the broken or at least unreliable voting threshold calculation?
According to https://mnowatch.org/leaderboard/ it currently sits at 342
Also, some proposals occasionally show negative votes required to pass, like 'still needs -15 votes to pass'

DashCentral seems to calculate voting threshold at 296 votes, which is a staggering 13.2% too low.
Hopefully you are going to finally repair this, after your proposal is approved.

DC uses 10% of the weighted masternodes count (weighted by performance masternodes) to calculate the voting threshold. This value is currently 2956 and is equal to the value of 2956 shown here (https://mnowatch.org/dash-stats).

So i don't know how the voting threshold of 341 displayed on https://mnowatch.org/leaderboard is calculated and whether it is right or wrong.

Any further insights would be helpful.

No Sir, you are wrong.
If you take a closer look, you can clearly see stated on: https://mnowatch.org/dash-stats
3794/2956 1k MNs (Total/Enabled)
124/114 4k MNs (Total/Enabled)
Therefore the correct formula would be: (2956+(114*4))*0.10

Furthermore, you can easily check payment queue roundturn length on a Block Explorer, for a MN Reward which is configured as payout for a single node, like for example this payout address here:
https://chainz.cryptoid.info/dash/address.dws?XtimBkeBnP9ukcdH6dSPL5RFAG434Lcnr5.htm
The difference in block heights shows the length of the payment queue roundturn, of course it will only be correct if the node was not affected by a PoSE-ban between two payment blocks.
This would be an appropriate and accurate way to measure the correct 10% threshold, because it effectively takes into account misconfigured, old-versioned and PoSE-banned nodes.

Obviously such a method will no longer work after the Evo Pool will take effect and 4K MNs will only receive a single Reward payment on the Core chain.
After Evo Pool takes effect, it would be necessary to measure the length of payment queue roundturn *collateral*, divided by 1000 or 10000 respectively.

Please also try to troubleshoot the 'negative votes required' nonsense, which occasionally shows up.

The formula was correct, however they seem to have changed the Evo node label from "HighPerformance" to "Evo" during the most recent updates. That led to the last part of the formula being 0. The issue has been resolved.

I have implemented a fix that could also resolve the sporadic "negative votes required" issue. In case it still shows up, please let me know.

Thanks for your support. Is mnowatch managed by you?

Thanks for taking the time to investigate and fixing it so quickly.
Not sure, but i believe MNOwatch is run by xkcd & demo, i love those guys.
Last but not least i wanted to remind, that if a rounding function is used in the calculation, then unless its a full integer number, it should always round UP (!) but never round down, even in such an example:
341.2 rounded = 342 (instead of 341 resulting from default rounding)
To make sure a strict minimum of 10% is always respected, that should make sense.

What´s weird is, i just noticed there seems to be quite a huge discrepancy between the post-fix DC calculation (345 net votes)
and the figure posted by MNOwatch here: https://mnowatch.org/leaderboard/ (340 net votes)

I guess only demo can help to solve this mystery, where is he?

Found and fixed another issue. The voting threshold is now correct (341).

Vote counts (YesCount,NoCount) are taken from "gobject list all proposals". I would assume that these numbers include votes of POSE_BANNED masternodes.

You may be interested to know that the `getgovernanceinfo` RPC was updated in v20 to make this easier on us all. It now includes the threshold required to pass.

eg

{
"governanceminquorum": 10,
"proposalfee": 1.00000000,
"superblockcycle": 16616,
"superblockmaturitywindow": 1662,
"lastsuperblock": 2010536,
"nextsuperblock": 2027152,
"fundingthreshold": 341,
"governancebudget": 8528.33663416
}

WOW, that was really quick.
Rango, you are a genius, i tip my hat to you!
Thank you so much for repairing our DAO voting.
I´m gonna support your proposal.

Perhaps someday there will be an opportunity to discuss my objection regarding the above-mentioned default rounding with the CTO and also with demo, so that based upon their inputs and opinions, the always roundUp() function could be implemented across all services (DashCore, MNOwatch, DC, etc.) using the same identical logic.

Imagine an extremely important governance proposal with a super-tight voting result outcome,
where it could ironically make all the difference.
It would cause a lot of subsequent infighting, if half the community maintains it was barely approved, while the other half of the community knows for a fact it was short a single vote due to the down-rounding of the default rounding.

First of all, all calculations are wrong.

Here is why:

https://www.dash.org/forum/index.php?threads/has-the-proposal-passing-threshold-10-been-adjusted-to-account-for-evonodes.54518/#post-237650

If you want to be compatible with dashcore, you should take into account the POSE_BANNED votes, while calculating the threshold by using the 10% formula.

https://mnowatch.org/dash-stats/

793/2954 1k MNs (Total/Enabled)
124/114 4k MNs (Total/Enabled)

So the current threshold for every proposal is (4*114+2954)*0.1= 341

341 votes, INCLUDING OF COURSE THE VOTES OF THE POSE_BANNED.

With regards to PoSe banned masternodes still being able to vote : https://github.com/dashpay/dash/pull/5583

It looks like this git pull is getting hampered, by not working nicely with services like MNOwatch. Which is likely the reason why it has not been merged for now.

To be fair, a number of solutions have been proposed in that pull request, with each a downside.

Also note that for correct calculations, you should pair a leaderborad report with the appropriate stats, based on the correct report date.

For example this leaderboard
https://mnowatch.org/leaderboard/?20240122041015

pairs with this stat
https://mnowatch.org/dash-stats/?20240122103306

This happened in dashd V20

The change from HighPerforance to Evo is visible in these sequent reports:

https://mnowatch.org/the_results_dashd_2023-11-17-00-52-18.html
https://mnowatch.org/the_results_dashd_2023-11-16-00-52-19.html

I will obvioulsy vote yes for this.

Of course, after voting yes for the first month, I expect some improvements here in dashcentral in order for my yes to be kept for the next months too.

Yes, we support everyone else, I think we should support you.

No, the stupid masternodes do not support everyone.

For example, they do not support the Encointer Proposal, which is about to give an anonymous proof of individuality for every Dash member and thus make the Dash community members accountable for their stupid decisions.

https://mnowatch.org/encointerUBI