From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pieter.wuille@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0FDE97F for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 4 Aug 2015 09:03:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 997A511E for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 4 Aug 2015 09:03:23 +0000 (UTC) Received: by ioeg141 with SMTP id g141so10485079ioe.3 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 04 Aug 2015 02:03:23 -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:to :cc:content-type; bh=KKFZZwMbc6zFFi1SiKqbB7BSeUVa6dszV9TpSl6immU=; b=hs6txM0xqt8zsHdrO5HwWPwkwmnypOvT79Re+/pTYDK1xvhGX6IpinPcmz8sy4qbct nSmH9HYc3YyMuR01x48TMHbT53THIqRVaWAaipojaLvhsbJ2aXnTvrtA3anhUfChM8sf /YbnJu9S0da5NMaGKQxxm4aTDN9LaDhSvUKCGs1TIsDZlQZEYFKIe6mmBRhCBzZ1lNVV TbM/4JgpJZragqohzm1hz/p/QG2ey/BDY8CT1PZ81g107uULvEh1QOkiAiVX7cUw2NK+ YzrrtyVPfkZImAjwbFYg/OZToorl38JyLrRVDfvXnrFK34r2yjbfRpCBU4ABqO/fTCwv Pa7Q== MIME-Version: 1.0 X-Received: by 10.107.37.142 with SMTP id l136mr2369154iol.126.1438679002920; Tue, 04 Aug 2015 02:03:22 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Tue, 4 Aug 2015 02:03:22 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Tue, 4 Aug 2015 02:03:22 -0700 (PDT) In-Reply-To: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk> References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk> Date: Tue, 4 Aug 2015 11:03:22 +0200 Message-ID: <CAPg+sBgvMS112vO3=TjBXitmXLLa1CngeqmK+RWqwR+WOoj2VA@mail.gmail.com> From: Pieter Wuille <pieter.wuille@gmail.com> To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=001a1140269aea3cf2051c788efd X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Tue, 04 Aug 2015 09:03:25 -0000 --001a1140269aea3cf2051c788efd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would like to withdraw my proposal from your self-appointed vote. If you want to let a majority decide about economic policy of a currency, I suggest fiat currencies. They have been using this approach for quite a while, I hear. Bitcoin's consensus rules are a consensus system, not a democracy. Find a solution that everyone agrees on, or don't. On Aug 4, 2015 9:51 AM, "jl2012 via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > As now we have some concrete proposals ( > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.= html), > I think we should wrap up the endless debate with voting by different > stakeholder groups. > > --------------------------------- > Candidate proposals > > Candidate proposals must be complete BIPs with reference implementation > which are ready to merge immediately. They must first go through the usua= l > peer review process and get approved by the developers in a technical > standpoint, without political or philosophical considerations. Any fine > tune of a candidate proposal may not become an independent candidate, > unless it introduces some =E2=80=9Creal=E2=80=9D difference. =E2=80=9CNo = change=E2=80=9D is also one of the > voting options. > --------------------------------- > Voter groups > > There will be several voter groups and their votes will be counted > independently. (The time frames mentioned below are just for example.) > > Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are > eligible to vote. One block one vote. Miners will cast their votes by > signing with the bitcoin address in coinbase. If there are multiple > coinbase outputs, the vote is discounted by output value / total coinbase > output value. > Many well-known pools are reusing addresses and they may not need to > digitally sign their votes. In case there is any dispute, the digitally > signed vote will be counted. > > Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around > early September) are eligible to vote. The total =E2=80=9Cbalance=E2=80= =9D of each > scriptPubKey is calculated and this is the weight of the vote. People wil= l > cast their votes by digital signature. > Special output types: > Multi-sig: vote must be signed according to the setting of the multi-sig. > P2SH: the serialized script must be provided > Publicly known private key: not eligible to vote > Non-standard script according to latest Bitcoin Core rules: not eligible > to vote in general. May be judged case-by-case > > Developers: People with certain amount of contribution in the past year i= n > Bitcoin Core or other open sources wallet / alternative implementations. > One person one vote. > > Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index, > Winkdex, or NYSE Bitcoin index, with 30 days volume >100,000BTC are > invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoi= n, > Huobi, Coinbase. Exchanges operated for at least 1 year with 100,000BTC > 30-day volume may also apply to be a voter in this category. One exchange > one vote. > > Merchants and service providers: This category includes all bitcoin > accepting business that is not centralized fiat-currency exchange, e.g. > virtual or physical stores, gambling sites, online wallet service, paymen= t > processors like Bitpay, decentralized exchange like Localbitcoin, ETF > operators like Secondmarket Bitcoin Investment Trust. They must directly > process bitcoin without relying on third party. They should process at > least 100BTC in the last 30-days. One merchant one vote. > > Full nodes operators: People operating full nodes for at least 168 hours > (1 week) in July 2015 are eligible to vote, determined by the log of > Bitnodes. Time is set in the past to avoid manipulation. One IP address o= ne > vote. Vote must be sent from the node=E2=80=99s IP address. > > -------------------- > 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. > > -------------------- > Interpretation of results: > > It is possible that a candidate with lower ranking to have higher approva= l > rate. However, ranking is more important than the approval rate, unless t= he > difference in approval rate is really huge. 90% support would be excellen= t; > 70% is good; 50% is marginal; <50% is failed. > > -------------------- > Technical issues: > > Voting by the miners, developers, exchanges, and merchants are probably > the easiest. We need a trusted person to verify the voters=E2=80=99 ident= ity by > email, website, or digital signature. The trusted person will collect vot= es > and publish the named votes so anyone could verify the results. > > For full nodes, we need a trusted person to setup a website as an > interface to vote. The votes with IP address will be published. > > For bitcoin holders, the workload could be very high and we may need some > automatic system to collect and count the votes. If people are worrying > about reduced security due to exposed raw public key, they should move > their bitcoin to a new address before voting. > > Double voting: people are generally not allowed to change their mind afte= r > voting, especially for anonymous voters like bitcoin holders and solo > miners. A double voting attempt from these classes will invalidate all > related votes. > > Multiple identity: People may have multiple roles in the Bitcoin ecology. > I believe they should be allowed to vote in all applicable categories sin= ce > they are contributing more than other people. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a1140269aea3cf2051c788efd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">I would like to withdraw my proposal from your self-appointe= d vote.</p> <p dir=3D"ltr">If you want to let a majority decide about economic policy o= f a currency, I suggest fiat currencies. They have been using this approach= for quite a while, I hear.</p> <p dir=3D"ltr">Bitcoin's consensus rules are a consensus system, not a = democracy. Find a solution that everyone agrees on, or don't.</p> <div class=3D"gmail_quote">On Aug 4, 2015 9:51 AM, "jl2012 via bitcoin= -dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bit= coin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribution"><= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">As now we have some concrete proposals (<a hr= ef=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009= 808.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio= n.org/pipermail/bitcoin-dev/2015-July/009808.html</a>), I think we should w= rap up the endless debate with voting by different stakeholder groups.<br> <br> ---------------------------------<br> Candidate proposals<br> <br> Candidate proposals must be complete BIPs with reference implementation whi= ch are ready to merge immediately. They must first go through the usual pee= r review process and get approved by the developers in a technical standpoi= nt, without political or philosophical considerations. Any fine tune of a c= andidate proposal may not become an independent candidate, unless it introd= uces some =E2=80=9Creal=E2=80=9D difference. =E2=80=9CNo change=E2=80=9D is= also one of the voting options.<br> ---------------------------------<br> Voter groups<br> <br> There will be several voter groups and their votes will be counted independ= ently. (The time frames mentioned below are just for example.)<br> <br> Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are eligi= ble to vote. One block one vote. Miners will cast their votes by signing wi= th the bitcoin address in coinbase. If there are multiple coinbase outputs,= the vote is discounted by output value / total coinbase output value.<br> Many well-known pools are reusing addresses and they may not need to digita= lly sign their votes. In case there is any dispute, the digitally signed vo= te will be counted.<br> <br> Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around ea= rly September) are eligible to vote. The total =E2=80=9Cbalance=E2=80=9D of= each scriptPubKey is calculated and this is the weight of the vote. People= will cast their votes by digital signature.<br> Special output types:<br> Multi-sig: vote must be signed according to the setting of the multi-sig.<b= r> P2SH: the serialized script must be provided<br> Publicly known private key: not eligible to vote<br> Non-standard script according to latest Bitcoin Core rules: not eligible to= vote in general. May be judged case-by-case<br> <br> Developers: People with certain amount of contribution in the past year in = Bitcoin Core or other open sources wallet / alternative implementations. On= e person one vote.<br> <br> Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index, Winkdex,= or NYSE Bitcoin index, with 30 days volume >100,000BTC are invited. Thi= s includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin, Huobi, Coin= base. Exchanges operated for at least 1 year with 100,000BTC 30-day volume = may also apply to be a voter in this category. One exchange one vote.<br> <br> Merchants and service providers: This category includes all bitcoin accepti= ng business that is not centralized fiat-currency exchange, e.g. virtual or= physical stores, gambling sites, online wallet service, payment processors= like Bitpay, decentralized exchange like Localbitcoin, ETF operators like = Secondmarket Bitcoin Investment Trust. They must directly process bitcoin w= ithout relying on third party. They should process at least 100BTC in the l= ast 30-days. One merchant one vote.<br> <br> Full nodes operators: People operating full nodes for at least 168 hours (1= week) in July 2015 are eligible to vote, determined by the log of Bitnodes= . Time is set in the past to avoid manipulation. One IP address one vote. V= ote must be sent from the node=E2=80=99s IP address.<br> <br> --------------------<br> Voting system<br> <br> Single transferable vote is applied. (<a href=3D"https://en.wikipedia.org/w= iki/Single_transferable_vote" rel=3D"noreferrer" target=3D"_blank">https://= en.wikipedia.org/wiki/Single_transferable_vote</a>). 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.<br> 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<br= > <br> 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.<br> <br> --------------------<br> Interpretation of results:<br> <br> It is possible that a candidate with lower ranking to have higher approval = rate. However, ranking is more important than the approval rate, unless the= difference in approval rate is really huge. 90% support would be excellent= ; 70% is good; 50% is marginal; <50% is failed.<br> <br> --------------------<br> Technical issues:<br> <br> Voting by the miners, developers, exchanges, and merchants are probably the= easiest. We need a trusted person to verify the voters=E2=80=99 identity b= y email, website, or digital signature. The trusted person will collect vot= es and publish the named votes so anyone could verify the results.<br> <br> For full nodes, we need a trusted person to setup a website as an interface= to vote. The votes with IP address will be published.<br> <br> For bitcoin holders, the workload could be very high and we may need some a= utomatic system to collect and count the votes. If people are worrying abou= t reduced security due to exposed raw public key, they should move their bi= tcoin to a new address before voting.<br> <br> Double voting: people are generally not allowed to change their mind after = voting, especially for anonymous voters like bitcoin holders and solo miner= s. A double voting attempt from these classes will invalidate all related v= otes.<br> <br> Multiple identity: People may have multiple roles in the Bitcoin ecology. I= believe they should be allowed to vote in all applicable categories since = they are contributing more than other people.<br> <br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div> --001a1140269aea3cf2051c788efd--