MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Sun, 30 Aug 2015 13:13:54 -0400
From: jl2012@xbt.hk
To: =?UTF-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
In-Reply-To: <CABm2gDo66UzhLU3Dgc6Cj=0Au4xJNv-U9GUv8JaryakQFJ=VQA@mail.gmail.com>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
	<CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
	<CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
	<2081355.cHxjDEpgpW@crushinator>
	<A30CC2E3-A769-445C-95A2-35B963EFC283@gmail.com>
	<CAB+qUq7ZzLHrFZ5FQazrcALA-b-jFh_bf-XX1GaJbGY1KQB5YA@mail.gmail.com>
	<CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@mail.gmail.com>
	<CABm2gDreJ1PwZu3WgZdj_RR0W9JoQTF9w-Qwyfoh6uk1EM0ajg@mail.gmail.com>
	<CAOG=w-uYFbyUF+PZABNvMqHei2-yuoCETtXnfkYV-Rr9-pPKuw@mail.gmail.com>
	<CADJgMzvJDSk6oZMZPc4C8ENHhGvspdeF7WURfnY6OPKWs33a7w@mail.gmail.com>
	<CABm2gDo66UzhLU3Dgc6Cj=0Au4xJNv-U9GUv8JaryakQFJ=VQA@mail.gmail.com>
Message-ID: <8faa4df0135b558e5cd064ccaec09e73@xbt.hk>
User-Agent: Roundcube Webmail/1.0.5
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Consensus based block size retargeting algorithm
 (draft)
Precedence: list

Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到:

> 
> I still don't see the point in having a lower moving size maximum.
> If 8 MB is mining-centralization-safe, let's move directly to 8 MB
> without adding this seemingly useless extra complexity.
> If it's not, mining voting on a lower moving maximum won't make it 
> safer.
> 
> Once we have more objective tools (centralization metrics, simulators,
> etc...) to determine whether or not a block size is
> mining-centralization-safe for a given point in time (looking at
> current centralization and current technology available), I don't see
> the problem with repeating the equivalent of bip102 periodically
> (every 2 years?) to adapt the size to better technology or lower
> mining centralization.
> It would be also helpful to have a tool to somehow measure "size
> increase urgency" (ie right now free transactions get mined and blocks
> aren't full or close to be full, I don't think the current general
> sense of urgency on this matter is justified).
> 
> With all respect, I believe bip100 and this proposal are
> over-engineering; and bip101 and bip103 (pieter's) are
> overly-optimistic (in their exponential technological growth
> assumptions).

This is based on the assumption that miners would always like to use up 
the last byte of the available block size. However, this is just not 
true:

1. The 6 year blockchain history has shown that most miners have a soft 
cap with their block size.

2. Chinese miners, controlling 60% of the network, rejected Gavin's 
initial 20MB proposal and asked for 8MB: 
http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size

3. BTCChina supports BIP100 and will vote for 2MB at the beginning, with 
8MB as a mid-term goal: 
https://vip.btcchina.com/page/noticetemplate?id=100.
BTCChina is controlling 12% of the network in the past month. If BIP100 
uses the 20-percentile vote as the block size, it takes only 8% more 
vote to keep the size at 2MB

For many reasons miners may want to have a smaller block size, which we 
don't need to list them here. Although they can limit it by a softfork 
or even 51% attack, it is a very violent process. Why don't we just 
allow them to vote for a lower limit?

So I think the right way is to choose a mining-centralization-safe 
limit, and let it free float within a range based on miner's vote. If we 
are lucky enough to have some responsible miners, they will keep it as 
low as possible, until the legitimate tx volume catches up. Even in the 
worst case, the block size is still mining-centralization-safe. The 
upper limit may increase linearly, if not exponentially, until we find a 
better long-term solution. (sort of a combination of BIP100 and 101, 
with different parameters)

--------
For the matter of "urgency", I agree with you that there is no actual 
urgency AT THIS MOMENT. However, if a hardfork may take 5 years to 
deploy (as you suggested), we really have the urgency to make a decision 
now. Actually, the main point is not urgency but uncertainty. We have 
debated for 5 years. Why won't we have 5 more years of debate, plus 5 
years of deployment delay? Are we sticking to 1MB for 10 years? In that 
case Bitcoin Core must be abandoned by the economic majority and a 
Schism fork must occur.