Careful there. If the vote extends only to masternode operators and not the general user, I wouldn't bandy that word.
Embracing a measured vote of the bourgeoisie is far from democracy.
The most practical implementation here would be to enable "abstain" as a valid voting option and set the default vote to null rather than "ABSTAIN." This would implement the desired functionality without too much convolution of the voting system. At the end of the voting period, or for any...
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...
That method doesn't exist, not sure what TaoOfSatoshi meant to indicate. All you have for voting within the client right now are vote and vote-many. Also, voting does not require a wallet unlock.
Voting plus multisig scripting would be the sensible basis here, sidechains should never be encouraged. However while script-based transactions are fairly well established, they have not been implemented at this scale and introduce risk should involved masternodes not follow convention.
IANAL, but It's a unique case, which always draws question. The miner creates the transaction and could have legal merit, the masternode receives funds and further executes services based on a relatively unspecified contract. Sure if this goes directly to a fund it's relatively easy to prove...
This endeavor of allocating funds towards developers, regardless of how well-intentioned or well-implemented would inevitably draw further attention in this regard.
I'll rebase some of my previous commentary. Relying on the masternode network with a randomized script metric is somewhat concerning. Looking around the community right now, it is easy to see that there are a few people who own a fair number of masternodes or otherwise hold influence over a...
This was exactly my thought with the mention of considering use of transaction locks held by masternodes who receive the coinbase tx. With proper implementation, these become held to a function and burned if not appropriated according to masternode voting, or with some tweaks to darksend allow...
The synergy of this project is project is bound to soar with a "Delivery Execllence Initiative." Buzzwords much? But seriously, glad to see this refocus.
Solarminer Some snippets:
I was not really endorsing long term use of donation metrric, more a "don't shift radically to solve something that could be similarly implemented with less breakage." This methodology could be implemented without the hardfork inherent in the 15% add. Same for the...
Can we not jump the gun here arbitrarily defining quotas for this? It really defeats the point of even implementing the voting system...
With some fixes to the multisig implementation, you have a clean masternode supported donations channel, this should be the avenue utilized for funding at the...
Your issue can be gleaned from the last 9 pages of this thread and ultimately stems back to same issue identified here: https://darkcointalk.org/threads/mandatory-all-users-must-update-to-v11.3619/