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 0BBB4486 for ; Tue, 4 Aug 2015 09:45:07 +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 938CE10A for ; Tue, 4 Aug 2015 09:45:03 +0000 (UTC) Received: from localhost ([::1]:40221 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZMYmE-000xc8-NM; Tue, 04 Aug 2015 05:44:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 04 Aug 2015 05:44:54 -0400 From: jl2012@xbt.hk To: venzen@mail.bihthai.net In-Reply-To: <55C084A2.6050401@mail.bihthai.net> References: <1c808715eac12f67cf9865dfd97c0a37@xbt.hk> <55C084A2.6050401@mail.bihthai.net> Message-ID: <881dc07db59514a2e2738d253dec0038@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:45:07 -0000 As I mentioned, the candidate proposals must go through usual peer review process, which includes proper testing, I assume. Scaling down is always possible with softforks, or miners will simply produce smaller blocks. BIP100 has a scaling down mechanism but it still requires miners to vote so it doesn't really make much difference But anyway, this is off-topic, as candidate proposals may include mechanism for scaling down. Venzen Khaosan 於 2015-08-04 05:23 寫到: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It is not scientific or sensible to go from proposal stage straight to > voting and then implementation stage. > > The proposals you have diligently gathered, summarized and presented > in your document must go through testing, and scenario simulation with > published results, in order for objective evaluation to be made > possible. > > For that matter, even "running up against a capacity limit" has not > been simulated or tested. Additionally, (and looking the other way) > there is a lack of provision for scaling DOWN in the current proposals > - - hard to envision, yes - but what goes up will eventually come down. > A global credit contraction is not unlikely, nor is natural disaster, > and these scenarios have implications for usage, scale, degree of > decentralization and security. > > CS is science, there is no reason for this generation not to apply > rigorous Computer Science to Bitcoin. > > Venzen > > > On 08/04/2015 02:50 PM, jl2012 via bitcoin-dev 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 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). 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVwISfAAoJEGwAhlQc8H1mygAH/jxe3C5RjPlsSKfIg+CikEwi > kSttrZKr45s6EzayUqyBjBensgsgQCYKo3RLUq8lSpeJdZSmfu4qis09iZVJmKNX > klA/CTuiHTE8jGgwjAHNeeAI/ZQSFOYictzk4OVTSQWoMuB8Wq6S+QXCiUbulOGH > E/vHQz25ZNPX0+Z1Ypx26kSglBNzWJT1cdtyAvd3SDOTMuRVcH9y4aECSB+399Jt > BT2pBOYCJjrXfuU0lh26yph08UyIKSoToCJ4jxEtBzf4COYppsO0dzHeboYkwLMo > +ZuBhz5Bv9Fy5d6AcQtCUjBJE0dZvyAjf7Zc3U9X5ZXe5sAx/zC36O307YtneHI= > =f/pR > -----END PGP SIGNATURE-----