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>
User-Agent: Roundcube Webmail/1.0.5
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Wrapping up the block size debate with voting
Precedence: list

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-----