ZHVyRpJQ

1Gavin Andresen <gavin@bitcoinfoundation.org> 2/4/15
2to Jeff, Pieter, Gregory, Wladimir 
3
4I've been thinking about why I get so worked up over the block size issue, and I believe I've figured it out.
5
6I think we're failing on the most fundamental value proposition for Bitcoin: predictability.
7
8We 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.
9
10If 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.
11
12I 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.
13
14Do 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.
15
16I 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.
17
18If 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.
19
20But 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.
21
22-- 
23--
24Gavin Andresen
25----------------------------------------------------------------------------------------------------
26Jeff Garzik <jgarzik@bitpay.com> 2/4/15
27to Gavin, Pieter, Gregory, Wladimir 
28
29Some quick thoughts, in random, disconnected order:
30
311) 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?
32
332) 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?
34
353) 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.
36
374) 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?
38
395) 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.
40
416) 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.
42
43-- 
44Jeff Garzik
45Bitcoin core developer and open source evangelist
46BitPay, Inc.      https://bitpay.com/
47----------------------------------------------------------------------------------------------------
48Gregory Maxwell <gmaxwell@gmail.com> 2/4/15
49to Gavin, Jeff, Pieter, Wladimir 
50
51As an aside,
52
53At FC15 Rainer Böhme  kind of bluntly (german style I guess) hit me
54with a 'you're stupid if you think you can just increase the block
55size with no effect, there is no incentive basis for that working out
56well' and cited
57http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400519 to me...
58which makes a more formalized argument for the fee/security
59equilibrium argument.  :)
60
61I need to give Gavin's message some more thought. One thing would be
62helpful is some thoughts on where "somewhere else" would be?  Is there
63any wellspring of innovation that has a more consistent and coherent
64scaling story than we have in Bitcoin?  Whats their answers the the
65multitude of concerns around the tradeoffs in this space?
66
67I think we made an error before in backing off the default block size
68limit too early. But while it did exist we absolutely did see
69soft-full blocks then, which suggests that Jeff's (3) may not be the
70case; though its hard to tell.  We've also seen continued increases in
71things where people are stuffing non-transaction data like messaging
72into the Blockchain with the increase.
73
74Message size limit isn't a limit, since you can carry the network over
75other protocols.
76
77----------------------------------------------------------------------------------------------------
78Jeff Garzik <jgarzik@bitpay.com> 2/4/15
79to Gregory, Gavin, Pieter, Wladimir
80 
81Second Rainer:  There absolutely will be economic turmoil & consequences to changing the 1MB limit.  I sorta thought this was self-evident :)
82
83It 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.
84
85This must be stated up front as a cost; hopefully it is a one-time cost.
86
87Any decision has costs and benefits.  The benefits need to outweight the costs.  Leads back to existential comment #1/#3 in prev email... 
88----------------------------------------------------------------------------------------------------
89Gavin Andresen <gavin@bitcoinfoundation.org> 2/4/15
90to Jeff, Gregory, Pieter, Wladimir 
91
92RE: 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).
93
94We also have no idea how much hashing is "enough to secure the network, but not too much."
95
96Am I alone in believing that predictability is better than One True Optimal Solution?
97
98I'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.
99
100Greg, you said "go to 2MB when we need to."  Can you be more explicit about how we tell "when we need to" ?
101
102Jeff, Pieter, Wladimir:  opinions?
103----------------------------------------------------------------------------------------------------
104Wladimir <laanwj@gmail.com> 2/5/15
105to Gavin, Jeff, Pieter, Gregory 
106
107On Wed, 4 Feb 2015, Gavin Andresen wrote:
108> 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.
109
110I agree. I certainly agree scaling is something that needs attention.
111
112I 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.
113
114Unlike 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.
115
116> 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.
117
118Well, 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.
119
120Being 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.
121
122Even 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.
123(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'.)
124
125> 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.
126
127I would prefer a method of scaling that involves off-chain transactions, or other forms of decentralization.
128
129Broadcasting 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.
130
131... 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.
132
133> 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.
134
135Easier, certainly. Safer, I don't know. This is an extremely difficult matter either way.
136
137Wladimir
138----------------------------------------------------------------------------------------------------
139Gavin Andresen <gavin@bitcoinfoundation.org> 2/5/15
140to Wladimir, Jeff, Pieter, Gregory 
141
142On Thu, Feb 5, 2015 at 4:55 AM, Wladimir <laanwj@gmail.com> wrote:
143> 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.
144
145Let me try to understand-- what part of the increase-the-blocksize-to-handle-all-the-world's-transactions scalability roadmap do you disagree with?
146
147Do 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)
148
149Or 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.
150
151I 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.
152
153
154RE: 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).
155
156I'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).
157
158And I'm fairly certain big miners will agree; after all, it give them more choice, not less.
159----------------------------------------------------------------------------------------------------
160Gregory Maxwell <gmaxwell@gmail.com> 2/5/15
161to Gavin, Wladimir, Jeff, Pieter 
162
163DeathAndTaxes argues that 200+ Mbyte blocks are needed, even
164completely ignoring retail traffic:
165https://bitcointalk.org/index.ph?topic=946236.0
166
167Predictability is great, but I think you're painting a false
168comparison: Ineffectively large limits trade one kind of
169predictability for another.  When the block size limit matters there
170is less predictability about when a transaction you just created will
171get confirmed (how much less we don't know as we've never had a fee
172market and fee estimation actively deployed), when blocksizes are not
173(effectively) limited the viability of the network in the long term is
174less predictable. I could just as well say "Why do you hate freedom?"
175for all the clarity that provides.  Transaction confirmation is
176inherently somewhat unpredictable just due to block creation being a
177poisson process, so my intuition is to not put _that_ much weight on
178small timescale unpredictability because anything that really needs it
179will need another transaction confirmation mechanism already.  On
180longer timescales one can get greater predictability by replacing
181transactions with higher fees, if their transactions turn out to not
182be competitively priced considering their delay tolerance.
183
184> We also have no idea how much hashing is "enough to secure the network, but not too much."
185
186Well you certainly can draw lines around costs of attacks vs rewards
187and have something better than "no idea".  As a not totally reasonable
188approximation as older hardware goes dark, assume you can buy
189hashpower on the open market for energy prices, and assume you can
190make N-confirm trades where if you don't successfully cheat your
191expected return on the trade is nearly 100% (say 99.9%), but if you're
192successful you gain 200%, you'll attack if the cost of attacking is
193lower than your returns, ... the hard part in this kind of analysis is
194figuring out how much you can attack at once.  Getting +100% on a
195single 0.1 BTC trade probably doesn't make it interesting, but making
196100 simultaneous 50BTC attacks is much more interesting.  If you
197assume all transactions in blocks are attacks, you can draw a direct
198cap on the amount of 'value' that could be transacted before an attack
199is profitable. (Turns out to be frighteningly low, at least last time
200I tried running that number.)
201
202I don't think "too much" POW security is actually a concern, rather we
203want enough security for the highest security uses and then a bit more
204since the cost of failure may be we lose access to this kind of system
205going forward. And we don't want transaction fees to be so costly as
206to exclude applications. But these are somewhat at odds, there are
207"applications" where virtually any fee is too much. Fortunately those
208applications don't need much security, but unfortunately what we have
209is one size fits all.  A bitcoin that scales enough for tiny
210micropayments may well not be secure enough to act as a store of
211value. These may actually be mutually exclusive right now.
212
213> Greg, you said "go to 2MB when we need to."  Can you be more explicit about how we tell "when we need to" ?
214
215I think we screwed up in exposing (and later encouraging) people to
216raise the soft limit, because doing so made it impossible to learn
217anything about the backlog under load. Hindsight is 20/10. What we
218should have done is left it at 500k, and when there were persistent
219backlogs increased the soft target to keep a clearance backlog of
22012-24 hours (which is not out of line with ACH clearing), while
221scheduling a hard limit increase to 2MB (assuming hosts could keep up
222with it). One metric would be variance in block size over 24 hours
223(and over the week). If we're actually full across the whole day it
224means we're really using the capacity and at least at peak people with
225time preferences for fast confirmation can express their preference
226with fees. By playing out the size conservatively with need, we have
227more touches (which stinks) but at the same time reduces the concerns
228of slipping into bad outcomes if the limits are unhinged.
229
230I do agree that we'll see continued progress in technology, sure, but
231the exponent is very uncertain and the distribution inequal. I live in
232Mountain View CA, home of Google. There are basically only two
233broadband options here, both are substantially slower than the
234connectivity I had at home a decade ago. Matt in SF has 500MBit/sec;
235which actually would have been what you would have expected from a
236double every two years from what I had a decade ago, but thats very
237rare.   Get the exponent slightly wrong and the result isn't just 10%
238too big, it's many multiplies too big.
239
240I'm unlikely to ever support any automatic "grows forever" (or even
241'grows to a size we can't clearly support with state of the art
242hardware today") proposal; as we can't even build and test software
243that is guaranteed to work in that environment (talk about
244non-predictability).  We've more or less completely failed at avoiding
245massive mining centralization and though its completely apparently
246broken now we're doing very little to improve it, I've seen no
247argument as to how a node-load induced total loss of decentralization
248or a loss-of-security-from-inadequate-fees would play out any
249differently.
250
251If indeed "70 billion transactions per day" becomes viable (in all
252respects, including incentives and decentralization) 20 years from
253now, it should be uncontroversial to increase the limits to accept
254that.  Jumping into the unknown is never going to be uncontroversial.
255I feel like you're asking me to conceal my concerns from the public in
256the name of harmony. I'm not going to do that, though if the public
257attacks continue I may well just bow out from Bitcoin entirely-- This
258subject is really stressful for me, and with the personal attacks I've
259received its adversely impacting my health... even now where I've been
260intentionally pretty quiet about the subject.
261
262I'd asked what you thought were were competing against here where
263people will turn to, most cryptocurrency systems also have limits...
264Iwent looking around some; Ethereum's latest claims (they change
265daily) seem to be that they're implementing the fraud proof stuff that
266had been talked about in the past in bitcoin-space so even if people
267can't run full nodes the properties of the system would be completely
268lost, plus using a moving average... and even there they say that it's
269unsolved, unclear, and needs future work.  I think ethereum's
270technical work is largely the work of madmen ( :) ), and even they
271think this is not simple or easy, even given that they're planning on
272deploying technology which arguably make the issues less severe (fraud
273proofs, and a rolling limit).
274----------------------------------------------------------------------------------------------------
275Gavin Andresen <gavin@bitcoinfoundation.org> 2/5/15
276to Gregory, Wladimir, Jeff, Pieter 
277
278RE: your bandwidth in Mountain View sucking:
279
280Okey 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."
281
282
283On Thu, Feb 5, 2015 at 2:43 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
284> I'm unlikely to ever support any automatic "grows forever" (or even
285> 'grows to a size we can't clearly support with state of the art
286> hardware today") proposal; as we can't even build and test software
287> that is guaranteed to work in that environment (talk about
288> non-predictability).
289
290I 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.
291
292All of my calculations assume zero improvements to the software, just network/bandwidth/CPU/storage growth.
293 
294>  We've more or less completely failed at avoiding
295> massive mining centralization and though its completely apparently
296> broken now we're doing very little to improve it, I've seen no
297> argument as to how a node-load induced total loss of decentralization
298> or a loss-of-security-from-inadequate-fees would play out any
299> differently.
300
301I think you're being short-sighted, and mining centralization will ebb and flow for years as technology changes.
302
303My 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".
304
305
306RE: 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."
307
308 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".
309----------------------------------------------------------------------------------------------------
310Pieter Wuille <pieter.wuille@gmail.com> 2/5/15
311to Gavin, Jeff, Gregory, Wladimir 
312
313On Wed, Feb 4, 2015 at 8:09 AM, Gavin Andresen
314<gavin@bitcoinfoundation.org> wrote:
315> I've been thinking about why I get so worked up over the block size issue,
316> and I believe I've figured it out.
317>
318> I think we're failing on the most fundamental value proposition for Bitcoin:
319> predictability.
320
321> I think we are hurting adoption by not having consensus on a clear,
322> predictable plan for how the network will scale up to handle increasing
323> transaction volume.
324
325I think the fundamental difference in view is that you see a growing
326adoption of "bitcoin transactions on the blockchain", and that the
327blockchain should grow to accommodate that. On the other hand, I
328believe the scalability of the blockchain will grow as a result of
329technological improvements, and that adoption of bitcoin transactions
330on the blockchain will grow to match the available scalability.
331
332If people have a prediction that Bitcoin will scale to any transaction
333rate, then there is little we can do but pointing out that that's a
334dream. 20 megabyte blocks can do more than 1 megabyte blocks, but they
335can't handle every transaction on the planet. It's not even enough to
336handle the current monetary transactions done in bitcoin-the-currency
337(think exchange trades, changetip, ...). People have forever built
338off-chain systems, and that's both inevitable and fine. What the
339blockchain offers is a new (and constant) level of trustlessness for
340monetary transactions, at a cost. That trustlessness and cost are not
341wanted for everything, and that's fine. Bitcoin the ecosystem is not
342just the blockchain.
343
344Again, I am in favor of increasing the block size, but I don't think a
345"OMG we're reaching the limit!" panic reaction is a good reason for
346doing so. I think people also have a prediction that we don't take
347rushed decisions that could undermine the system.
348
349Things I'm specifically worried about:
350
351* Ability for validation. Larger blocks will mean higher bandwidth,
352higher CPU cost, faster growth of fast memory for the UTXO set, faster
353growth of disk space usage. I'm glad you did benchmarks to know the
354numbers for short-term effects of a block size increase for most of
355these, but the practice is still that the number of full nodes is
356dropping due to much less theoretical issues. Perhaps pruning will
357improve things, but we don't know. Just saying that a solution exists
358is not the same as having it deployed.
359I'd like to add here that I don't believe in any "But how many full
360nodes is enough?" answer. I don't care about the number of full nodes.
361I care about the very practical ability people have to validate that
362nobody is violating any rules. With increasing usage, I would expect
363to see an increasing number of nodes - but it's not.
364It's the same as why we don't have laws "There can be at most 5 deaths
365per year on this highway due to traffic accidents", but have speed
366limits instead.
367
368* Miner centralization incentives. I'm baffled that you don't seem to
369care about this. I would like to stress that this is not directly
370about security. I'm not particularly worried that miners will decide
371to collude and do some very directly selfish move that ultimately
372destroys confidence in the system in the medium term. I'm worried
373about subtle but increasingly strong tendency for centralization that
374makes the system increasingly less interesting (making miners subject
375to regulation, for example). If you let miners choose their block
376sizes, then - without any selfish or malicious intent -
377better-connected miners can notice that they can create larger blocks
378than others (because their blocks still propagate sufficiently fast to
379a majority of the effective hashrate). Propagation delay increasing
380means a larger advantage for larger and better-connected miners. As
381far as I know, GHOST does not even claim to fix this. I believe full
382nodes should have the responsibility to limit the benefit larger
383miners can have over smaller miners. The way to do that is by them
384requiring a block size to be at a level where smaller miners are able
385to operate.
386
387* Political danger. If we (or you) are able to pull off a
388controversial hard fork, and get people to go along with it, it's
389evidence that we have power we shouldn't have; power which people may
390demand that we use again later. I think our role should be advisory as
391to what the technology can support, and only act when there is no
392controversy. I'll gladly argue that people should support a block size
393increase I consider technically reasonable (see further), but against
394anything that seems controversial (even if the change itself seems
395technically reasonable to me). At a totally different level than
396usual, the "consistency is more important than correctness" argument
397applies.
398
399Things I consider technically bad ideas:
400
401* An order-of-magnitude jump. I very much agree with Zooko's argument
402that every order of magnitude scaling exposes problems that were not
403visible before. Scaling gradually gives time to make problems appear
404before they're critical, and push back until they're solved.
405
406* Unbounded growth. We should grow proportionally with (the bottleneck
407of) growing technologies we rely on, but I don't think we have any
408clue about scaling factors of storage/computation/bandwidth over a 20
409year scale. If that means more hardforks to accommodate, so be it.
410
411* A miner vote. This is a hard forking change, and a very large
412majority of nodes will need to choose to adopt it. To them, only
413miners creating blocks that satisfy the new rules matter anymore
414(they'll ignore others), so votes from old miners are utterly
415irrelevant. Just set a flag date, and make people upgrade by that
416time. If we're not sure that everyone with economic importance will
417have upgraded by that time, we shouldn't be doing it.
418
419* Proposing a specific change before having simulated the behaviour of
420the network as a whole. As I've told you in private, I understand this
421may feel as a "Now they're again coming up with new requirements!",
422but I find it frightening to see a push for a change without even
423knowing how for example propagation is affected. We still have silly
424sleeps in the networking code, and the pull requests to fix those
425before 0.10 received too little attention to merge. I don't think we
426should be aiming for huge increases without doing the effort of fixing
427known small problems.
428
429I've said this before, but in my view, the block size sets a balance
430between scalability and verifiability. A system with marginal
431transaction rate but validatable with 30-years old hardware is useless
432- as inter-bank transfer systems can work fine without trustlessness
433(they can just sue each other if they don't play by the rules). But a
434system with huge transaction rate and very limited ability to validate
435isn't useful either - PayPal works fine for that and at much lower
436cost too. What we need is a particular balance between those, and the
437block size limit sets that balance. I don't know what that balance
438should be, but I also very strongly disagree with leaving the decision
439up to miners.
440
441Thanks for reading this.
442----------------------------------------------------------------------------------------------------
443Gavin Andresen <gavin@bitcoinfoundation.org> 2/5/15
444to Pieter, Jeff, Gregory, Wladimir 
445
446Thanks, Pieter.
447
448So, what kind of size increase WOULD you support right now?
449
450How about:
451
452Start 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).
453
454
455RE: letting miners decide:
456
457OK, 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.
458
459
460Detailed response to your concerns:
461
462RE: rushed decisions:
463
464Yes, 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.
465
466RE: ability for validation:
467
468I 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.
469
470RE: miner centralization incentives:
471
472Is 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" ?
473
474Before 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.
475
476RE: political danger:
477
478Maybe 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...
479
480RE: simulating the entire network:
481
482Great, lets simulate the entire network with 20MB blocks.  I don't know how to do that, can you help out with that?
483----------------------------------------------------------------------------------------------------
484Gregory Maxwell <gmaxwell@gmail.com> 2/5/15
485to Gavin, Wladimir, Jeff, Pieter 
486
487On Thu, Feb 5, 2015 at 9:58 PM, Gavin Andresen
488<gavin@bitcoinfoundation.org> wrote:
489
490> On Thu, Feb 5, 2015 at 2:43 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
491>>
492>> I'm unlikely to ever support any automatic "grows forever" (or even
493>> 'grows to a size we can't clearly support with state of the art
494>> hardware today") proposal; as we can't even build and test software
495>> that is guaranteed to work in that environment (talk about
496>> non-predictability).
497>
498>
499> I really, really don't understand this attitude-- I woulda thunk you were
500> old enough to be confident that technology DOES improve. In fits and starts,
501> but over the long term it definitely gets better.
502
503I'm confident that technology will improve. But it can improve nicely
504but still be _utterly_ blown away by any particular pre-perscribed
505growth formula (especially an exponential one). If the limit is some
506multiple of what nodes can comfortably handle or real demand on the
507network then its more or less equivalent to unlimited; so it doesn't
508even have to be off by much.  I'm also experienced enough with large
509scale systems to know that massive increases in scale expose new
510behaviors and effects that were not visible in other regimes.  So, for
511example in 1990 one might have correctly predicted the grown in raw
512ALU throughput we've seen, but if you also assumed memory bandwidth
513would have kept up you would be massively misplaced (factor of 100x+
514off by now), and many problems become more memory bandwidth limited as
515they scale.
516
517This is especially a factor when you're talking about improvement of
518the, say, 10th percentile rather than the best available technology--
519which is very much a consideration.
520
521There are also serious confounding trends. Computers are getting
522better but more computing is moving onto battery powered tablet
523devices which move backwards a decade in technology and on to cloud
524hosted infrastructure which adds little decentralization in to
525ecosystem. Sometimes the improvement in technology is rolled into
526power, space, and cost savings and doesn't become readily available in
527the forum of throughput. Sometimes the improvements show up in
528specialized processors which may not be useful to us (e.g. most of the
529multiply throughput and memory bandwidth in a high end desktop is in
530the GPU right now). It wouldn't be an unreasonable guess that
531computing power available at low cost to the general public may
532increase slower even if raw technology improvement speeds up because
533the improvements are going into other areas, esp. if applications
534which need massive increases in local computing power don't
535materialize.
536
537> All of my calculations assume zero improvements to the software, just network/bandwidth/CPU/storage growth.
538
539The existing p2p protocol can't handle messages over 32MB; so that
540isn't the case-- we don't even need to debate this. You're also not
541measuring more than a small part of the effect in increasing the
542blocksize. Go try running the network with propagation delays 20x what
543we have now: it really doesn't work, the orphan rate would be huge. So
544if you're actually telling me that these numbers already work with
545current software/network designs I'm quite confident to say that _they
546do not_. Sure, I think much of this can be improved with software
547(which is why I've not loudly protested that it cannot work)... If I
548use your claims here as a gauge of how much we don't know yet, it's
549suggestive that there may be other effects that none of us know about.
550
551> I think you're being short-sighted, and mining centralization will ebb and flow for years as technology changes.
552
553The progression towards centralization has been pretty much monotonic.
554You've professed ignorance of the mining ecosystem before, I don't
555think thats serving you well here. It's really not in a healthy state
556now, and I'm not aware of anything that is happening to improve it.
557(quite the other way, as there are trade-secret (and maybe patent
558pending) optimizations which make the kind of massive improvements
559they were speculated to bring.). We're also seeing some of the few
560hardware companies that sold to the company going out of business.
561
562> RE: stress:   Is it just the politics, or do you imagine some major technical disaster?
563
564It's both but on the latter I am less worried about "technical
565disaster" than a slow slide into something more or less completely
566centralized or completely insecure (necessitating a fix that
567completely centralizes it, like stellar had recently). If it's a
568straight up disaster causing explicit pain for everyone thats often
569easier to deal with, because its clear that something must be done,
570likely clear what that something is, and if that something has costs
571(like making some kinds of established transactions non-viable) it
572would be reasonable to build support around.   When the pain is not
573acute it's easier to just ignore or hope it will "ebb and flow" itself
574into a better state later(somehow).
575----------------------------------------------------------------------------------------------------
576Gavin Andresen <gavin@bitcoinfoundation.org> 2/6/15
577to Gregory, Wladimir, Jeff, Pieter 
578
579Ok, I'm hearing:
580
581+ You're concerned about propagation delays.
582
583If I can demonstrate running code that has propagation delays less than eleven seconds per hop for (say) 200MB blocks, would that address that concern?
584
585The 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).
586
587+ 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.
588
589
590+ You're concerned about mining centralization, and that larger blocks might make that problem worse.
591
592I'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.
593
594If the propagation issue is addressed, would you agree that mining centralization is an orthogonal issue, or is there something else I'm missing?
595
596PS: ARE there any reasonable ideas for addressing mining centralization?
597
598
599+ The future of technology is uncertain, so we should not build rules that assume technological growth.
600
601I 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.
602
603
604
605Also: 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. 
606----------------------------------------------------------------------------------------------------
607Gavin Andresen <gavin@bitcoinfoundation.org> 2/10/15
608to Gregory, Wladimir, Jeff, Pieter 
609
610I'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).
611
612But 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.
613
614Reading 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?
615
616And how can we mitigate the risks?
617
618Or, if we cannot agree, what then?
619
620E.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).
621
622I'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).
623----------------------------------------------------------------------------------------------------Pieter Wuille <pieter.wuille@gmail.com> 2/11/15
624to Gavin, Gregory, Wladimir, Jeff 
625
626On Tue, Feb 10, 2015 at 10:07 AM, Gavin Andresen
627<gavin@bitcoinfoundation.org> wrote:
628> But I still want to try to reach consensus on the maximum block size issue,
629> and I'm going to keep pushing the issue publicly and privately. I think it
630> is a HUGE mistake to do anything that might dampen adoption at this stage in
631> Bitcoin's life.
632
633I think it's a huge mistake to:
6341) Push for a hard fork for something that's clearly controversial,
635could divide the community, or could make us look like dictators of
636the network's rules.
6372) Make a change that modifies (and keeps modifying) the network's
638incentives in unknown (and unbenchmarked) ways.
6393) Make changes that assume a particular growth curve for technology
640in the next 10-20 years.
641
642Dampening adoption is already happening and inevitable. There is no
643way we can support all transactions that would be on-chain if they
644were unlimited and zero cost. Changetip would be crazy if they'd do
645all tips on-chain, even with 20 MB blocks.
646
647I do agree that it's important to work on this, and show that we're
648working on this. At least I (but I doubt I'm alone) have been quiet
649about this topic to avoid looking divided or because of general
650aversion to political debate; maybe we should change that, and start
651talking about more various proposals to improve scalability of several
652bottlenecks in public.
653
654> Reading back through all the discussion, I really think Pieter and Gregory
655> are being much too conservative, but getting back to Jeff's comments: how
656> can we agree on whether the potential risks outweigh the potential benefits?
657>
658> And how can we mitigate the risks?
659
660Why are we even discussing this before having benchmarked or simulated
661the most important effect on the network (the propagation time)?
662Worse, we hardly have good information about the actual network's
663propagation time effects, apart from an academic paper which was based
664on numbers from 0.7. I don't like this "We must increase the size a
665lot; what needs to happen?". I want to see numbers, talk publicly
666about the tradeoffs that have to be made when the limits increase, and
667then see whether a consensus can be found.
668
669There are suggested proposals that improve propagation time, but none
670are implemented and deployed, and none improve some of our fundamental
671bottlenecks. Numbers that I know of:
672* Patrick Strateman benchmarked the fastest just-process-a-block
673bandwidth of Bitcoin Core master on recent hardware (xeon, 80 GB ram,
674ssd storage) at 51 megabit per second. That's without signature
675checking, and would mean every single hop over the network of a 20
676megabyte block already takes 3.3 seconds, as an absolute baseline.
677* Signature checking, with the best libsecp256k1 numbers currently
678(which require 2 patented techniques, and a dependency on GMP) could
679do a signature check in around 40-50 microseconds, or an additional
6802s, if fully parallellized on a quad-core 3.5 GHz i7 machine (which
681may potentially be avoided for pre-checked mempool transactions).
682* Your own IBLT proposal to improve bandwidth usage has superlinear
683cpu consts for reconstructing blocks on the receiver size (with the
684current code, extrapolated linearly from current block sizes, you may
685have better numbers) taking 5s to construct a 20-megabyte block.
686* Some silly sleeps in the networking code adding a few times 0.1s
687before relaying a block.
688
689Seems to me that even assuming infinite bandwidth, zero latency, very
690recent hardware, and not-yet-implemented software improvements, we're
691talking about network propagation times close to a minute, which means
692a 10% bonus for better-connected miners. I consider that high, but
693even if there are no unforeseen software or security or fee incentive
694or full node running incentive problems, the question is whether the
695Bitcoin community should accept the centralization tradeoff that this
696implies. It's not a boolean "secure or not"; it's a compromise between
697scalability and decentralization (of miners and of full nodes). It's a
698compromise we as a community need to make consciously.
699
700I want to stress again that this is not to prevent an evil cabal of
701miners to outright attack the network. This is about subtle incentives
702that may cause honest, profit-optimizing, larger miners to push away
703smaller pools to a point where they can't compete. If we think they
704wouldn't do that anyway because of risk to the network, there is also
705no reason why we should allow them to do so.
706
707> Or, if we cannot agree, what then?
708
709If we already can't agree, how do you expect the entire community to
710agree? We're not just talking about a majority of miners.
711
712> E.g. the argument "An order of magnitude increase always brings up issues" :
713> Bitcoin has already gone through three orders of magnitude jumps (1KB blocks
714> to 10KB blocks to 100KB blocks; we're about to hit the fourth, 100K to 1MB).
715>
716> I'd say we had one unforseen issue in those three jumps-- the accidental
717> fork. And I argue that we have a much better testing infrastructure in place
718> now to avoid that kind mistake in the future, in addition to a lot better
719> understanding of the technical issues (thanks mainly to lots of hard work
720> and thinking by you-all).
721
722This is not only about testing. There are economic incentives involved
723we can't predict. There are people saying there are no problems, based
724on extrapolations from numbers of the current economic landscape. We
725don't know how the landscape will evolve, however.
726
727I really, really, want to stress that I'm not against increasing the
728block size. The Bitcoin network needs to scale as technical
729bottlenecks improve. But the current approach and discussion around it
730makes me sick. I don't want to set what requirements you need to
731fullfill before I agree about increasing it. I want you to understand
732and consider and be honest about the issues that are brought up, and
733not wipe them off the table with "I did some numbers and it looks ok,
734but this needs to happen now".
735
736Anyway, let's be constructive. Here is what I propose:
737* Implement infrastructure to monitor the propagation speed of blocks
738on the actual network.
739* Do simulations with many-node networks to estimate the effect of
740larger blocks on the network (forking rate). We can probably work
741together with the Chaincode Labs people (who have been asking us for
742interesting work they can do), or people from Aviv Zohar's research
743group, who seems interesting in this.
744* Once we have numbers, suggest an immediate increase to 2 megabyte,
745with esimtated effect on forking rate, centralization incentives, etc,
7466 months or 1 year in the future, with the explicit plan to increase
747further, based on the observed effects afterwards.
748* Once the actual block size has actually increased, see what effect
749it has had on the network (or whether other, unforeseen problems have
750appeared), and then iterate, perhaps with some future growth formula
751built-in.
752
753Please.
754----------------------------------------------------------------------------------------------------
755Gavin Andresen <gavin@bitcoinfoundation.org> 2/18/15
756to Pieter, Gregory, Wladimir, Jeff 
757
758On Wed, Feb 11, 2015 at 10:07 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
759> Anyway, let's be constructive. Here is what I propose:
760> * Implement infrastructure to monitor the propagation speed of blocks
761>  on the actual network.
762
763Done:
764
765https://getaddr.bitnodes.io/dashboard/
766http://bitcoinstats.com/network/propagation/
767
768Looks like propagation for current blocks to 50% of the network is about 4-5 seconds.
769 
770> * Do simulations with many-node networks to estimate the effect of
771> larger blocks on the network (forking rate). We can probably work
772> together with the Chaincode Labs people (who have been asking us for
773> interesting work they can do), or people from Aviv Zohar's research
774> group, who seems interesting in this.
775
776A 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.
777
778And 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.
779
780Is 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.
781
782I'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...."
783
784> * Once we have numbers, suggest an immediate increase to 2 megabyte,
785> with esimtated effect on forking rate, centralization incentives, etc,
786> 6 months or 1 year in the future, with the explicit plan to increase
787> further, based on the observed effects afterwards.
788> * Once the actual block size has actually increased, see what effect
789> it has had on the network (or whether other, unforeseen problems have
790> appeared), and then iterate, perhaps with some future growth formula
791> built-in.
792
793
794Are you willing to do the heavy lifting of selling that and getting consensus that multiple hardforks is the right approach?
795
796I would much rather one hard fork, and then soft-fork a lower limit if it technology doesn't evolve as predicted.
797----------------------------------------------------------------------------------------------------
798Pieter Wuille <pieter.wuille@gmail.com> 2/22/15
799to Gavin, Gregory, Wladimir, Jeff 
800
801On Wed, Feb 18, 2015 at 7:57 AM, Gavin Andresen
802<gavin@bitcoinfoundation.org> wrote:
803> Done:
804>
805> https://getaddr.bitnodes.io/dashboard/
806> http://bitcoinstats.com/network/propagation/
807>
808> Looks like propagation for current blocks to 50% of the network is about 4-5
809> seconds.
810
811Cool, that's good to know. Having this broken down by block size, and
812higher percentiles would be even more interesting to see.
813
814>> * Do simulations with many-node networks to estimate the effect of
815>> larger blocks on the network (forking rate). We can probably work
816>> together with the Chaincode Labs people (who have been asking us for
817>> interesting work they can do), or people from Aviv Zohar's research
818>> group, who seems interesting in this.
819>
820> A higher forking rate isn't, by itself, an issue because it affects all
821> miners equally-- unless it gets close to the block interval time, in which
822> case consensus breaks down.
823
824I think you misunderstood my argument. If propagation delays would
825affect all miners equally, there would not be a problem. The point is
826that larger and better-connected miners suffer less badly from
827propagation (a large miner does not suffer from propagation when
828building upon his own previous block; a weaker form of the same effect
829applies to miners that are geographically closer to a majority of
830other miners). The full-network propagation delay sets a limit on the
831advantage larger/more centralized miners have over smaller/more
832distributed ones, and it's in the ecosystem's best interest to limit
833that advantage.
834
835> And it seems to me it is a self-correcting problem: if a bigger block
836> propagates slower and has increased forking risk then there is a built-in
837> incentive for miners to produce smaller blocks.
838
839It's not. If you let miners choose their own block sizes (either
840because of no limit, or a limit beyond what they would rationally
841produce), larger and better-connected miners will be able to produce
842relatively larger blocks than others (with the same forking rate),
843giving them a competitive advantage. I'm not concerned about the
844network convergence breaking down due to slow propagation. I'm worried
845about incentivizing larger miners and clusters thereof. Centralization
846incentives already exist for miners now, but they are more due to
847reduction of variance and maintenance costs. Block propagation time
848differences result in an actual systemic income benefit on top of
849that. As hardware and deployment improvements slow down, I'm sure that
850this systemic difference will become an increasingly important factor
851in mining profitability.
852
853> Is the current 4-5 seconds-to-propagate-to-50% fast enough? Blocks are about
854> 1/3 full right now, so that implies 12-15 seconds for 1MB blocks to
855> propagate.
856
857Assuming an idealized Poisson-distributed 600s average-interval
858blocks, the forking rate in function of the average block propagation
859time should be:
860* 1.25s: 0.21%
861* 2.5s: 0.42%
862* 5s: 0.83%
863* 10s: 1.65%
864* 20s: 3.3%
865* 40s: 6.4%
866* 80s: 12%
867(it's slightly sublinear, but there may be worse effects that play a
868role when the propagation times get closer to the interval).
869
870I don't know enough about the economic incentives underlying the
871mining business, but anything above a few percent sounds pretty bad
872already.
873
874We also don't know how propagation time across single link and
875whole-network setups evolve as the block size gets larger. Most
876effects (validation, transmission time) are likely linear. Some are
877constant (latency and some network code effects). Some may be
878superlinear (the block reconstruction code in your IBLT proposal is, I
879believe). I believe we (not just us, but the community) should know
880these effects and be aware of their potential risks, through
881simulation and observation, before making a decision.
882
883> I'm happy to work on optimizing propagation, but I don't want to end up
884> spending two months getting 8MB IBLT-ified blocks propagating in eleven
885> seconds only to have the goalposts moved to "great, but we REALLY need
886> sub-5-second propagation...."
887
888I've been thinking about a simulator that predicts mining income given
889a network of nodes with various propagation properties, but we still
890really need actual numbers from the network w.r.t. how propagation
891evolves in function of block size. Making that propagation less
892dependent on actual block sizes would be awesome. Your IBLT proposal
893likely does that to some extent for the network transmission time, but
894trades it for higher per-transaction CPU costs on both sides, so I'm
895not convinced it really helps. Gregory's proposal is probably simpler
896to implement, and I expect it to have a stronger effect on reducing
897propagation time variance in practice. Numbers would be very welcome,
898of course.
899
900Also, I've been focussing this discussion mostly on propagation time,
901because I believe it's the part that is most likely to be overlooked,
902and requires the weakest "assumption of miner evilness", not because I
903think there are no other risks. In particular, things like long-term
904mining income, and incentives to run full nodes are very scary, but
905harder to analyse as well. The most important part IMHO is for us to
906be able to talk publicly about these, and their risks.
907
908> Are you willing to do the heavy lifting of selling that and getting
909> consensus that multiple hardforks is the right approach?
910
911If needed, I'll voice my opinion about it publicly, and say what
912things we have left to do, and how gradual experimentation is needed.
913You still have to convince me that all of this needs urgency. I'd like
914to see how the system behaves with blocks closer to the limit - both
915technically and economically - as I can't imagine any long-term future
916for Bitcoin without it (whatever the actual size is).
917
918> I would much rather one hard fork, and then soft-fork a lower limit if it
919> technology doesn't evolve as predicted.
920
921Please don't assume you'll be able to just ask miners in 15 years time
922to act against their own interests.
923----------------------------------------------------------------------------------------------------
924Gavin Andresen <gavin@bitcoinfoundation.org> 2/23/15
925to Pieter, Gregory, Wladimir, Jeff 
926
927RE: block propagation and economics:
928
929
930I'm worried all the simulation and testing in the world still won't let us reach consensus on how to proceed.
931
932
933Here's a partly-baked thought, it either makes things more complicated and hard to analyze or mitigates that "how can we protect small/poorly-connected miners from Big Miners Create Giant Block attacks:"
934
935New consensus rules:
936
9371) A limit based on average size of last N blocks + growth, with parameters set such that a minority of miners can always keep the average from rising so high they are significantly economically disadvantaged.
938
939  --> This should address the mining centralization concerns.
940  --> It should also mitigate problems that might crop up with sudden increases in the size
941  --> It should also address concerns that there should be "block size pressure" to keep transaction fees up
942  --> It is short-term predictable
943
944I hate introducing more magic constants, but I hate being stuck at 1MB blocks more... so imagine the rule is:
945
946max block size is average(sizeof last 32 blocks) + 1/32'nd sizeof last 32 blocks
947
94832 because I like powers of two, and it'll be slightly harder for people to screw up the math.
949
950average size and not median so that a minority of small miners can produce smaller blocks and limit the profits of bigger, better-connected miners.
951
952Increase of 1/32'nd because that lets 1/32'nd (3%) of hashing power "veto" any size increase by mining nothing but minimum-size blocks. If slightly more than 1/32'nd of hash power consistently produces minimum-sized blocks then the block size cannot rise, even if the other 97% of hash power is producing as-large-as-allowed blocks.
953
954And last 32 blocks because it seems like a reasonable compromise between needing to respond quickly to surges in transaction volume around major shopping days and wanting to make it impossible for a majority of miners to unilaterally impose their will on the rest of the network.
955
956If 100% of miners decided to produce blocks as large as possible, block size could double in about 4 hours. I think that is about the right order of magnitude if we assume transaction spikes like the 4x spikes seen by traditional online transactions on some days before Christmas (e.g. see http://adwords.blogspot.com/2014/10/online-retailers-secret-to-seasonal.html ).
957
958My economic intuition on why this would work to protect smaller / badly connected miners:
959
960I assume the transaction fee market will look like other markets-- there will be a small number of high-fee, high-value transactions that are very profitable for miners, then increasing numbers of low-value, low-fee transactions down to some threshold below which no full nodes bother to relay and no miners bother to mine.
961
962Small miners will take the most profitable transactions, and by producing smaller blocks limit the advantage bigger miners have over them-- the big miner can take some extra low-profit transactions, but not a gazillion low-profit transactions.
963
964We'd need a good model for the distribution of transaction fees to model this, but it seems to me the incentives are aligned correctly. And whenever contemplating detailed economic modelling I think of "the curious task of economics is to demonstrate to men how little they really know about what they imagine they can design".
965
966
9672) A 1MB "minimum maximum size" :  miners may always produce blocks up to 1MB big, no matter average size of last 32 blocks
968
969  --> Gotta have a bootstrapping rule, and need to prevent opening up a new form of 51% attack. There is still a mild attack here: "51% attacker mines 32 empty blocks, resets average size back to 1MB default, stop mining and it will take the network a day or two to recover and produce larger blocks." But a 51% attacker can already screw with the network by mining empty blocks.
970
9713) A high absolute upper limit to protect against "miners unite to produce really large blocks that only other miners can validate."
972
973  --> This would be the 8MB limit doubling every couple of years, so running a full node at home remains viable "forever".
974 
975
976---------------------
977
978An orthogonal thought:  I think we should move default mining policy for the reference implementation to be neutral with respect to block size. I think a target block size of average-size-of-last-32-blocks-plus-half-the-average-transaction-size would accomplish that-- basically, if miners didn't express a preference they would produce blocks the same size that everybody else is producing.
979
980Miners who bothered to express a preference for either larger or smaller blocks by overriding the default would influence all of the "don't care" or "can't be bothered to figure out the economic tradeoffs" miners.
981
982----------------------
983
984Pieter: I know you don't like the idea of miners having control, but I think you're making the mistake of thinking that miners are distinct from the rest of the ecosystem. If a merchant or exchange or individual or group wants to exert influence over the economics of the block size, they are free to do some mining and express their opinion via hashing larger or smaller blocks.
985
986I agree that we want to make sure we don't suffer a "tyranny of the majority."
987----------------------------------------------------------------------------------------------------
988Gavin Andresen <gavin@bitcoinfoundation.org> 5/7/15
989to Pieter, Gregory, Wladimir, Jeff 
990
991I think this email thread was a pretty good discussion; would you all be OK with making it public?
992
993I also still kinda like the proposal in the last message...
994----------------------------------------------------------------------------------------------------
995Jeff Garzik <jgarzik@bitpay.com> 5/7/15
996to Gavin, Pieter, Gregory, Wladimir 
997
998You're welcome to publish mine (don't forget to snip quoted material
999not authored by me)
1000----------------------------------------------------------------------------------------------------