Proposal: Business Development (January)

[UdjinM6]

The net votes of this proposal are 389 votes, thus it is below 10% and it needs 44 more YES votes to be approved. But for a strange reason the requested amount of 607.410 has been paid!
...
_trolling_

Budget was finalized when this proposal still had some support http://dashvotetracker.com/history.html?ProposalID=179

Yet I agree that such support drop is a clear signal that smth need to be fixed NOW.
@babygiraffe @eduffield

 

[demo]

Budget was finalized when this proposal still had some support http://dashvotetracker.com/history.html?ProposalID=179

Yet I agree that such support drop is a clear signal that smth need to be fixed NOW.
@babygiraffe @eduffield

The payment of 607.41 dash took place at 2017-01-04 06:47:53

At this time the NET votes were 389

So there is obviously a bug here, or otherwise someone hacked your system and caused the budget to give the money earlier.
Device random, remember?

 

[ericsammons]

Budget was finalized when this proposal still had some support http://dashvotetracker.com/history.html?ProposalID=179

Yet I agree that such support drop is a clear signal that smth need to be fixed NOW.
@babygiraffe @eduffield

Demo's trolling aside, I think he is correct: this proposal did *not* have enough votes when the superblock occurred, yet it was still paid (https://chainz.cryptoid.info/dash/block.dws?598193.htm). Why is that? If you look at the history, the superblock was paid at 01:47:53 on 1/4/2016, yet at that point, this proposal had about 416 net votes, which was not enough to pass.

Does the Budget System look at the vote when the superblock occurs, or does it look when someone finalizes the budget (which happened a few hours before in this case). If it is when the budget is finalized, that is a real problem, as people do not know exactly when that will happen, and that can be controlled by an individual (unlike the superblock occurrence, which is set and immutable). This vote is a perfect case-in-point: it crossed the threshold from passed to not-passed in the final hours of the cycle - after the budget finalization but before the superblock was generated. It would be good for MN owners to know how this works, and if it will be different in 12.1.

 

[David]

Demo's trolling aside, I think he is correct: this proposal did *not* have enough votes when the superblock occurred, yet it was still paid (https://chainz.cryptoid.info/dash/block.dws?598193.htm). Why is that? If you look at the history, the superblock was paid at 01:47:53 on 1/4/2016, yet at that point, this proposal had about 416 net votes, which was not enough to pass.

Does the Budget System look at the vote when the superblock occurs, or does it look when someone finalizes the budget (which happened a few hours before in this case). If it is when the budget is finalized, that is a real problem, as people do not know exactly when that will happen, and that can be controlled by an individual (unlike the superblock occurrence, which is set and immutable). This vote is a perfect case-in-point: it crossed the threshold from passed to not-passed in the final hours of the cycle - after the budget finalization but before the superblock was generated. It would be good for MN owners to know how this works, and if it will be different in 12.1.

The Network only looks at the vote totals when the budget was finalized. That's why almost every month, somebody from Core Team (usually @tungfa iirc) reminds everybody to go ahead and vote and not wait until the last minute. It has specifically been pointed out that votes cast (either for or against) do not count after finalization occurs.

I agree that it's definitely something that should be worked on, however.

 

[tungfa]

The Network only looks at the vote totals when the budget was finalized. That's why almost every month, somebody from Core Team (usually @tungfa iirc) reminds everybody to go ahead and vote and not wait until the last minute. It has specifically been pointed out that votes cast (either for or against) do not count after finalization occurs.

I agree that it's definitely something that should be worked on, however.

did
https://www.dash.org/forum/threads/11-days-to-go-please-vote.12517/#post-110564

 

[David]

Budget was finalized when this proposal still had some support http://dashvotetracker.com/history.html?ProposalID=179

Yet I agree that such support drop is a clear signal that smth need to be fixed NOW.
@babygiraffe @eduffield

I agree. I'm honestly starting to get a bit scared at how thinly spread the "core" of Core Team is becoming. While I understand the need for an "executive council" of sorts within the Team, expanding the weekly calls to a wider audience (all of Core Team) would probably be a good first step. That would keep more people in the loop, and give an opportunity for more people to take more responsibility. Frankly, I have quite a lot of free time and am always looking for something else to do--unload some stuff on me!

 

[ericsammons]

The Network only looks at the vote totals when the budget was finalized. That's why almost every month, somebody from Core Team (usually @tungfa iirc) reminds everybody to go ahead and vote and not wait until the last minute. It has specifically been pointed out that votes cast (either for or against) do not count after finalization occurs.

I agree that it's definitely something that should be worked on, however.

You learn something every day, I guess. I thought I had a pretty good understanding of the process, but I didn't know the votes were locked at budget finalization - I thought it was at the superblock generation (although I guess the name "finalization" should have given me a hint ). Obviously that's not an ideal system, so hopefully it will be changed in the future.

 

[TroyDASH]

Although this seems to have passed by the skin of its teeth, the vote wasn't exactly a ringing endorsement. I hope the team will follow through on those issues because if not it will only get worse

 

[UdjinM6]

@ericsammons
As @David correctly pointed out budgets are finalized ahead of superblocks, usually few hours before. Budgets can only be finalized when it's ~2 days left, not earlier, but we try to keep it as close to superblocks as possible to count as much votes as possible (keeping in mind that you need to give MNs some time to vote on finalized budget itself which takes few tens of blocks because their votes are spread in time). Also it's not something only Core Team member can do, anyone willing to burn 5 DASH can https://dashpay.atlassian.net/wiki/display/DOC/Budget+Finalization+Procedure and then different finalized budgets will compete against each other for MN's votes. The one with the highest support wins and serves as a base for superblock payouts.

 

[demo]

@ericsammons
As @David correctly pointed out budgets are finalized ahead of superblocks, usually few hours before. Budgets can only be finalized when it's ~2 days left, not earlier, but we try to keep it as close to superblocks as possible to count as much votes as possible (keeping in mind that you need to give MNs some time to vote on finalized budget itself which takes few tens of blocks because their votes are spread in time). Also it's not something only Core Team member can do, anyone willing to burn 5 DASH can https://dashpay.atlassian.net/wiki/display/DOC/Budget+Finalization+Procedure and then different finalized budgets will compete against each other for MN's votes. The one with the highest support wins and serves as a base for superblock payouts.

Yes, but the important question is:

Who is the one who manually finilized the budget, before the end, in order to get rid of the upcoming negative votes and that way receive the 607 dash?

Who is suspicious of doing it? Is it maybe someone who directly or indirectly receives profit from the 607 dash?

It is obvious that someone read @fible1 announcement, and decided to get rid of his negative votes by finalizing the budget earlier.

The community must discover the person who played that tricky game, and do not trust him as a person anymore.

 

[Ryan Taylor]

Demo's trolling aside, I think he is correct: this proposal did *not* have enough votes when the superblock occurred, yet it was still paid (https://chainz.cryptoid.info/dash/block.dws?598193.htm). Why is that? If you look at the history, the superblock was paid at 01:47:53 on 1/4/2016, yet at that point, this proposal had about 416 net votes, which was not enough to pass.

Does the Budget System look at the vote when the superblock occurs, or does it look when someone finalizes the budget (which happened a few hours before in this case). If it is when the budget is finalized, that is a real problem, as people do not know exactly when that will happen, and that can be controlled by an individual (unlike the superblock occurrence, which is set and immutable). This vote is a perfect case-in-point: it crossed the threshold from passed to not-passed in the final hours of the cycle - after the budget finalization but before the superblock was generated. It would be good for MN owners to know how this works, and if it will be different in 12.1.

If your read my monthly official announcement on the budget, I do repeat every month to be sure to vote by the day before to ensure votes are counted. Voting just hours before the budget pays will ensure your vote will not be counted almost all of the time.

These messages take time to propagate the network, and it takes time for masternodes to evaluate a proposed finalization and vote on it (happens automatically based on the vote counts they "see" at the time). We also don't think it's prudent to wait for the very last second to send the budget finalization command... this is still relatively new software and should anything go wrong in that procedure, we should leave a bit of time to address it before budgets are missed.

All that said, the message sent by the masternode owners we hear loud and clear. It didn't need to be defunded before we notice the angst about communication. If that was the objective of many of the "no" voters, mission accomplished without sacrificing our business development efforts.

 

[demo]

If your read my monthly official announcement on the budget, I do repeat every month to be sure to vote by the day before to ensure votes are counted. Voting just hours before the budget pays will ensure your vote will not be counted almost all of the time.

These messages take time to propagate the network, and it takes time for masternodes to evaluate a proposed finalization and vote on it (happens automatically based on the vote counts they "see" at the time). We also don't think it's prudent to wait for the very last second to send the budget finalization command... this is still relatively new software and should anything go wrong in that procedure, we should leave a bit of time to address it before budgets are missed.

All that said, the message sent by the masternode owners we hear loud and clear. It didn't need to be defunded before we notice the angst about communication. If that was the objective of many of the "no" voters, mission accomplished without sacrificing our business development efforts.

If you want to be fair, you should burn the 607 dash!
This is the decision of the community, the 607 dash should be burned!

The 607 dash reside now into your wallet, after the tricky game someone played.
So you are the only one who can burn them now!

Do it immediatly, otherwise you are suspicious.

 

[UdjinM6]

Yes, but the important question is.
Who is the one who manually finilized the budget, in order to get rid of the negative votes and get the 607 dash in his pocket?
Who is suspicious of doing it?
Is it maybe someone who directly or indirectly received the 607 dash?

