From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 980627C3 for ; Tue, 4 Aug 2015 10:22:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB87F13D for ; Tue, 4 Aug 2015 10:22:29 +0000 (UTC) Received: by qgeh16 with SMTP id h16so2715120qge.3 for ; Tue, 04 Aug 2015 03:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=u8G/IMgo2Eslz9eh699xE0gfT4ZRaT+2QGB0w40eqEY=; b=iPzwr99gL2LDBAtFNakFcHcLi2R/cR6/EgdBAxhssRQTb0Bz9GuRl9U5nCKL9J2JB/ k7aNTDbpypKO+n1QARk7kVnuLdcftDF+1UR7o2rFl4gKD7TaI73O2p72vG9fnQpVYZCt W67pjiuDXCNObXmmA9VP6esQI76IMs2m73rJU+TyUhxcU/1uFew7P94AqxQyLzm14pQN cikQP31uQD7WvmpjdQM1rlwAl48T9Z/JNxLJp1b6BGUcsXV9Sj8ecfuTsYUJ/6DX/6Ht qI/tu28zvhbcxz1JFaiMTPv50epu0gG2bv1i2hDNuf3U+qbARznkb8CJ/Ha75ulf7okE nMMw== MIME-Version: 1.0 X-Received: by 10.140.86.137 with SMTP id p9mr5054551qgd.89.1438683748961; Tue, 04 Aug 2015 03:22:28 -0700 (PDT) Received: by 10.140.93.162 with HTTP; Tue, 4 Aug 2015 03:22:28 -0700 (PDT) In-Reply-To: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk> References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk> Date: Tue, 4 Aug 2015 11:22:28 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11c12436cd15c3051c79a9cf X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Wrapping up the block size debate with voting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 10:22:30 -0000 --001a11c12436cd15c3051c79a9cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=9C1=E2=80=9D, =E2=80=9C2=E2= =80=9D, =E2=80=9C3=E2=80=9D, etc, or use =E2=80=9CN=E2=80=9D to > indicate rejection of a candidate. > Vote counting starts with every voter=E2=80=99s first choice. The candida= te with > fewest votes is eliminated and those votes are transferred according to > their second choice. This process repeats until only one candidate is lef= t, > which is the most popular candidate. The result is presented as the > approval rate: final votes for the most popular candidate / all valid vot= es > > After the most popular candidate is determined, the whole counting proces= s > 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. --001a11c12436cd15c3051c79a9cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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 =E2=80=9C1=E2=80=9D, =E2=80=9C2=E2=80=9D, =E2= =80=9C3=E2=80=9D, etc, or use =E2=80=9CN=E2=80=9D to indicate rejection of = a candidate.
Vote counting starts with every voter=E2=80=99s 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 le= ft, which is the most popular candidate. The result is presented as the app= roval 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 rat= e for the second most popular candidate. The process repeats until all prop= osals are ranked with the approval rate calculated.
Instant runoff voting is not a good system for finding a conse= nsus of the voters.=C2=A0

h= ttp://zesty.ca/voting/sim/

The main issue here is the= "Squeezing out" of center opinions.=C2=A0

If = the middle option is acceptable to almost everyone but is only the top choi= ce of 20%, then it will lose in round one and leave only extreme options re= maining.

Approval is a better system for a con= sensus.

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.=C2=A0 If voters are honest, it allows a= middle ground to be reached.

If everyone votes strategic= ally, it becomes approval voting.=C2=A0 With consensus, there is an assumpt= ion that a significant fraction of the community would be willing to be hon= est rather than strategic.

The outcome is poss= ible a final decision but not a binding decision.=C2=A0 Voters need to reco= gnise that failing to find a middle ground could mean they get their way bu= t they split the community.

Additio= nally, since the point is to determine parameters, you don't necessaril= y need to select from discrete candidates.

- Initial new = size
- Rate of increase
- Maximum size

They are just numbers.=C2=A0 You could have votes indi= cate what they want, and then use the median as the consensus option.
The exception is to have the miners choose what the size is (s= ubject to limits).=C2=A0 That option is already entirely in the hands of th= e miners and they could do it unilaterally.
--001a11c12436cd15c3051c79a9cf--