public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Vincent Truong <vincent.truong@procabiak.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] User vote in blocksize through fees
Date: Sat, 13 Jun 2015 09:01:02 +1000	[thread overview]
Message-ID: <CACrzPemekkQdn5awnb9tBc9uWs12KLHQAdqu=4zAtjn=O-kkaw@mail.gmail.com> (raw)
In-Reply-To: <CABr1YTd0wcOC8+KSPCPHrx5Ob4nY3azed46gS+nR_NzmxDiTzw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5209 bytes --]

(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@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@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@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 mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 6785 bytes --]

  reply	other threads:[~2015-06-12 23:01 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-12 18:11 [Bitcoin-development] User vote in blocksize through fees Peter Todd
2015-06-12 18:20 ` Mark Friedenbach
2015-06-12 18:26   ` Matt Whitlock
2015-06-12 18:36     ` Peter Todd
2015-06-12 18:56     ` Jannes Faber
     [not found]       ` <CABr1YTfowMqgDZoWhDXiM0Bd3dwhVo6++FOvLntGc2HkApEbGw@mail.gmail.com>
2015-06-12 20:04         ` Eric Lombrozo
2015-06-12 23:01           ` Vincent Truong [this message]
2015-06-12 23:11             ` Luke Dashjr
2015-06-12 23:23           ` Aaron Gustafson
2015-06-12 18:22 ` Matt Whitlock
2015-06-12 18:34   ` Peter Todd
2015-06-12 18:36     ` Matt Whitlock
2015-06-12 18:39       ` Benjamin
2015-06-12 18:47         ` Peter Todd
2015-06-12 18:44       ` Peter Todd
2015-06-12 18:52         ` Matt Whitlock
2015-06-12 18:54         ` Matt Whitlock
2015-06-12 18:56           ` Aaron Gustafson
2015-06-13 22:20 ` Danny Thorpe
2015-06-13 22:24   ` Eric Lombrozo
2015-06-14  4:55   ` Chun Wang
2015-06-14  4:59     ` Jeff Garzik
2015-06-14  5:08     ` Eric Lombrozo
2015-06-14  5:13       ` Jeff Garzik
2015-06-14  5:20         ` Eric Lombrozo
2015-06-14  5:36           ` Jeff Garzik
2015-06-14 10:06             ` Mats Henricson
2015-06-14 10:34               ` Benjamin
2015-06-14 15:07                 ` Jeff Garzik
2015-06-14 21:59                   ` odinn
2015-06-14 20:10                 ` Eric Lombrozo
2015-06-14 14:42               ` Jeff Garzik
2015-06-14 22:26                 ` Mike Hearn
2015-06-15  3:59             ` Eric Lombrozo
2015-06-14  4:16 ` Stephen
2015-06-14  4:50   ` Eric Lombrozo
2015-06-14  4:56   ` Jeff Garzik
2015-06-14  7:19 ` Ashley Holman
2015-06-13 23:57 Raystonn
2015-06-14  4:28 ` odinn
2015-06-14  5:46   ` Aaron Voisine
2015-06-14 21:38     ` odinn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACrzPemekkQdn5awnb9tBc9uWs12KLHQAdqu=4zAtjn=O-kkaw@mail.gmail.com' \
    --to=vincent.truong@procabiak.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=elombrozo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox