- (a) I once posted a patch to change max block size, so I thought about this long before forum readers ever woke up to the issue,
- (b) I have since backed down from that radical position,
- (c) it seems likely that max block size will change sometime in bitcoin's future,
- (d) block size is VERY MUCH like bitcoin's 21M limit, so a lot of care must be taken when changing MAX_BLOCK_SIZE logic. Block size is an economically limited resource whose production is tightly defined and controlled by algorithm, with an intentionally steady production rate (the 1MB limit).
- (d.1) Nonewithstanding the major impacts of a hard fork, in and of itself.
- (e) I lean against solutions that are feedback-based (average of last 1000 block sizes, etc.), as they can be gamed too easily
- (f) implementation will likely be: if (now > chosen hard fork future date) { do it }
- (g) my default rhetorical position will be to push back against changes, for now, since there is no demonstrated need for hard fork.
- (g.1) Block sizes are nowhere near maximum, and
- (g.2) Competition for space encourages efficient solutions, whereas a too-loose block size policy incentivizes the opposite: dumping into the block chain
- (h) when I ran asic + p2pool, I set max block size at 900k and free tx at 300k. That reflects my personal (not official dev team etc.) preferences. I filtered out 1e8 outputs from mempool. We are nowhere near competing for block space at this point.
- And very importantly, (i) it is a mistake to increase block size simply because people are too lazy to implement layers on top of bitcoin. Bitcoin will forever be a zen balance of applications and layers that sit on top of the blockchain, and those that directly use the blockchain itself as their comm/functional layer (c.f. SatoshiDICE).
So I generally agree with a lot of gmaxwell's points, and it is important therefore to not arbitrarily increase blocksize, simply because that makes some apps easier -- because they free-ride on the blockchain itself. Maybe one future state of The Mainnet Blockchain is simply a high security merged mining root for several important chains, who can say?
Block size is a core economic resource, like the number of bitcoins itself. Not merely the number of transactions we can support... it influences fees and many other factors.
My off-the-cuff guess (may be wrong) for a solution was: if (todays_date > SOME_FUTURE_DATE) { MAX_BLOCK_SIZE *= 2, every 1 years } [Other devs comment: too fast!] That might be too fast, but the point is, not feedback based nor directly miner controlled.
Conclusions:
- Block size does not need to change right now.
- If and when block size changes, implement a simple rule, and let the free market figure out the rest (which might include a more complex rule years later, when the picture is more clear).
P.S. That was more than I intended to type, about block size. It seems more like The Question Of The Moment on the web, than a real engineering need. Just The Thing people are talking about right now, and largely much ado about nothing.
