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.
Vote: Self-sustainable Decentralized Governance by Blockchain
- Thread starter eduffield
- Start date
Nor for meIt's not working for me (this morning) I have yet to voteBut 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
"masternode vote-many yea" gives me "Voted successfully 0 time(s) and failed 4 time(s)."
Yes, I was apparently misinformed. I'm happy this functionality is coming, though!
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 spoke too soon, there is no textual feedback from vote whereas vote-many has an iteration counter message.
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...
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.
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).
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.
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.
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:
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?
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.
What does the StartingBlock property do? Does it determine how long the voting remains open?
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.
That's a great idea, that will definitely help
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.
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.
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:
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.
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.
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.
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
Maybe I just have to load my actual wallet and put it online? I didn't want to do that