(Sorry for spam, forgot to cc the mailing list)

RE: miner economics
Miners who have an agenda can forego fees to achieve it and create their own txns if it is completely txn/user driven. It is better to just count miners votes and let the user votes be their backing.

Although miners need to include txns that have the same vote as them, or you expect them be able to vote themselves with their own txns, with backing eventually there will be a large pool of unconfirmed txns that vote against them. Which means a juicy choice of fees for an honest or small miner to vote the other way (if there are any).

If the votes are required to be near unanimous (almost 100%) rather than majority rule, there will be a small miner out there who will vote honestly and reset the vote on behalf of those users, because there is a fee incentive to do so (a pure honest miner doesn't care about fees. But they're a dying breed). If it is a majority rule type of vote, bigger miners will set the vote direction and small miners have no say no matter how they vote. From a decentralisation perspective, it is better to want the big guns to have a small voice, otherwise it will tend towards centralisation.

Troll users (voting against when the direction is very clear) can still be ignored by excluding their txns unless they're paying attractive fees. (So it isn't exactly 100%, but it'll be close). Miners have some power but ultimately they will represent the users if the users votes are clearly divided.

If you think 100% is hard, 95-90% could be a compromise but that requires an assumption that at least 5-10% will have their voices unheard. And that might be OK. Personally, 100% is consensus, anything less is just a democracy.

RE: vote bits
I think letting a vote go up and down in the same vote is a strange one. Personally I think binary votes simplify the process.

Would it be better to 'announce' a vote that will contain a certain change. For example, hash of a config file that said change MAX_BLOCK_SIZE -> 8mb. More things can use the same mechanism by including changes in a config (or whatever script/markup) file as needed in the future, for whichever constants you want to expose to votes.

Votes can just be 0 and 1 for no/yes and omitted for neutral. My preference is 1 for yes, 0 for no neutral/ignored and omitted for no, so that it is backwards compatible and doesn't skew votes to the agreeing direction, and forces node owners and wallet developers to upgrade and participate.