Leak: Bitcoin block size discussion

Subject: Why I'm pushing the block size issue
------------------------

From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Wed, Feb 4, 2015 at 11:09 AM
To: Jeff Garzik <jgarzik@bitpay.com>, Pieter Wuille <pieter.wuille@gmail.com>, Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>


I've been thinking about why I get so worked up over the block size issue, and I believe I've figured it out.

I think we're failing on the most fundamental value proposition for Bitcoin: predictability.

We are, and have been, completely united when it comes to the monetary properties of Bitcoin-- only 21 million coins ever, issued at a completely predictable rate.

If a couple of us started talking about how 0.5% per year inflation was a much better idea and we should switch to that once the block reward gets that low I think that would be terrible for Bitcoin adoption, because consistency and predictability are incredibly important.

I think we are hurting adoption by not having consensus on a clear, predictable plan for how the network will scale up to handle increasing transaction volume.

Do y'all agree or disagree? If I was new to Bitcoin and thinking of starting a Bitcoin-related business, the transaction volume cap would make me seriously reconsider.

I think that dynamic makes the 1MB limit really sticky: no increased transaction volume, because anybody sane will look at the 1MB block size and the unwillingness of us to do anything about it and will decide to innovate somewhere else until the problem gets solved.

If we think "sidechains to the rescue!" or "offchain transactions!" or "payment channels can do everything!" then great, lets privately agree that is the clear, predictable plan and then work on explaining how that is safer and better than increasing the 1MB size.

But I DO think that increasing the maximum block size is easier and safer than any of those other options. And I strongly believe that we're hurting Bitcoin by not having a consistent, united message on how we are going to scale up.


--
--
Gavin Andresen




----------
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, Feb 4, 2015 at 12:02 PM
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Cc: Pieter Wuille <pieter.wuille@gmail.com>, Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>


Some quick thoughts, in random, disconnected order:

1) The existential question that must be answered is:   Is conservatism and risk avoidance in the block-size arena preventing disaster, or shackling us and hindering further growth?

2) It is a good thing that dumb applications like blockchain instant messaging are disincentivized.  Will raising the block size limit before there is a need increase spam?

3) There is no demonstrated need to remove the 1MB limit today.  Is that a self-reinforcing trap?  Goes back to existential question in comment #1.

4) Are the spam limits staying?  They are hardcoded, ugly and economically compress fees.  The plan for changing this would seem interlinked with block size changes.  If spam limits go to zero, what prevents block from being filled 100% to the soft limit at all times -- where spam filler pads out each block?

5) Predictability is a good argument to make.  That is why my proposed block size increase algorithm has always been flat -- +X bytes every Y blocks -- and not game-able.

6) If you are going to change the blocksize, there is also a good (yet radical) argument to make for simply removing the block size limit, implicitly making the limit 32MB message size limit.  Let miners and the market sort it out.  I would recommend creating some projections about orphan rates, sizes and propagation times so that lazy miners will choose a sane policy.











--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Wed, Feb 4, 2015 at 1:41 PM
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Cc: Jeff Garzik <jgarzik@bitpay.com>, Pieter Wuille <pieter.wuille@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>


As an aside,

At FC15 Rainer Böhme  kind of bluntly (german style I guess) hit me
with a 'you're stupid if you think you can just increase the block
size with no effect, there is no incentive basis for that working out
well' and cited
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400519 to me...
which makes a more formalized argument for the fee/security
equilibrium argument.  :)

I need to give Gavin's message some more thought. One thing would be
helpful is some thoughts on where "somewhere else" would be?  Is there
any wellspring of innovation that has a more consistent and coherent
scaling story than we have in Bitcoin?  Whats their answers the the
multitude of concerns around the tradeoffs in this space?

I think we made an error before in backing off the default block size
limit too early. But while it did exist we absolutely did see
soft-full blocks then, which suggests that Jeff's (3) may not be the
case; though its hard to tell.  We've also seen continued increases in
things where people are stuffing non-transaction data like messaging
into the Blockchain with the increase.

Message size limit isn't a limit, since you can carry the network over
other protocols.

----------
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, Feb 4, 2015 at 2:02 PM
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Gavin Andresen <gavin@bitcoinfoundation.org>, Pieter Wuille <pieter.wuille@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>



Second Rainer:  There absolutely will be economic turmoil & consequences to changing the 1MB limit.  I sorta thought this was self-evident :)

It is irrelevant what the limit "should be"  The simple fact of a change radically alters a heretofor static economic equilibrium.  Further, a resource increase presents markets with new supply, and demand (and within elasticity, price) alters accordingly.

This must be stated up front as a cost; hopefully it is a one-time cost.

Any decision has costs and benefits.  The benefits need to outweight the costs.  Leads back to existential comment #1/#3 in prev email...



--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Wed, Feb 4, 2015 at 2:38 PM
To: Jeff Garzik <jgarzik@bitpay.com>
Cc: Gregory Maxwell <gmaxwell@gmail.com>, Pieter Wuille <pieter.wuille@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>


RE: Nicolas' paper: his result applies to an unlimited block size versus "some" limit. I could ping him to see if he has a way of thinking about 1MB versus 100K versus 10MB blocks ....  but since miner revenue is #txns * average_fee * exchange_rate I don't think it is possible to answer, unless we come up with a model for how the number of transactions relates to the exchange rate (I believe more transactions == more utility == higher exchange rate, but don't know how to put a number on that).

We also have no idea how much hashing is "enough to secure the network, but not too much."

Am I alone in believing that predictability is better than One True Optimal Solution?

I'd really like each of you to (privately, here) state what you think the plan should be. I've publicly stated what I think:  Increase max size to 20MB, double it every two years for the next twenty years.

Greg, you said "go to 2MB when we need to."  Can you be more explicit about how we tell "when we need to" ?

Jeff, Pieter, Wladimir:  opinions?

--
--
Gavin Andresen



----------
From: Wladimir <laanwj@gmail.com>
Date: Thu, Feb 5, 2015 at 4:55 AM
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Cc: Jeff Garzik <jgarzik@bitpay.com>, Pieter Wuille <pieter.wuille@gmail.com>, Gregory Maxwell <gmaxwell@gmail.com>



On Wed, 4 Feb 2015, Gavin Andresen wrote:

Do y'all agree or disagree? If I was new to Bitcoin and thinking of starting a Bitcoin-related business, the transaction volume cap would make me seriously reconsider.

I agree. I certainly agree scaling is something that needs attention.

I also think increasing the block size is an acceptable solution for the short term. Given that it is safe of course, and we can convince the users that it is safe. As you've noticed lot of users are deadly afraid of any change to Satoshi's built-in 'magic values' assumptions.

Unlike any change we've made before, this gets kind of policitcal, whether we like it or not :/ People do compare it with say, changing the inflation rate, even though you'd say it should be much less controversial.

I think that dynamic makes the 1MB limit really sticky: no increased transaction volume, because anybody sane will look at the 1MB block size
and the unwillingness of us to do anything about it and will decide to innovate somewhere else until the problem gets solved.

Well, to be honest, in my opinion an increasing block size would be mostly 'scalability theater' in the large picture. Likely that's enough to kick the can down the road a bit, and convince 'anybody sane' but I don't know.

Being kind of sane myself, I've never seen bitcoin's one-blockchain-based system as suitable for scaling up to large enough to handle, say, a substantial part of humanity's daily transactions.

Even with that limitation it's obviously useful, but what if we tried to turn it into something it is not? and broke the current usefulness in the process.
(e.g. concerns about bandwidth usage, increased verification compute requirements, and such that lead to fewer full nodes, concentrated in rich countries, and less useful behind anonimity networks. Also concerns of less resilience due to that, making it less attractive as 'digital gold'.)

If we think "sidechains to the rescue!" or "offchain transactions!" or "payment channels can do everything!" then great, lets privately agree that is the clear, predictable plan and then work on explaining how that is safer and better than increasing the 1MB size.

I would prefer a method of scaling that involves off-chain transactions, or other forms of decentralization.

Broadcasting all transactions to the entire world, having everyone validate say, your coffee or bus ticket purchase borders on the absurd. To handle any kind of adoption as a mainstream (micro-)payment system denominated in Bitcoin we need non-obvious solutions.

... which makes pushing the 'increase block size' button very tempting as it is so easy and obvious. As said, I'm not squarely against it as first step, although what nags me a bit is that it takes the pressure off it may also prevent people from working on more sophisticated solutions for the future.

But I DO think that increasing the maximum block size is easier and safer than any of those other options. And I strongly believe that we're
hurting Bitcoin by not having a consistent, united message on how we are going to scale up.

Easier, certainly. Safer, I don't know. This is an extremely difficult matter either way.

Wladimir

----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Thu, Feb 5, 2015 at 10:53 AM
To: Wladimir <laanwj@gmail.com>
Cc: Jeff Garzik <jgarzik@bitpay.com>, Pieter Wuille <pieter.wuille@gmail.com>, Gregory Maxwell <gmaxwell@gmail.com>


On Thu, Feb 5, 2015 at 4:55 AM, Wladimir <laanwj@gmail.com> wrote:
Being kind of sane myself, I've never seen bitcoin's one-blockchain-based system as suitable for scaling up to large enough to handle, say, a substantial part of humanity's daily transactions.

Let me try to understand-- what part of the increase-the-blocksize-to-handle-all-the-world's-transactions scalability roadmap do you disagree with?

Do you think the computer industry is about to run into a CPU or storage or bandwidth wall? If yes, can you give me references to why you think that?  (all the references I can find say that we should continue scaling up for at least 20 years, except for incorrect 10-year-old predictions that we would hit the wall in 5 or 10 years)

Or do you think people will be making a much larger number of transactions per day in 20 years than they are today? According to my research, the average Western person makes just a hand-full of financial transactions each day.

I believe that the typical personal computer and home network connection 20 years from now WILL be able to handle 70 billion transactions per day. I know that sounds insane, but that is where we will be after 20 years of exponential growth.


RE: politics: I think this can be done, if we are united. A super-majority of people already support raising the max size (just judging by online polls and comments).

I'm sure almost all of the big exchanges and merchants will support it, they all want to scale up (davout at Bitcoin-Central being the only exception-- not surprising, giving his company's name, I suppose).

