public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Vincent Truong <vincent.truong@procabiak.com>
To: Stephen Morse <stephencalebmorse@gmail.com>
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
Date: Wed, 3 Jun 2015 13:08:17 +1000	[thread overview]
Message-ID: <CACrzPe=vNd8T0B4DGH3dTE9S9S1jEU9k6_5Uz_NUP1ZEgC8uYA@mail.gmail.com> (raw)
In-Reply-To: <CABHVRKS5Mnp9vSJ6mZwNroY7jbBJx+4d+m4hVpWONisaMvBNUw@mail.gmail.com>

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

Some changes:

Votes need to be 100%, not 50.01%. That way small miners have a fair
chance. A 50.01% vote means large miners call the shots.

Users (people who make transactions) need to vote. A vote by a miner
shouldn't count without user votes. Fee incentives should attract
legitimate votes from miners. A cheating miner will be defeated by another
miner who includes those votes, and take the fees.

This lets wallet providers and exchanges cast votes (few wallets will
implement prompts and will just auto vote, so if you don't agree, switch
wallets. Vote with your wallet).

~Vince
On Jun 3, 2015 12:34 PM, "Stephen Morse" <stephencalebmorse@gmail.com>
wrote:

> Pindar,
>
> yes and it's a good idea to separate the hard/soft fork upgrades. The
>> point being here is that we're also establishing a process for the
>> community to self-determine the way forward in a transparent and verifiable
>> manner.
>>
>> What's not to like? :)
>>
>> I'll probably have some time on Sunday to help hack something up but I
>> don't think this is that heavy a coding lift? What am I missing?
>>
>
> As Matt mentioned, many members of the bitcoin community would be hesitant
> about giving miners this much power. It essentially lets them vote to
> change the rules of the system. But miners are not the only part of this
> ecosystem, and they are not the only ones affected by the choice of block
> size limit, so they probably shouldn't be the only ones with a vote.
> Instead, we vote with the software we run, and all upgrade.
>
> So, while I think an idea like this has its merits, I would bet that it's
> fairly unlikely to get enough support to be merged into bitcoin core.
>
> Best,
> Stephen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

  reply	other threads:[~2015-06-03  3:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-31 19:04 [Bitcoin-development] Max Block Size: Simple Voting Procedure Stephen Morse
2015-06-02 21:26 ` Matt Whitlock
2015-06-03  0:30   ` Stephen Morse
     [not found] ` <CAM7BtUod0hyteqx-yj8XMwATYp73Shi0pvdcTrW0buseLGc_ZQ@mail.gmail.com>
     [not found]   ` <CABHVRKT7H1p67Bz_T_caaGFnfuswnC+kXKGdkpRhtXUZQv3HtQ@mail.gmail.com>
     [not found]     ` <CAM7BtUrN9D__ha63Qfs2Fi4HSUFWb8BArHni9yFKRSdLSxCNnA@mail.gmail.com>
2015-06-03  2:33       ` Stephen Morse
2015-06-03  3:08         ` Vincent Truong [this message]
2015-06-03  3:36           ` Stephen Morse
2015-06-03  4:18         ` Pindar Wong

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='CACrzPe=vNd8T0B4DGH3dTE9S9S1jEU9k6_5Uz_NUP1ZEgC8uYA@mail.gmail.com' \
    --to=vincent.truong@procabiak.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=stephencalebmorse@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