I finalized budget this month, here is the tx https://explorer.dash.org/tx/94160b7580d38ac9f07468413fbea6774b5ac24f055e5fb834f3e8103cc19bde
Here is the tx where I returned leftover to my donation address https://explorer.dash.org/tx/b64cf9845ffdd92fcaf756d4e1f3687f850b7d73b65bbb1c6b248d468d9abca4
Finalization tx is in block 597813, latest superblocks started at 598176, 598176 - 597813 = 363 i.e. 363/~24 = ~15 hours before superblocks. We usually try to finalize budgets starting 24h before superblocks in case of any unforeseen issues. This proved to be a good practice because sometimes it's not that smooth as you'd expect it (votes fluctuate which can sometimes affect finalized budget acceptance). There is no way to finalize it other than manually in 12.0, it's going to be automatic starting from 12.1. Also I did not get rid of any votes, I simply can't - finalization procedure is a process of compressing proposal list into a hash and relaying it together with collateral hash to the network. Each masternode decides on its own using it's own vote count if it likes it or not (every vote is verified independently by every masternode).

If you want to be fair, you should burn the 607 dash!

Do it now, otherwise you are suspicious.

The procedure was executed exactly like it's designed in the protocol, like it or not.

 

[Ryan Taylor]

Yes, but the important question is:

Who is the one who manually finilized the budget, before the end, in order to get rid of the upocoming negative votes and that way receive the 607 dash?

Who is suspicious of doing it? Is it maybe someone who directly or indirectly receives profit from the 607 dash?

It is obvious that someone read @fible1 announcement, and decided to get rid of his negative votes by finalizing the budget earlier.

Anyone can finalize the budget. In practice, it is almost always to the best of my knowledge a member of the core team. I would point out, the core team would have no way in advance of budget finalization (which we performed within 24 hours of the payout as usual... there was no manipulation of the usual procedure) that some "no" votes would soon be casted. In fact, it was actually a bit LATER than usual this month and was only finalized about 15 hours ahead of the budget. So many of those voting within 24 hours of the payout, despite being "late", nonetheless saw their votes counted.

 

[demo]

The procedure was executed exactly like it's designed in the protocol, like it or not.

ARE YOU KIDDING ME?

IS A BUG IN YOUR SYSTEM MORE IMPORTANT THAN THE DECISION OF THE MASTERNODES?

THE COMMUNITY DECIDED.

THE 607 Dash must be burned!

(this is funny, this case is similar to the ethereum DAO case, so you must choose, either respect the bug or the community)

 

[UdjinM6]

ARE YOU KIDDING ME? IS THE BUG OF YOUR SYSTEM MORE IMPORTANT THAN THE DECISION OF THE COMMUNITY?
THE COMMUNITY DECIDED. THE 607 Dash must be burned!

It's not a bug, it's the way it's designed. If you don't know how it's designed or you don't like the way it's designed it doesn't suddenly make smth a bug.

 

[demo]

It's not a bug, it's the way it's designed. If you don't know how it's designed or you don't like the way it's designed it doesn't suddenly make smth a bug.

Of course it is a bug. It is a design bug.
The most important bugs reside into the design.
And why this design is a bug? Because it does not respect the decision of the community.
Here is the rule:
Every design which do not respects the decision of the community, it is considered as a buggy design.

 

[UdjinM6]

of course it is a bug. It is a design bug.

No, it's not. Design bug is when smth is not working the way it was designed which is not the case. There are design limitations and there are solutions to such limitations - not perfect solutions, but they were needed to get system working to some degree.

...
(this is funny, this case is similar to the ethereum DAO case, so you must choose, either respect the bug or the community)

This has nothing in common.

 

[demo]

No, it's not. Design bug is when smth is not working the way it was designed which is not the case. There are design limitations and there are solutions to such limitations - not perfect solutions, but they were needed to get system working to some degree.

So you have designed to get rid of the negative votes, at your will, by having the power to finilize the budget before it ends?

 

[Ryan Taylor]

If you want to be fair, you should burn the 607 dash!
This is the decision of the community, the 607 dash should be burned!

The 607 dash reside now into your wallet, after the tricky game someone played.
So you are the only one who can burn them now!

Do it immediatly, otherwise you are suspicious.

There was no "trickery"... I explain in every single budget summary in "official announcements" when votes need to be cast before. These late votes simply do not count... that has been well explained countless times, even if a subset of the masternode owners didn't yet realized that.

Even if that weren't the case, I can assure you, the vote would not have turned out differently. I personally know of a substantial number of votes that were not cast, but were planning to vote "yes" should business development have fallen into defunded status (and no, I did not ask for them to vote, they informed me of their intent). That became unnecessary as it turned out, so they never voted.

Finally, there is a good reason why it might not be wise to allow last-minute voting. Apathetic "shadow" voters may not cast their votes if proposals they support have for example 11% support. This could allow a whale with 3% voting power to vote "no" minutes before the budget and defund something. Had the whale cast their votes days earlier, the apathetic voters have time to react. I call it "ninja voting".

This was in a sense, a case of "ninja voting" with many last-minute vote changes. Had the "shadow" voter I referenced had time to react, they surely would have cast their votes to offset it.

 

[UdjinM6]

So you have designed to get rid of the negative votes, at your will, by having the power to finilize the budget before it ends?

Stop writing and start reading, pls.