• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

BUG REPORT: Should the votes of a former masternode that just keeps his collateral be counted?

Should the votes of a former masternode that just keeps his collateral be counted?

  • Total voters
    5
vazaki3

vazaki3

Well-known member
Weejohnny whale is out of the game now. He didnt upgrade to v18.
Why his votes for dash-incubator-2022-q3 and BrazilQ42022 proposals still count?

The protocol wipes the masternode's votes only in case the masternode's collateral is removed. But the one who is supposed to have voting rights, is the one who runs a masternode. Not the one who just keeps a dash collateral address!!!

I think the one who just keeps a collateral address but shut down his masternodes should have the right for his votes to be stored and wait for a possible return, but his votes should not be counted.
 
Last edited:
<vote history>
Should the votes of a former masternode that just keeps his collateral be counted?
</vote history>
 
This bug still remains, after 1 year!!!! Watch!

Code: 
20:13 demo<0>apogee 0 $ cat ~demo/httpd/the_results_dashd_2023-09-22-14-35-18.html.csv|grep ",Regular,"|cut -f1,3,10- -d,|grep mnowatch-hosting-2023|grep POSE
"108.61.247.70",mnowatch-hosting-2023,Regular,POSE_BANNED
"149.248.39.252",mnowatch-hosting-2023,Regular,POSE_BANNED
"202.182.102.237",mnowatch-hosting-2023,Regular,POSE_BANNED
"45.32.162.229",DAOTutorials DASHFTLSEPT2024 dash-incubator-ash-2023-q3 dash-incubator-rion-2023-q3 dash-marketing-hub-integrations-bounty DCG-COMP-OCT-DEC23 mnowatch-hosting-2023 Ru-speaking-Community TREASURY-REALLOCATION-60-20-20,Regular,POSE_BANNED
"198.13.52.47",mnowatch-hosting-2023,Regular,POSE_BANNED
"144.202.95.18",mnowatch-hosting-2023,Regular,POSE_BANNED
"149.28.25.132",mnowatch-hosting-2023,Regular,POSE_BANNED
"45.76.111.111",mnowatch-hosting-2023,Regular,POSE_BANNED
"202.182.105.95",mnowatch-hosting-2023,Regular,POSE_BANNED
"45.76.234.147",mnowatch-hosting-2023,Regular,POSE_BANNED
"144.202.19.42",dash-marketing-hub-integrations-bounty mnowatch-hosting-2023,Regular,POSE_BANNED
"108.160.134.116",mnowatch-hosting-2023,Regular,POSE_BANNED
"45.77.129.235",mnowatch-hosting-2023,Regular,POSE_BANNED
"45.76.205.140",mnowatch-hosting-2023,Regular,POSE_BANNED
"185.28.101.145",mnowatch-hosting-2023,Regular,POSE_BANNED
"136.244.116.110",mnowatch-hosting-2023,Regular,POSE_BANNED
"149.28.254.159",mnowatch-hosting-2023,Regular,POSE_BANNED
"45.77.11.194",mnowatch-hosting-2023,Regular,POSE_BANNED
18G ~/httpd
20:14 demo<0>apogee 0 $


All the above masternodes are POSE_BANNED, they do not count in the definition of the electorate and in the calculation of the 10% threshold. But the core wallet still calculates their votes as legitimate in the voting oucome!!! Regarding the examined mnowatch proposal, unfortunately the mnowatch leaderboard for compatibility reasons reports 685 YES votes (being forced to be compatible to a bug, what an irony !!!) , while in reality the legitimate YES votes for the mnowatch proposal are currently only 667 !!!

SO THE VOTING OUTCOME OF THE CORE WALLET AND OF THE DASH BUDGET SYSTEM IS DEFINITELY WRONGLY CALCULATED!!!! THE BUDGET PROPOSALS ARE PASSING AND ARE BEING PAID BY TAKING INTO ACCOUNT THE VOTES OF THE POSE_BANNED MASTERNODES THAT DO NOT PARTICIPATE IN THE 10% THRESHOLD!!!!

