path: root/2a/745fe1120acfcb7692ac75b13f3e1bfbe620ed

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 CEE4B1137
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 31 Aug 2015 18:50:32 +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 EAE9E215
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 31 Aug 2015 18:50:31 +0000 (UTC)
Received: from localhost ([::1]:45214 helo=server47.web-hosting.com)
	by server47.web-hosting.com with esmtpa (Exim 4.85)
	(envelope-from <jl2012@xbt.hk>)
	id 1ZWU9x-001idS-GJ; Mon, 31 Aug 2015 14:50:25 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Mon, 31 Aug 2015 14:50:25 -0400
From: jl2012@xbt.hk
To: =?UTF-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
In-Reply-To: <CABm2gDp=1XHzyXF=JbVLWzfyuFKSnbMbDwLk_2NpWq5s3vukpA@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>
	<8faa4df0135b558e5cd064ccaec09e73@xbt.hk>
	<CABm2gDp=1XHzyXF=JbVLWzfyuFKSnbMbDwLk_2NpWq5s3vukpA@mail.gmail.com>
Message-ID: <2cae2c1968b9d519a3ebc4be2d7f9a42@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=0.1 required=5.0 tests=BAYES_50,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] Consensus based block size retargeting algorithm
 (draft)
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: Mon, 31 Aug 2015 18:50:32 -0000

Jorge Timón 於 2015-08-30 14:56 寫到:
> On Sun, Aug 30, 2015 at 7:13 PM,  <jl2012@xbt.hk> wrote:
>> 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
>> [...]
> 
> No, I'm not making such assumption. I'm focusing on what they CAN do,
> while suspending judgement on their good will and not trying to
> predict their future behavior from historic behaviour.
> With 60% of the hashrate, you can easily get 100% by orphaning
> everybody else's blocks. More importantly, being under the same
> jurisdiction they can be forced to behave in certain way (for example,
> censor transactions) by law.
> I'm very worried about the current situation no matter how benevolent
> current miners are. Thus weakening the only limit to mining
> centralization that we have at the consensus rule level seems
> extremely risky at this point.

The reason for 60% of block were generated in China is same as the 
reason for 60% of your clothes were made in China. The electricity there 
is the cheapest on the planet. Many dams were built in the past 10 years 
and now they have huge amount of surplus electricity due to economic 
downturn.

Not sure if you are aware of this thread: 
https://bitcointalk.org/index.php?topic=1072474.0 . Could you imagine 
this in any developed country? As long as mining is largely dependent on 
energy, there is no hope to break the balance/imbalance.

Bandwidth is probably only a few percent of miners' cost. There is no 
evidence that the current level of centralization is a result of block 
size. Instead, clear evidence has shown that centralization is a result 
of pool mining*, invention of ASIC, and disparity of energy cost. (* 
People started pool mining in 2010 because they wanted lower variance, 
not because of the inability to run a full node)


>> 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)
> 
> My point is, a "soft cap" determined by miners clearly doesn't protect
> us from mining centralization: the "hard cap" does.
> Knowing that, and given that miners can currently set their own policy
> block size maximum, what does this "voting on a lower limit" achieve?
> What are the gains? Why are we "lucky" if they keep the lower one as
> low as possible?

Even if we could quantify the level of centralization, it is a continuum 
and we must compromise between utility and centralization. Unless 
BIP101/103 is adopted, adjusting the hard cap always require a hardfork. 
For obvious technical and political reasons we can't have hardfork too 
frequently. Therefore, we need to leave some leeway: the hard cap may be 
a bit too high for today, but we are sure that technology will catch up 
in the near future.

Assuming we have plenty amount of "benevolent" miners, they will keep 
the block size low unless there is a real demand for larger block space. 
This is different from setting an individual soft limit, as that will 
lead to block size scarcity and therefore higher tx fee, which may be 
good for all miners. And as we say "miners can always decrease the block 
size with softfork or 51% attack", BIP100 materializes this possibility 
in a much smoother way.

I say "lucky" because I wholeheartedly believe it is good to keep the 
block as small as we really need. We can't do this by an equation so I 
would prefer to leave the power to miners (and they always have this 
power, anyway).
> 
>> 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.
> 
> Thank you for admitting it is not urgent!
> I suggested 5 years for the concrete hardfork in bip99 because it's
> clearly non-urgent and I wanted to be very conservative. I'm happy to
> reduce that to say, 1 year (specially given that the change is very
> simple to implement).
> For a simple block size change (like, say bip102) 1 year (maybe 6
> months + miner's confirmation) is probably more than enough as well.
> And we can always deploy an urgency hardfork if it is necessary.
> 
>> 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.
> 
> Fortunately we haven't been discussing this for 5 years, I don't know
> where you get that from.

Jeff and Satoshi discussed this in 2010, although the flame throwing 
debate did not start until 2013.

> A schism fork it's certainly always a possibility but I would only
> consider it after an urgency hardfork (once the issue becomes urgent)
> fails due to not being uncontroversial.
> Would you agree with me on that?
> What would be your criterion for considering an increase in block size 
> urgent?

The problem is the definition of "urgency" itself is controversial. And 
I believe an urgent hardfork should only be done as a bug fix, not 
implementation of a new feature. Block size increase should be a planned 
feature, as we don't want the tx fee raised to 10USD, before suddenly 
dropping to 0.01USD with the hardfork.

I don't think it's urgent today because my free tx always get mined. I 
don't know what is urgent and different people have different 
definition, but in general I think that should be measured by tx fee in 
USD. 0.001USD/byte may be intolerable for many people. (It's about 
$0.0001/byte now, and $0.0005/byte when it was $1200/BTC). It's not 
difficult to reach this level given the halving and potential bull 
market is coming.

> Mine is: we should consider a block increase only when minimum market
> fees for transactions to be mined (currently zero satoshis) increase
> above a high fee (admittedly undefined, but certainly greater than
> zero).

As I argued above, it's already too late when things become really 
urgent. That will lead to serious market disruption, and the uncertainty 
could be very harmful to the development of the bitcoin economy.

> Even if it's "urgent", I think we should only increase the maximum if,
> at the same time, the new size can be considered safe
> mining-centralization-wise (unfortunately we don't have any metric to
> measure that nor enough tools to realistically simulate different
> sizes in different network topologies at the moment). But once we have
> them, the next discussion will be much simpler, so I don't see the
> need for block size maximum that changes over time (neither
> exponentially nor linearly).
> 
> Would you agree with me that mining centralization should be the most
> important criterion when changing the block size maximum rule rather
> than the level of minimum fees?

As I said above, strictly limiting the block size may have little effect 
on mining centralization (because block size at this level is not a 
determining factor), while it may seriously suppress the utility.

I'm all for mining decentralization but block size is just not the right 
way to improve the situation.

> If the community can't agree on this, I'm afraid there will be a
> schism hardfork eventually. Another possibility is that those who
> aren't concerned with mining centralization start their own altcoin
> (centralizedcoin? ), maybe a spinoff [
> https://bitcointalk.org/index.php?topic=563972.0 ] if they want to
> keep Bitcoin's utxo at the moment of the separation.
> 
> But if the community agrees with this and just disagrees on the
> maximum block size consensus rule having any effect on mining
> centralization (like Gavin and I disagree), we should calm down and
> use scientific processes to find out what the relation between the two
> actually is (if there's any relation at all).
> 
> Would you agree with me on this?

I agree with you, but the balance between centralization and utility is 
also important. (and I believe the difference between 1MB and 8MB is 
tolerable, at least I must keep my full node running at this level)

I also have an idea to have a "decentralizedcoin", with very small 
blocks and everyone could mine with a CPU. That would be interesting if 
it is backed by famous devs in this area and is not 
yet-another-scamcoin.