Vincent Truong [ARCHIVE] on Nostr: š Original date posted:2015-06-12 š Original message:(Sorry for spam, forgot to ...
š
Original date posted:2015-06-12
š Original message:(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" <elombrozo at 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.faber at 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 <bip at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/9f92b4cb/attachment.html>;
š Original message:(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" <elombrozo at 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.faber at 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 <bip at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/9f92b4cb/attachment.html>;