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.