And I'm fairly certain big miners will agree; after all, it give them more choice, not less.


--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/


----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Thu, Feb 5, 2015 at 2:43 PM
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Cc: Wladimir <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>, Pieter Wuille <pieter.wuille@gmail.com>

too big, it's many multiplies too big.

I'm unlikely to ever support any automatic "grows forever" (or even
'grows to a size we can't clearly support with state of the art
hardware today") proposal; as we can't even build and test software
that is guaranteed to work in that environment (talk about
non-predictability).  We've more or less completely failed at avoiding
massive mining centralization and though its completely apparently
broken now we're doing very little to improve it, I've seen no
argument as to how a node-load induced total loss of decentralization
or a loss-of-security-from-inadequate-fees would play out any
differently.

If indeed "70 billion transactions per day" becomes viable (in all
respects, including incentives and decentralization) 20 years from
now, it should be uncontroversial to increase the limits to accept
that.  Jumping into the unknown is never going to be uncontroversial.
I feel like you're asking me to conceal my concerns from the public in
the name of harmony. I'm not going to do that, though if the public
attacks continue I may well just bow out from Bitcoin entirely-- This
subject is really stressful for me, and with the personal attacks I've
received its adversely impacting my health... even now where I've been
intentionally pretty quiet about the subject.

I'd asked what you thought were were competing against here where
people will turn to, most cryptocurrency systems also have limits...
Iwent looking around some; Ethereum's latest claims (they change
daily) seem to be that they're implementing the fraud proof stuff that
had been talked about in the past in bitcoin-space so even if people
can't run full nodes the properties of the system would be completely
lost, plus using a moving average... and even there they say that it's
unsolved, unclear, and needs future work.  I think ethereum's
technical work is largely the work of madmen ( :) ), and even they
think this is not simple or easy, even given that they're planning on
deploying technology which arguably make the issues less severe (fraud
proofs, and a rolling limit).