Some people may get benefit of this bug. For example, if I have a fleet of 200 masternodes then I can vote YES for my proposal and I can intentionally pose banned all of them at the end of the cycle. In that case the 10% passing threshold lowers, and my proposal passes more easily! Say the weight of the network is 3453+72*4=3741, then the passmark is 374 votes, now to move that down by one we need a weight of 3730 so 3741-3730=11, so for every 10 nodes that are removed from the network, the passmark falls by 1 vote. The aforementioned 200 mnos fleet, in case they decide to exploit the bug, it is like if they holded 220 votes! So, by exploiting this bug, you can increase your voting power by 10%!

This is absurd, and the fact that this bug is not fixed after one year makes it more absurd! This bug should be resolved ASAP, I also would like the DCG to pay me a bug bounty for the discovery of this bug.

@QuantumExplorer @Pasta @UdjinM6
 
Last edited:
I'm not going to comment on whether you're correct as I don't know, but I will say right now the bug bounty program clearly states:

Responsible Disclosure Policy
As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.
Click to expand...
 
Monotoko said:
I'm not going to comment on whether you're correct as I don't know, but I will say right now the bug bounty program clearly states:
Click to expand...

The Disclosure Policy of the bug bounty program should be fixed, and better say:

"Responsible Disclosure Policy
As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization, unless the core developers are so unprofessional so that they keep refusing to fix the bug after one whole year."
 
Last edited:
And by the way, I am not not discussing this program or any vulnerabilities of it outside of the program.
I am into the official Dash forum, so I am INSIDE the program, am I not?

If you think that the vulnerability I just mentioned is so critical (it is not actually), you could always censor my comment. You should have done this (as a forum admin) since one year from now, but you didnt! So if you want to accuse someone, it is fair to firstly accuse yourself for not censoring the disclosed vulnerability for a whole year.
Matthew 7:3 CEB
Why do you see the splinter that’s in your brother’s or sister’s eye, but don’t notice the log in your own eye?
Click to expand...

I was waiting one year to explode, this is the definition of forbearing.
Your underlying motivation for accusing me is not fairness @Monotoko, your underlying motivation is solely to find excuses for the unprofessional action of DCG of not fixing this bug for a whole year. The DCG wants the bugs not to be disclosed, in order for them to hide their unprofessionalism. Thats why the bug bounty program requires non disclosure for all kind of bugs, even for the non critical ones. This bug bounty rule should change, and the non critical bugs should be allowed both to be revealed and get paid, because the Dash community deserves to be informed about the quality of the work of the DCG developers.
 
Last edited:
vazaki3 said:
And by the way, I am not not discussing this program or any vulnerabilities of it outside of the program.
I am into the official Dash forum, so I am INSIDE the program, am I not?

If you think that the vulnerability I just mentioned is so critical (it is not actually), you could always censor my comment. You should have done this (as a forum admin) since one year from now, but you didnt! So if you want to accuse someone, it is fair to firstly accuse yourself for not censoring the disclosed vulnerability for a whole year.


I was waiting one year to explode, this is the definition of forbearing.
Your underlying motivation for accusing me is not fairness @Monotoko, your underlying motivation is solely to find excuses for the unprofessional action of DCG of not fixing this bug for a whole year. The DCG wants the bugs not to be disclosed, in order for them to hide their unprofessionalism. Thats why the bug bounty program requires non disclosure for all kind of bugs, even for the non critical ones. This bug bounty rule should change, and the non critical bugs should be allowed both to be revealed and get paid, because the Dash community deserves to be informed about the quality of the work of the DCG developers.
Click to expand...

No you're not inside the program, you can clearly see that on the bug bounty page. It tells you who to contact, it lays out exactly how a bug should be handled... this forum is public.

I personally had no idea you've posted the bug here a year ago, and I'm not sure anyone else did either... this is why we have channels for bugs There are also certain considerations and balances to make, for example is your theoretical exploit of this supposed bug better than say, me having no MNs and simply attacking every masternode who votes no to my proposal in order to get them POSE_BANNED and their votes discounted/dismissed?

There's pros and cons, simply calling it a bug because you think it is does not mean it wasn't designed that way to avoid something else
 
Monotoko said:
There are also certain considerations and balances to make, for example is your theoretical exploit of this supposed bug better than say, me having no MNs and simply attacking every masternode who votes NO to my proposal in order to get them POSE_BANNED and their votes discounted/dismissed?
Click to expand...

