From: Peter Todd <pete@petertodd•org>
To: Chun Wang <1240902@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Date: Sun, 31 May 2015 09:05:30 +0200 [thread overview]
Message-ID: <20150531070530.GD12966@muck> (raw)
In-Reply-To: <CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2015-05-31 7:05 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 22:02 Matt Corallo
2015-05-07 23:24 ` Joseph Poon
2015-05-08 0:05 ` Peter Todd
2015-05-08 6:33 ` Arkady
2015-05-08 10:03 ` Mike Hearn
2015-05-08 16:37 ` Peter Todd
2015-05-08 19:47 ` Tier Nolan
2015-05-09 3:08 ` Peter Todd
2015-05-16 4:39 ` Stephen
2015-05-16 11:29 ` Tier Nolan
2015-05-16 11:25 ` Tier Nolan
2015-05-29 22:36 ` Gavin Andresen
2015-05-29 23:25 ` Matt Corallo
[not found] ` <CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
2015-05-30 19:32 ` Matt Corallo
2015-05-30 20:37 ` Gavin Andresen
2015-05-31 14:46 ` Jorge Timón
2015-05-31 14:49 ` Gavin Andresen
2015-05-31 14:59 ` Jorge Timón
2015-05-31 15:08 ` Gavin Andresen
2015-05-31 15:45 ` Jorge Timón
2015-05-29 23:42 ` Chun Wang
2015-05-30 13:57 ` Gavin Andresen
2015-05-30 14:08 ` Pindar Wong
2015-05-30 22:05 ` Alex Mizrahi
2015-05-30 23:16 ` Brian Hoffman
2015-05-31 0:13 ` Alex Mizrahi
2015-05-31 5:05 ` gb
[not found] ` <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
2015-05-31 1:31 ` [Bitcoin-development] Fwd: " Chun Wang
2015-05-31 2:20 ` Pindar Wong
2015-05-31 12:40 ` Gavin Andresen
2015-05-31 13:45 ` Alex Mizrahi
2015-05-31 14:54 ` Gavin Andresen
2015-05-31 22:55 ` Alex Mizrahi
2015-05-31 23:23 ` Ricardo Filipe
2015-05-31 23:40 ` Pindar Wong
2015-05-31 23:58 ` Ricardo Filipe
2015-06-01 0:03 ` Pindar Wong
2015-06-01 7:57 ` Alex Mizrahi
2015-06-01 10:13 ` Mike Hearn
2015-06-01 10:42 ` Pindar Wong
2015-06-01 11:26 ` Peter Todd
2015-06-01 12:19 ` Pindar Wong
2015-06-01 11:02 ` Chun Wang
2015-06-01 11:09 ` Pindar Wong
2015-06-01 11:20 ` Chun Wang
2015-06-01 13:59 ` Gavin Andresen
2015-06-01 14:08 ` Chun Wang
2015-06-01 15:33 ` Mike Hearn
2015-06-01 16:06 ` Ángel José Riesgo
2015-06-01 14:46 ` Oliver Egginger
2015-06-01 14:48 ` Chun Wang
2015-06-01 16:43 ` Yifu Guo
2015-06-01 20:01 ` Roy Badami
2015-06-01 20:15 ` Roy Badami
2015-06-01 13:21 ` Mike Hearn
2015-06-01 12:29 ` Warren Togami Jr.
2015-06-01 13:15 ` Gavin Andresen
2015-05-31 12:52 ` Gavin Andresen
2015-05-31 13:31 ` [Bitcoin-development] [Bulk] " gb
2015-05-31 19:49 ` Gavin Andresen
2015-05-31 14:17 ` [Bitcoin-development] " Dave Hudson
2015-05-31 14:34 ` Yifu Guo
2015-05-31 14:47 ` Gavin Andresen
2015-05-31 7:05 ` Peter Todd [this message]
2015-05-31 12:51 ` [Bitcoin-development] " Gavin Andresen
2015-05-30 23:18 Raystonn
2015-05-31 0:32 ` Alex Mizrahi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150531070530.GD12966@muck \
--to=pete@petertodd$(echo .)org \
--cc=1240902@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox