From: Tier Nolan <tier.nolan@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Wrapping up the block size debate with voting
Date: Tue, 4 Aug 2015 11:22:28 +0100 [thread overview]
Message-ID: <CAE-z3OVoMwDTmNt=WX3t-FUqx4HP9c02QmOMa==wH0xXczFrnw@mail.gmail.com> (raw)
In-Reply-To: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk>
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
On Tue, Aug 4, 2015 at 8:50 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> --------------------
> Voting system
>
> Single transferable vote is applied. (
> https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are
> required to rank their preference with “1”, “2”, “3”, etc, or use “N” to
> indicate rejection of a candidate.
> Vote counting starts with every voter’s first choice. The candidate with
> fewest votes is eliminated and those votes are transferred according to
> their second choice. This process repeats until only one candidate is left,
> which is the most popular candidate. The result is presented as the
> approval rate: final votes for the most popular candidate / all valid votes
>
> After the most popular candidate is determined, the whole counting process
> is repeated by eliminating this candidate, which will find the approval
> rate for the second most popular candidate. The process repeats until all
> proposals are ranked with the approval rate calculated.
>
Instant runoff voting is not a good system for finding a consensus of the
voters.
http://zesty.ca/voting/sim/
The main issue here is the "Squeezing out" of center opinions.
If the middle option is acceptable to almost everyone but is only the top
choice of 20%, then it will lose in round one and leave only extreme
options remaining.
Approval is a better system for a consensus.
Each voter can indicate which of the proposals is approved/accepted and the
option with the most support wins.
If one option has 80% support and another has 90% support, then both make a
good choice (though the 90% one has won).
Range voting allows more accuracy, if that is an issue. If voters are
honest, it allows a middle ground to be reached.
If everyone votes strategically, it becomes approval voting. With
consensus, there is an assumption that a significant fraction of the
community would be willing to be honest rather than strategic.
The outcome is possible a final decision but not a binding decision.
Voters need to recognise that failing to find a middle ground could mean
they get their way but they split the community.
Additionally, since the point is to determine parameters, you don't
necessarily need to select from discrete candidates.
- Initial new size
- Rate of increase
- Maximum size
They are just numbers. You could have votes indicate what they want, and
then use the median as the consensus option.
The exception is to have the miners choose what the size is (subject to
limits). That option is already entirely in the hands of the miners and
they could do it unilaterally.
[-- Attachment #2: Type: text/html, Size: 3445 bytes --]
next prev parent reply other threads:[~2015-08-04 10:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-04 7:50 jl2012
2015-08-04 9:03 ` Pieter Wuille
2015-08-04 9:22 ` jl2012
2015-08-04 9:29 ` Hector Chu
2015-08-04 9:23 ` Venzen Khaosan
2015-08-04 9:44 ` jl2012
2015-08-04 10:22 ` Tier Nolan [this message]
2015-08-06 23:26 ` Dave Scotese
2015-08-06 23:32 ` Pieter Wuille
2015-08-07 0:37 ` Will
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='CAE-z3OVoMwDTmNt=WX3t-FUqx4HP9c02QmOMa==wH0xXczFrnw@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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