(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. On Jun 13, 2015 6:04 AM, "Eric Lombrozo" wrote: > Miners currently only collect an almost negligible portion of their > revenue from fees. While I certainly welcome any proposals that move us in > the direction of defining a smooth metaconsensus process, I think with the > curent economics, miners (and especially those with significant hashing > power) have more of an incentive to block txs/spam their votes than to > adapt to tx sender preferences...unless people increase their tx fees > significantly. But without wallets that can make decent suggestions in this > regard, this feature will be almost inaccessible to most regular users. And > the economics still aren't entirely clear. > > - Eric Lombrozo > On Jun 12, 2015 12:30 PM, "Jannes Faber" wrote: > > I'm imagining in Peter's proposal it's not the transaction votes that are > counted but only the votes in the blocks? So miners get to vote but they > risk losing money by having to exclude counter voting transactions. But > garbage transactions are no problem at all. > > Note that users that want to cast a vote "pay" for that by increased > confirmation time (on average, hopefully slightly depending on the trend). > > On Fri, Jun 12, 2015, 20:27 Matt Whitlock wrote: > >> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: >> > Peter it's not clear to me that your described protocol is free of miner >> > influence over the vote, by artificially generating transactions which >> they >> > claim in their own blocks >> >> Miners could fill their blocks with garbage transactions that agree with >> their vote, but this wouldn't bring them any real income, as they'd be >> paying their own money as fees to themselves. To get real income, miners >> would have to vote in accordance with real users. >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >