(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 elombr...@gmail.com 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 j.fa...@elevate.nl 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 b...@mattwhitlock.name 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
