Re: [Bitcoin-development] Block Size Increase Requirements

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

On Sat, May 30, 2015 at 07:42:16AM +0800, Chun Wang wrote:
> Hello. I am from F2Pool. We are currently mining the biggest blocks on
> the network. So far top 100 biggest bitcoin blocks are all from us. We
> do support bigger blocks and sooner rather than later. But we cannot
> handle 20 MB blocks right now. I know most blocks would not be 20 MB
> over night. But only if a small fraction of blocks more than 10 MB, it
> could dramatically increase of our orphan rate, result of higher fee
> to miners. Bad miners could attack us and the network with artificial
> big blocks. As yhou know, other Chinese pools, AntPool, BW, they
> produces ASIC chips and mining mostly with their own machines. They do
> not care about a few percent of orphan increase as much as we do. They
> would continue their zero fee policy. We would be the biggest loser.
> As the exchanges had taught us, zero fee is not health to the network.
> Also we have to redevelop our block broadcast logic. Server bandwidth
> is a lot more expensive in China. And the Internet is slow. Currently
> China has more than 50% of mining power, if block size increases, I
> bet European and American pools could suffer more than us. We think
> the max block size should be increased, but must be increased
> smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
> and so on. Thanks.

Great to hear from you!

Yeah, I'm pretty surprised myself that Gavin never accepted the
compromises offered by others in this space for a slow growth solution,
rather than starting with over an order of magnitude blocksize increase.
This is particularly surprising when his own calculations - after
correcting an artithmetic error - came up with 8MB blocks rather than
20MB.

Something important to note in Gavin Andresen's analysises of this issue
is that he's using quite optimistic scenarios for how nodes are
connected to each other. For instance, assuming that connections between
miners are direct is a very optimistic assumption that depends on a
permissive, unregulated, environment where miners co-operate with each
other - obviously that's easily subject to change! Better block
broadcasting logic helps this in the "co-operation" case, but there's
not much it can do in the worst-case.


Unrelated: feel free to contact me directly if you have any questions
re: the BIP66 upgrade; I hear you guys were planning on upgrading your
mining nodes soon.

-- 
'peter'[:-1]@petertodd.org
00000000000000000db932d1cbd04a29d8e55989eda3f096d3ab8e8d95eb28e9

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]