Vote: Self-sustainable Decentralized Governance by Blockchain

Solarminer

Well-known Member
Apr 4, 2015
762
922
163
I'll try commenting out the nays in my masternode.conf, doing a vote-many yea, then reverse the comments and do a vote-many nay.
Good plan. Make sure all the votes get counted. I had to run start-many first to get all my nodes to accept the votes. They were even all green/active on the Elbereth site too. Weird.
 

David

Well-known Member
Jun 21, 2014
618
628
163
It's not working for me (this morning) I have yet to vote :( But I hope to get my vote in before we hit 51%, Though it'd be cool to be the vote that pushes it over the edge ;) LOL
Nor for me

"masternode vote-many yea" gives me "Voted successfully 0 time(s) and failed 4 time(s)."
 

tungfa

Grizzled Member
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,898
6,745
1,283
am trying to vote 1 by 1 MN
but no confirmation and nothing happening ??
what am i doing wrong ?

 
  • Like
Reactions: Raico

deusstultus

New Member
Dec 5, 2014
29
33
13
am trying to vote 1 by 1 MN
but no confirmation and nothing happening ??
what am i doing wrong ?
Vote-many gives textual feedback, vote does not. Run masternode list votes and parse for your ip.

Edited to correct claim after sniffing code.
 
Last edited by a moderator:
  • Like
Reactions: tungfa

tungfa

Grizzled Member
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,898
6,745
1,283
This is the standard response if your vote has already been accepted. Run masternode list votes and parse for your ip.
I never got a confirmation , got all good then I guess
 

GreyGhost

Well-known Member
Foundation Member
Jun 4, 2014
303
556
263
Santa Monica, CA
I voted - no confirmation like in tungfa's case above - and my vote reflected on DASH Ninja - Masternode Details Monitoring.

Alas, since it changed from displaying my vote and is now showing "ABSTAIN." Not sure is ninja monitoring accurate but it is perhaps worth mentioning...
 

deusstultus

New Member
Dec 5, 2014
29
33
13
I voted - no confirmation like in tungfa's case above - and my vote reflected on DASH Ninja - Masternode Details Monitoring.

Alas, since it changed from displaying my vote and is now showing "ABSTAIN." Not sure is ninja monitoring accurate but it is perhaps worth mentioning...
Ninja nodes are still running on 11.2.22 at present and therefore can't hold the votes for long periods per Evan's note in OP.
 

akhavr

Active Member
Oct 11, 2014
837
414
133
While I like the proposal, it does not contain the conditions and the way to stop diverting funds to escrow in the case MN's would consider the experiment failing.

Did I miss it?
 

alex-ru

Grizzled Member
Jul 14, 2014
2,374
3,243
1,183
Incidentally, it may be a problem:
We rely on the assumption that success of all MN-owners directly linked to the success of the DASH project.
But in practice, it may be that some players (banks, Bitcoiners, FBI ...) will become MN-owners to vote "nay" - to block our development (IF ">50%" will manage not only "their" part of RDM-funds, but 100% of whole RDM-funds).
 
Last edited by a moderator:
  • Like
Reactions: akhavr

pille

Active Member
Feb 18, 2015
275
304
123
My vote always switches to ABSTAIN (dashninja) after a while. Masternode is running stable at version .23

Also, I have to "masternode start" after every update, even with small version changes (.22 -> .23). If I dont do this, I get offline.
 
Last edited by a moderator:

eduffield

Core Developer
Mar 9, 2014
1,084
5,323
183
An Update To The Proposal

It dawned on me how to update the existing system to get the best of both worlds a fully decentralized system that pays exact amounts directly from the blockchain. We also figured out how to improve the decentralization of the proposal viewing application, so that anyone can run one of these websites independently of each other without having to copy data around. Between these two improvements, the initial version of the budgeting software will be highly decentralized and without any escrow account.

Proposal Website Decentralization

Anyone can start off a proposal by submitting it from a masternode. The data required consists of ProposalName, ProposalURL, PaymentCount, StartingBlock, PaymentAddress and PaymentAmountUSD. The ProposalURL is a json object with a ShortDescription, LongDescription, PDFURL and any other fields that are required to show users.

The site will be able to show this information, something like “mnbudget show”, which will return the following:


{
"one" : {
"URL" : "http://www.dashpay.io/proposals/one.txt",
"BlockStart" : 1000,
"BlockEnd" : 24922,
"PaymentCountTotal" : 1,
"PaymentCountLeft" : 1,
"PaymentAddress" : "yDrdpBqfExiGbssu388t2k3N3de2KsWeNN",
"Ratio" : 1.00000000,
"Yeas" : 1,
"Nays" : 0,
"Abstains" : 0,
"Alloted" : 7500000000,
"TotalBudgetAlloted" : 7500000000
}
}

It will pull down the url and cache all of the information in a database. Notice proposal administrators must host the json object with the data about the proposal, this allows highly decentralized storage of the information in the proposals. Users can then register on the website, then post comments about proposals.

To allow people to submit proposals from these proposal websites, the website will have access to a masternode, that can submit it for the users. This means we’ll have a very friendly website for building these json files, which can show drafts to the community. Once a draft has been finalized, it can be submitted. After it’s submitted, this is non-reversible and these fields can’t be modified without losing all votes.

Removal Of The Reference Node

It’s a high priority to ship the first version with no reference node. We’re going to use masternode quorums to select the payee of each block. This means that 10 of 2500 masternodes will randomly be selected to have a task of voting who they think should get paid each block. We’re going to use a deterministic algorithm to select the payee, so all nodes should come to same conclusion.

How The Network Will Pay Proposals

To remove the escrow account and pay exact amounts we can use a spork to send the current USD value of DASH to the network. This process can be decentralized later, but is out of scope for the initial version. After the network has the correct value to use, we can then reduce the blockreward of all blocks by 10% and at the end of the cycle the network can pay the proposals their exact own amounts using very large blocks, which will catch it up with the required block reward.

Here’s an example of what this will look like, let’s say we have this budget and a $3 DASH price:

PropOne, Reward $8000
PropTwo, Reward $8000
PropThree, Reward $5000
PropFour, Reward $4000
PropFive, Reward $900

Total $25900 (Total budget is $25920.00 at 10%, notice there’s $20 left over)

we’ll use a static block reward of 5 for simplicity:

Block 300,000 - Miner reward 2.47, Masternode payee 2.025 (a total reward of 4.5, when the target reward is 5)
… 17280 blocks pass (1 month) ...
Block 317280 - Miner reward 2.47, PropOne payee 2666.66DASH
Block 317281 - Miner reward 2.47, PropTwo payee 2666.66DASH
Block 317282 - Miner reward 2.47, PropThree payee 1666.66DASH
Block 317283 - Miner reward 2.47, PropFour payee 1333.33DASH
Block 317284 - Miner reward 2.47, PropFive payee 300.00DASH

---

I don't think anyone will have an issue with changing to this system, as it's far superior to the existing one. If you do, simply change from vote from Yea to Nay.
 
Last edited by a moderator:

David

Well-known Member
Jun 21, 2014
618
628
163
An Update To The Proposal

It dawned on me how to update the existing system to get the best of both worlds a fully decentralized system that pays exact amounts directly from the blockchain. We also figured out how to improve the decentralization of the proposal viewing application, so that anyone can run one of these websites independently of each other without having to copy data around. Between these two improvements, the initial version of the budgeting software will be highly decentralized and without any escrow account.

Proposal Website Decentralization

Anyone can start off a proposal by submitting it from a masternode. The data required consists of ProposalName, ProposalURL, PaymentCount, StartingBlock, PaymentAddress and PaymentAmountUSD. The ProposalURL is a json object with a ShortDescription, LongDescription, PDFURL and any other fields that are required to show users.

The site will be able to show this information, something like “mnbudget show”, which will return the following:


{
"one" : {
"URL" : "http://www.dashpay.io/proposals/one.txt",
"BlockStart" : 1000,
"BlockEnd" : 24922,
"PaymentCountTotal" : 1,
"PaymentCountLeft" : 1,
"PaymentAddress" : "yDrdpBqfExiGbssu388t2k3N3de2KsWeNN",
"Ratio" : 1.00000000,
"Yeas" : 1,
"Nays" : 0,
"Abstains" : 0,
"Alloted" : 7500000000,
"TotalBudgetAlloted" : 7500000000
}
}

It will pull down the url and cache all of the information in a database. Notice proposal administrators must host the json object with the data about the proposal, this allows highly decentralized storage of the information in the proposals. Users can then register on the website, then post comments about proposals.

To allow people to submit proposals from these proposal websites, the website will have access to a masternode, that can submit it for the users. This means we’ll have a very friendly website for building these json files, which can show drafts to the community. Once a draft has been finalized, it can be submitted. After it’s submitted, this is non-reversible and these fields can’t be modified without losing all votes.

Removal Of The Reference Node

It’s a high priority to ship the first version with no reference node. We’re going to use masternode quorums to select the payee of each block. This means that 10 of 2500 masternodes will randomly be selected to have a task of voting who they think should get paid each block. We’re going to use a deterministic algorithm to select the payee, so all nodes should come to same conclusion.

How The Network Will Pay Proposals

To remove the escrow account and pay exact amounts we can use a spork to send the current USD value of DASH to the network. This process can be decentralized later, but is out of scope for the initial version. After the network has the correct value to use, we can then reduce the blocksize all all blocks by 10% and at the end of the cycle the network can pay the proposals their exact own amounts using very large blocks, which will catch it up with the required block reward.

Here’s an example of what this will look like, let’s say we have this budget and a $3 DASH price:

PropOne, Reward $8000
PropTwo, Reward $8000
PropThree, Reward $5000
PropFour, Reward $4000
PropFive, Reward $900

Total $25900 (Total budget is $25920.00 at 10%, notice there’s $20 left over)

we’ll use a static block reward of 5 for simplicity:

Block 300,000 - Miner reward 2.47, Masternode payee 2.025 (a total reward of 4.5, when the target reward is 5)
… 17280 blocks pass (1 month) ...
Block 317280 - Miner reward 2.47, PropOne payee 2666.66DASH
Block 317281 - Miner reward 2.47, PropTwo payee 2666.66DASH
Block 317282 - Miner reward 2.47, PropThree payee 1666.66DASH
Block 317283 - Miner reward 2.47, PropFour payee 1333.33DASH
Block 317284 - Miner reward 2.47, PropFive payee 300.00DASH

---

I don't think anyone will have an issue with changing to this system, as it's far superior to the existing one. If you do, simply change from vote from Yea to Nay.
Brilliant as always, Evan. I'm impressed.
 
  • Like
Reactions: bigrcanada

Stray

Member
May 27, 2014
43
14
48
Hi Evan,

Please correct me if my understanding is flawed:
Since these pass through the Masternode network, would there be anything in place to keep a malicious user from submitting an inordinate amount of proposals or invalid JSON objects that could prove to be a nuisance or tie up resources processing excessive requests?
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
Hi Evan,

Please correct me if my understanding is flawed:
Since these pass through the Masternode network, would there be anything in place to keep a malicious user from submitting an inordinate amount of proposals or invalid JSON objects that could prove to be a nuisance or tie up ]resources processing excessive requests?
I suggested an anti-spam fee, eg 1 DASH to submit a proposal.
 

orangecycle

Well-known Member
Foundation Member
Oct 2, 2014
169
239
203
node40.com
Anyone can start off a proposal by submitting it from a masternode. The data required consists of ProposalName, ProposalURL, PaymentCount, StartingBlock, PaymentAddress and PaymentAmountUSD. The ProposalURL is a json object with a ShortDescription, LongDescription, PDFURL and any other fields that are required to show users.
What does the StartingBlock property do? Does it determine how long the voting remains open?
 

eduffield

Core Developer
Mar 9, 2014
1,084
5,323
183
Hi Evan,

Please correct me if my understanding is flawed:
Since these pass through the Masternode network, would there be anything in place to keep a malicious user from submitting an inordinate amount of proposals or invalid JSON objects that could prove to be a nuisance or tie up resources processing excessive requests?
The JSON object is pretty much ignored by the protocol. It's just used on the website to show more information to the users. If you mess that file up, it wouldn't mess with the network and it will pretty much be ignored.

I suggested an anti-spam fee, eg 1 DASH to submit a proposal.
That's a great idea, that will definitely help
 

Stray

Member
May 27, 2014
43
14
48
I suggested a fee, eg 1 DASH to submit a proposal.
That could be interesting - If the proposal is rejected the collateral could be added to an approved project perhaps? (or returned after some time period, but that defeats the purpose of a fee)

-Second question that may or may not be valid- How would we prevent 'imitation' requests if that's a concern:
(an exact duplicate of an existing vote, or one with a slight change in parameters that may not be immediately noticeable)

The community could police that? May get annoying as utilization shoots up.
 
  • Like
Reactions: raganius

eduffield

Core Developer
Mar 9, 2014
1,084
5,323
183
What does the StartingBlock property do? Does it determine how long the voting remains open?
Using starting block, you can tell the network you would like to start getting paid in 3 months or so. That's also how it calculates when your payments are complete.
 

JGCMiner

Active Member
Jun 8, 2014
364
217
113
How The Network Will Pay Proposals

To remove the escrow account and pay exact amounts we can use a spork to send the current USD value of DASH to the network. This process can be decentralized later, but is out of scope for the initial version. After the network has the correct value to use, we can then reduce the blockreward of all blocks by 10% and at the end of the cycle the network can pay the proposals their exact own amounts using very large blocks, which will catch it up with the required block reward.

Here’s an example of what this will look like, let’s say we have this budget and a $3 DASH price:

PropOne, Reward $8000
PropTwo, Reward $8000
PropThree, Reward $5000
PropFour, Reward $4000
PropFive, Reward $900

Total $25900 (Total budget is $25920.00 at 10%, notice there’s $20 left over)

we’ll use a static block reward of 5 for simplicity:

Block 300,000 - Miner reward 2.47, Masternode payee 2.025 (a total reward of 4.5, when the target reward is 5)
… 17280 blocks pass (1 month) ...
Block 317280 - Miner reward 2.47, PropOne payee 2666.66DASH
Block 317281 - Miner reward 2.47, PropTwo payee 2666.66DASH
Block 317282 - Miner reward 2.47, PropThree payee 1666.66DASH
Block 317283 - Miner reward 2.47, PropFour payee 1333.33DASH
Block 317284 - Miner reward 2.47, PropFive payee 300.00DASH

---

I don't think anyone will have an issue with changing to this system, as it's far superior to the existing one. If you do, simply change from vote from Yea to Nay.
Evan, correct me if I am wrong, but according to this new proposal the block reward will be reduced 10%. Then based on MN voting a certain number of projects are funded where the total cost of those projects must be X where 0%<= X <= 10% of the original block reward (in your example 5). Next those funds are paid by some superblocks say at the end of every month. Finally, if the total required funds are less than 10% of the original block reward then the remaining Dash is never generated (in your example the $20 or 6.667 DASH). Is that correct?
 
Last edited by a moderator:

oaxaca

Well-known Member
Foundation Member
Jul 8, 2014
573
832
263
-Second question that may or may not be valid- How would we prevent 'imitation' requests if that's a concern:
(an exact duplicate of an existing vote, or one with a slight change in parameters that may not be immediately noticeable)

The community could police that? May get annoying as utilization shoots up.
Each proposal would obviously have it's own topic on this forum. Enough comments like "Project 12 is just a ripoff of project 7. Don't vote for it!" should be sufficient.
 

deusstultus

New Member
Dec 5, 2014
29
33
13
I don't think anyone will have an issue with changing to this system, as it's far superior to the existing one. If you do, simply change from vote from Yea to Nay.
Should rebuff user response on the voting system with this aspect. There is no response on success from client side on delivering a vote or write to debug.log. Additionally, the client side should be able to check pmn->lastVote equivalent from masternodeman as well and respond with a message indicating votes cannot be changed within the specified interval rather than just returning.

Masternode handling is obviously more important to govern this system, but if clients don't have an easy way of acknowledging the status of each vote call it complicates the process.
 
  • Like
Reactions: raganius

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
Finally, if the total required funds are less than 10% of the original block reward then the remaining Dash is never generated (in your example the $20 or 6.667 DASH). Is that correct?
I don't think it would be 'earmarked' (and thus the block reward modified) in the first place. Not so much a case of never generated as never needed, never taken?

At least that's how I read it - Evan was just demonstrating a within-max-budget scenario.
 

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,876
1,867
1,283
Sorry to bug you all, but Crowning said I could vote via my remote masternodes. I haven't been able to vote via my local (using vote-many shows failed 1) When I vote on my remote, using dashd masternode vote yea I get no feedback, and checking here: http://178.254.18.153/~pub/Dash/masternode_payments_stats.html, the vote count didn't go up. I checked my debug log, and I can't find anything definitive searching for yea or vote or anything. The remotes and the locals were updated to v23. Thanks for any help.

Maybe I just have to load my actual wallet and put it online? I didn't want to do that :(