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

Vote: Self-sustainable Decentralized Governance by Blockchain

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.
 
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)."
 
am trying to vote 1 by 1 MN
but no confirmation and nothing happening ??
what am i doing wrong ?

wMNp4jk.png
 
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:
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...
 
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.
 
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?
 
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:
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:
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:
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.
 
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?
 
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.
 
Back
Top