Quote from: Peter R on May 16, 2014, 07:53:39 PM

Quote from: DeathAndTaxes on May 16, 2014, 05:07:07 PM

The 1MB limit will almost certainly be raised but using another sanity cap is a good idea. Optimally it would be some floating cap which is deterministic and based on blockchain usage but that may take some time to develop and test. In the interim raising to say 10MB gives the network breathing room while limiting the scope of an attack.

Would it be reasonable to calculate the floating cap each time difficulty is retarget (every 2016 blocks)? You could set the max block size to, say, 4 x avg_block_size over the last 2016-block period.

That is my general understanding however the specific multiplier and period length should have some serious analysis and debate. There are other things to consider like should the algorithm be a one way ratchet (cap can only rise not fall). What are the implications either way? Should there be sanity limits (possibly in line with Moore's law) to the rate of growth that would strike a compromise between tx volume and the resources required to operate a full node. Having one million txs per block reduces the need for centralized off chain services but if that results in only a handful of datacenters having the resources to run full nodes well that is its own kind of centralization.

This is why personally (unless someone convinces me otherwise) I think the best route is a one time fixed increase to the cap (say 5 to 10 MB block size), combined with a plan to have in place a deterministic algorithm before rising volume necessitates the need for another manual increase.

As for a target block size I am not sure if there is any value in that. Pools are already starting to diverge in terms of their criteria for transaction selection. Eligius for example tends to make the largest blocks but they also don't include non paying transactions. I see nothing wrong with that and they likely would continue to build as they see fit regardless of what the target is. If free tx volume rises and paying tx volume falls I don't think anyone should feel obligated to change their block sizes. My understanding is that future versions of bitcoind will remove default values for block generation. Miners will need to explicitly pick the values or bitcoind will produce an error. Orphan costs can be reduced ~90% by changing the new block message format to include tx hashes instead of full transactions.