path: root/3d/cea0eb24e147ba594c162adc677eb8ef5e7ccf

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 999D698
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <jl2012@xbt.hk>)
	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 <pieter.wuille@gmail.com>
In-Reply-To: <CAPg+sBgvMS112vO3=TjBXitmXLLa1CngeqmK+RWqwR+WOoj2VA@mail.gmail.com>
References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk>
	<CAPg+sBgvMS112vO3=TjBXitmXLLa1CngeqmK+RWqwR+WOoj2VA@mail.gmail.com>
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 <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: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"
> <bitcoin-dev@lists.linuxfoundation.org> 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