Your argument seems rational , but it is not. Because the vulnerability you mention can be easily resolved if DCG allows dynamic IPs and/or anonymity for the masternodes. But DCG constantly denies any protection of the individual masternodes against DDOS attacks, and they use the lack of this protection in order to justify arguments like yours.

I am asking since 7 years now for someone to tell me the reason why dynamic IPs (a quick and dirty way to be protected against DDOS attacks) are not allowed to the masternodes, and nobody has ever gave me a convincive answer to that. I mean, the masternodes can recognize eachother by the masternode ID, cant they? Why do they need static IPs?

See? Every step is carefully designed by the agents who control DCG, in order to chain the masternodes with unbreakable chains.
 
Last edited:
And by the way, this bug does not only refer to the POSE_BANNED masternodes. It also refers to the operators who completely shut down their masternodes , like weejohnny did. This is the job of DCG, to carefully design and balance the pros and cons, so that an optimum solution will be found. But DCG denies to deal with that issue, since one year now.

We should vote the numbers in order to define a bounty to be given to independant developers who will be incetivized to deal with the problem, and maybe the problem will be resolved. But DCG also denies to the masternodes to vote the numbers.

See? Every step is carefully designed by the agents who control DCG, in order to chain the masternodes with unbreakable chains.
 
Last edited:
There is also a very simple solution in order to fix the "10% increase of voting power" bug, a solution irrelevant and independent to the problem of DDOS attacks against those who voted NO.

Whenever a masternode's vote is being calculated for the voting outcome (regardless he is POSE_PANNED or ENABLED), this masternode should also be counted when calculating the 10% threshold passmark.

It is that simple, isnt it @Monotoko ? Why the DCG refuses such a simple solution?
 
Last edited:
vazaki3 said:
There is also a very simple solution in order to fix the "10% increase of voting power" bug, a solution irrelevant and independent to the problem of DDOS attacks against those who voted NO.

Whenever a masternode's vote is being calculated for the voting outcome (regardless he is POSE_PANNED or ENABLED), this masternode should also be counted when calculating the 10% threshold passmark.

It is that simple, isnt it @Monotoko ? Why the DCG refuses such a simple solution?
Click to expand...
The above of course implies that for every proposal there is a different 10% threshold passmark. If we would like the same 10% threshold passmark for all proposals there is another even simpler solution for the "10% increase of voting power" bug.

The electorate should be defined as "all the ENABLED masternodes in addition to the POSE_BANNED masternodes that casted at least one vote in any proposal".

The above rule if applied today it will increase the current threshold passmark from 374 to 376, because among the 285 POSE_BANNED masternodes only 18 casted at least one vote. Anyway, there may be other solutions too, but it is not my job to design and find solutions. Let the DCG think about it, it is their job and they get paid for this.
 
Last edited:
After communicating with DCG they answered me this: "core only pays bounties for critical bugs that would allow exploitation of customer funds or actually take down the network. "

So the DCG does not pay for any other bug report, neither they pay for bug reports that affect the governance system !!!!

The DCG devs welcome suckers to report their non critical bugs (governance is NOT critical according them), but although the DCG devs are paid as developers to develop non critical features, they refuse to pay the testers when their shit is revealed.

@xkcd said in discord:
"I have personally discovered several bugs (uncredited) in the core wallet and they've been fixed, including one attack on Platform where I demonstrated Platform would not start if enough EvoNodes were in the PoSe Ban status."

And the stupid MNOs keep paying THAT DCG and THIS DEV team. No wonder why Dash will sink deeper into the shit.

karate-chop-gloria.gif



.#13
 
Last edited:
qwizzie said:
See : https://github.com/dashpay/dash/pull/5583 with regards to the bug in question.
Click to expand...

The funny thing is that:

1) DCG didnt mention me at all in the above relevant github bug report. I remind you also that I am banned forever from the whole github site because DCG reported me when I was trying to expose their design errors.

2) I have revealed the solution for this bug, but they didnt understand/read it yet.

vazaki3 said:
there is another even simpler solution for the "10% increase of voting power" bug.

The electorate should be defined as "all the ENABLED masternodes in addition to the POSE_BANNED masternodes that casted at least one vote in any proposal".

The above rule if applied today it will increase the current threshold passmark from 374 to 376, because among the 285 POSE_BANNED masternodes only 18 casted at least one vote.
Click to expand...

Instead of the above clear solution, DCG's inherent stupidity in designing the dash protocol makes things worst. Their "design solutions" are often a pile of stupid shit created in order to hide another pile of shit, and @xkcd already started complaining about it in github.

Apparently, DCG remains deaf simply because it is (s)elected by deaf MNOs.
This bunch of stupid deaf, are unable to hear the storm that is approaching, a storm that will tear Dash apart.

 
Last edited:
1. The GitHub issue is just the start of the discussion generally, I would be shocked if you weren't credited in the release notes if a solution is decided upon (and have reminded core team they should credit for that)

2. I've also passed on your suggestion
 
Monotoko said:
1. The GitHub issue is just the start of the discussion generally, I would be shocked if you weren't credited in the release notes if a solution is decided upon (and have reminded core team they should credit for that)

2. I've also passed on your suggestion
Click to expand...

Thanks for your help @Monotoko

I dont care to be mentioned.
I care to be paid for the bug discovery. Testers should be paid, in case they discover bugs.
Testers are the enemies of the developers, so in case a bug is discovered the compensation of the devs should go to the testers.

vazaki3 said:
I also would like the DCG to pay me a bug bounty for the discovery of this bug.
Click to expand...

 
Last edited:
vazaki3 said:
Thanks for your help @Monotoko

I dont care to be mentioned.
I care to be paid for the bug discovery. Testers should be paid, in case they discover bugs.
Testers are the enemies of the developers, so in case a bug is discovered the compensation of the devs should go to the testers.
Click to expand...

Even if I could move mountains and change the rules of the bounty, you'd also need to be KYC'd etc... which I imagine you wouldn't want? The DCG bounty is limited in scope and probably won't change for a while...

Why not start your own bounty with funds from the treasury directly? This way you're not bound by what we do/do not do, if it passed you'd:

1) Be doing exactly what you want to do in a roundabout way since there would be less for DCG as a whole (which, imo, is a much more fair way of doing it than the way you've suggested)
2) Have MN approval *and* funds for expanding the bug bounty we provide

I really do try to engage with you directly and you often do bring up good points, but the needless attacks on DCG make it really hard to do so. Do you want our developers to quit? Which developers do you blame for this bug? Should we penalize everyone? I'm not entirely sure you've thought that idea through - I imagine no developer worth his salt would sign such a contract, and would instead move to other projects
 
Monotoko said:
Even if I could move mountains and change the rules of the bounty, you'd also need to be KYC'd etc... which I imagine you wouldn't want? The DCG bounty is limited in scope and probably won't change for a while...

Why not start your own bounty with funds from the treasury directly? This way you're not bound by what we do/do not do, if it passed you'd:

1) Be doing exactly what you want to do in a roundabout way since there would be less for DCG as a whole (which, imo, is a much more fair way of doing it than the way you've suggested)
2) Have MN approval *and* funds for expanding the bug bounty we provide
Click to expand...
I was paid before for some tiny bug discovery, and a KYC was not required.
Who changed the rules?
Does the one who changed the rules has a KYC?
If yes, is he still an active member of DCG?
If not, why his rules in favor of KYC are still valid?

Monotoko said:
I really do try to engage with you directly and you often do bring up good points, but the needless attacks on DCG make it really hard to do so. Do you want our developers to quit?
Click to expand...
No.
Monotoko said:
Which developers do you blame for this bug?
Click to expand...
I dont know. DCG should discover the guilty.
Monotoko said:
Should we penalize everyone?
Click to expand...
Not everyone. The one who made the mistake, either the designer or the coder, or both.
Monotoko said:
I'm not entirely sure you've thought that idea through - I imagine no developer worth his salt would sign such a contract, and would instead move to other projects
Click to expand...
I also imagine no tester that worth his salt would ever reveal a bug under these bounty rules.

What do you want? After killing the Miners, and the 1k Masternodes, does DCG now wants to kill the Testers?

Testers will move to other projects under these stupid bug bounty rules. And you definitely need testers, when v20 and the platform will be released.

So invest in testers, and inject a little fear to the paid devs and designers, because they are afraid nothing at the moment.
 
Last edited:
You must log in or register to reply here.
Back
Top