----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Thu, Feb 5, 2015 at 4:58 PM
To: Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>, Pieter Wuille <pieter.wuille@gmail.com>


RE: your bandwidth in Mountain View sucking:

Okey dokey, but when I was stuck in Atlanta for the day the big news was "Google Fiber is coming to Atlanta, Charlotte, Raleigh–Durham and Nashville."


On Thu, Feb 5, 2015 at 2:43 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
I'm unlikely to ever support any automatic "grows forever" (or even
'grows to a size we can't clearly support with state of the art
hardware today") proposal; as we can't even build and test software
that is guaranteed to work in that environment (talk about
non-predictability).

I really, really don't understand this attitude-- I woulda thunk you were old enough to be confident that technology DOES improve. In fits and starts, but over the long term it definitely gets better.

All of my calculations assume zero improvements to the software, just network/bandwidth/CPU/storage growth.

  We've more or less completely failed at avoiding
massive mining centralization and though its completely apparently
broken now we're doing very little to improve it, I've seen no
argument as to how a node-load induced total loss of decentralization
or a loss-of-security-from-inadequate-fees would play out any
differently.

I think you're being short-sighted, and mining centralization will ebb and flow for years as technology changes.

My only fear is that some mining-related patents get granted that create a barrier to new entry, but we're already there with state-of-the-art chip fabrication anyway so "meh".


RE: stress:   Is it just the politics, or do you imagine some major technical disaster?  For the politics, I can be the bad guy-- or, even better, make Satoshi the bad guy. Just say honestly "I have my doubts, but bigger blocks is what Satoshi sold way back in the beginning, and staying true to that is important."

 PS: I screwed up the 20MB target-- I should double-count bandwidth for down+up. So starting at 8MB blocks (instead of 16MB) would be "half the bandwidth of a 300GB-per-month-data-cap-connection".

--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/


----------
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Thu, Feb 5, 2015 at 7:32 PM
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Cc: Jeff Garzik <jgarzik@bitpay.com>, Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>


On Wed, Feb 4, 2015 at 8:09 AM, Gavin Andresen
<gavin@bitcoinfoundation.org> wrote:
> I've been thinking about why I get so worked up over the block size issue,
> and I believe I've figured it out.
>
> I think we're failing on the most fundamental value proposition for Bitcoin:
> predictability.

> I think we are hurting adoption by not having consensus on a clear,
> predictable plan for how the network will scale up to handle increasing
> transaction volume.

----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Thu, Feb 5, 2015 at 8:22 PM
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Jeff Garzik <jgarzik@bitpay.com>, Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>


Thanks, Pieter.

So, what kind of size increase WOULD you support right now?

How about:

Start at 1MB.  Follow some exponential increase to 1GB in 20 years, with maximum possible sizes increasing at a constant percentage (so we're always able to test, etc).


RE: letting miners decide:

OK, I'm fine with picking a date or block number for the fork. I think we should have miners produce block.version=4 blocks before then, though, just to trigger the automatic "you need to upgrade" code.


Detailed response to your concerns:

RE: rushed decisions:

Yes, that is why I want there to be a plan NOW, not a year from now when, if we're lucky, transaction fees are at $10 per kilobyte because there is so much demand.

RE: ability for validation:

I don't know what to say-- our code can validate 20MB blocks right now, and I tested 200MB blocks to make sure there are no hidden O(n^2) gotchas waiting.

RE: miner centralization incentives:

Is your argument different from the Peter Todd "there is always a communication advantage for a bigger miner, therefore we will certainly end up with one miner in a server closet" ?

Before convincing myself that O(1) block propagation could work, I would agree that bigger blocks could lead to more centralization. But now I don't think so. I will go back to working on O(1) block propagation as soon as I get a stretch of uninterrupted time.

RE: political danger:

Maybe it would be politically better if I submitted a pull request to Bitcoin Core, it got rejected as too controversial, but then gets pulled into Mike's Bitcoin XT.  If a majority of miners and merchants and exchanges decide to run XT, then So Be It...

RE: simulating the entire network:

Great, lets simulate the entire network with 20MB blocks.  I don't know how to do that, can you help out with that?


--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/


----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Thu, Feb 5, 2015 at 11:48 PM
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Cc: Wladimir van der Laan <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>, Pieter Wuille <pieter.wuille@gmail.com>

----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Fri, Feb 6, 2015 at 10:17 AM
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Wladimir van der Laan <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>, Pieter Wuille <pieter.wuille@gmail.com>


Ok, I'm hearing:

+ You're concerned about propagation delays.

If I can demonstrate running code that has propagation delays less than eleven seconds per hop for (say) 200MB blocks, would that address that concern?

The set reconciliation work should make propagation delays constant for arbitrarily large blocks (assuming that they are not composed mostly of never-before-broadcast transactions; I'm confident we can dis-incentivize miners broadcasting blocks full of never-before-broadcast transactions).

+ The block relay code needs to be smarter, so receiving a very-expensive-to-validate block doesn't bottleneck validating less-expensive-to-validate blocks that might come in.


+ You're concerned about mining centralization, and that larger blocks might make that problem worse.

I'm not sure how to address that, because we don't seem to have a plan for reversing mining centralization with our current 1MB blocks.

If the propagation issue is addressed, would you agree that mining centralization is an orthogonal issue, or is there something else I'm missing?

PS: ARE there any reasonable ideas for addressing mining centralization?


+ The future of technology is uncertain, so we should not build rules that assume technological growth.

I think this one will have to be "we agree to disagree." I think the benefits of a clear road-map into the future outweigh the risks that things might go off the rails if the future is different from what most people expect, but I understand if you disagree.



Also: if any of you have suggestions for a better process for deciding what to do, I'd love to hear it. I don't want one person to be The Decider, but I also don't want one person to be The Blocker.

--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/


----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Tue, Feb 10, 2015 at 1:07 PM
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Wladimir van der Laan <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>, Pieter Wuille <pieter.wuille@gmail.com>


I'll be mostly out for the next couple of days (DevCore Boston, then Patrick and I are meeting with a bunch of people in NYC).

But I still want to try to reach consensus on the maximum block size issue, and I'm going to keep pushing the issue publicly and privately. I think it is a HUGE mistake to do anything that might dampen adoption at this stage in Bitcoin's life.

Reading back through all the discussion, I really think Pieter and Gregory are being much too conservative, but getting back to Jeff's comments: how can we agree on whether the potential risks outweigh the potential benefits?

And how can we mitigate the risks?

Or, if we cannot agree, what then?

E.g. the argument "An order of magnitude increase always brings up issues" :  Bitcoin has already gone through three orders of magnitude jumps (1KB blocks to 10KB blocks to 100KB blocks; we're about to hit the fourth, 100K to 1MB).

I'd say we had one unforseen issue in those three jumps-- the accidental fork. And I argue that we have a much better testing infrastructure in place now to avoid that kind mistake in the future, in addition to a lot better understanding of the technical issues (thanks mainly to lots of hard work and thinking by you-all).


--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/


----------
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, Feb 11, 2015 at 10:07 PM
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Cc: Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>

Anyway, let's be constructive. Here is what I propose:
* Implement infrastructure to monitor the propagation speed of blocks
on the actual network.
* Do simulations with many-node networks to estimate the effect of
larger blocks on the network (forking rate). We can probably work
together with the Chaincode Labs people (who have been asking us for
interesting work they can do), or people from Aviv Zohar's research
group, who seems interesting in this.
* Once we have numbers, suggest an immediate increase to 2 megabyte,
with esimtated effect on forking rate, centralization incentives, etc,
6 months or 1 year in the future, with the explicit plan to increase
further, based on the observed effects afterwards.
* Once the actual block size has actually increased, see what effect
it has had on the network (or whether other, unforeseen problems have
appeared), and then iterate, perhaps with some future growth formula
built-in.

Please.

--
Pieter

----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Thu, Feb 12, 2015 at 8:36 AM
To: Pieter Wuille <pieter.wuille@gmail.com>


Thanks Pieter, that's extremely helpful and productive. I'll respond more fully this weekend or next week when I'm back home, but assuming Greg and Jeff and Wladimir agree it feels like we can come up with a plan that we can all live with.

(at least on the technical concerns side; the economic stuff and the issue of one or multiple hard-forks are harder and might require public disagreement and discussion to resolve) (unless you're willing to step up and be the point person for getting consensus on what you think is right, in which case it'd be a lot less stress for me to step back and take a "I agree with whatever Pieter says, as long as the result increases the max size reasonably soon.")

--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/


----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Wed, Feb 18, 2015 at 10:57 AM
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>


On Wed, Feb 11, 2015 at 10:07 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
Anyway, let's be constructive. Here is what I propose:
* Implement infrastructure to monitor the propagation speed of blocks
on the actual network.

Done:

https://getaddr.bitnodes.io/dashboard/
http://bitcoinstats.com/network/propagation/

Looks like propagation for current blocks to 50% of the network is about 4-5 seconds.

* Do simulations with many-node networks to estimate the effect of
larger blocks on the network (forking rate). We can probably work
together with the Chaincode Labs people (who have been asking us for
interesting work they can do), or people from Aviv Zohar's research
group, who seems interesting in this.

A higher forking rate isn't, by itself, an issue because it affects all miners equally-- unless it gets close to the block interval time, in which case consensus breaks down.

And it seems to me it is a self-correcting problem: if a bigger block propagates slower and has increased forking risk then there is a built-in incentive for miners to produce smaller blocks.

Is the current 4-5 seconds-to-propagate-to-50% fast enough? Blocks are about 1/3 full right now, so that implies 12-15 seconds for 1MB blocks to propagate.

I'm happy to work on optimizing propagation, but I don't want to end up spending two months getting 8MB IBLT-ified blocks propagating in eleven seconds only to have the goalposts moved to "great, but we REALLY need sub-5-second propagation...."

* Once we have numbers, suggest an immediate increase to 2 megabyte,
with esimtated effect on forking rate, centralization incentives, etc,
6 months or 1 year in the future, with the explicit plan to increase
further, based on the observed effects afterwards.
* Once the actual block size has actually increased, see what effect
it has had on the network (or whether other, unforeseen problems have
appeared), and then iterate, perhaps with some future growth formula
built-in.


Are you willing to do the heavy lifting of selling that and getting consensus that multiple hardforks is the right approach?

I would much rather one hard fork, and then soft-fork a lower limit if it technology doesn't evolve as predicted.


--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/


----------
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Sun, Feb 22, 2015 at 5:31 AM
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Cc: Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>

----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Mon, Feb 23, 2015 at 12:03 PM
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>


RE: block propagation and economics:


I'm worried all the simulation and testing in the world still won't let us reach consensus on how to proceed.



----------
From: Gavin Andresen <gavin@bitcoinfoundation.org>
Date: Thu, May 7, 2015 at 2:31 PM
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>, Jeff Garzik <jgarzik@bitpay.com>


I think this email thread was a pretty good discussion; would you all be OK with making it public?

I also still kinda like the proposal in the last message...

----------
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Thu, May 7, 2015 at 2:38 PM
To: Gavin Andresen <gavin@bitcoinfoundation.org>
Cc: Pieter Wuille <pieter.wuille@gmail.com>, Gregory Maxwell <gmaxwell@gmail.com>, Wladimir van der Laan <laanwj@gmail.com>


You're welcome to publish mine (don't forget to snip quoted material
not authored by me)