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 999D698 for ; Tue, 4 Aug 2015 09:22:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C66FE176 for ; Tue, 4 Aug 2015 09:22:47 +0000 (UTC) Received: from localhost ([::1]:37475 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZMYQo-000kth-67; Tue, 04 Aug 2015 05:22:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 04 Aug 2015 05:22:46 -0400 From: jl2012@xbt.hk To: Pieter Wuille In-Reply-To: References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk> Message-ID: <202974587b08f03d588ab1ebbd106d06@xbt.hk> X-Sender: jl2012@xbt.hk User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 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 09:22:48 -0000 > Bitcoin's consensus rules are a consensus system What is your definition of "consensus"? Do you mean 100% agreement? Without a vote how do you know there is 100% (or whatever percentage) agreement? > Find a solution that everyone agrees on, or don't. Who are the "everyone"? Pieter Wuille 於 2015-08-04 05:03 寫到: > 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" > wrote: > >> As now we have some concrete proposals >> > (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html >> [1]), 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 usual 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 >> “real” difference. “No change” 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 >> “balance” of each scriptPubKey is calculated and this is the >> weight of the vote. People will 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 in 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, >> OKCoin, 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, payment 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 one vote. Vote must be sent from the node’s IP address. >> >> -------------------- >> Voting system >> >> Single transferable vote is applied. >> (https://en.wikipedia.org/wiki/Single_transferable_vote [2]). 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. >> >> -------------------- >> Interpretation of results: >> >> 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. >> >> -------------------- >> Technical issues: >> >> Voting by the miners, developers, exchanges, and merchants are >> probably the easiest. We need a trusted person to verify the >> voters’ identity by email, website, or digital signature. The >> trusted person will collect votes 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 after 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 since they are contributing more than other people. >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [3] > > > Links: > ------ > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html > [2] https://en.wikipedia.org/wiki/Single_transferable_vote > [3] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev