Search results

This is not a commentary on the implementation or advocacy for an alternative, simply indication that democracy is poor word association.

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...

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.

I spoke too soon, there is no textual feedback from vote whereas vote-many has an iteration counter message.

Vote-many gives textual feedback, vote does not. Run masternode list votes and parse for your ip. Edited to correct claim after sniffing code.

Just need the masternode.conf. Nothing is pulled from wallets here so you don't need to load or unlock cold wallets.

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/

s/D/d/ disablesafemode=1

Backup wallet and run once with -upgradewallet -zapwallettxes