Between all the flames on this list, several ideas were raised that did not get 
much attention. I hereby resubmit these ideas for consideration and discussion.

- Perhaps the hard block size limit should be a function of the actual block 
sizes over some trailing sampling period. For example, take the median block 
size among the most recent 2016 blocks and multiply it by 1.5. This allows 
Bitcoin to scale up gradually and organically, rather than having human beings 
guessing at what is an appropriate limit.

- Perhaps the hard block size limit should be determined by a vote of the 
miners. Each miner could embed a desired block size limit in the coinbase 
transactions of the blocks it publishes. The effective hard block size limit 
would be that size having the greatest number of votes within a sliding window 
of most recent blocks.

- Perhaps the hard block size limit should be a function of block-chain length, 
so that it can scale up smoothly rather than jumping immediately to 20 MB. This 
function could be linear (anticipating a breakdown of Moore's Law) or quadratic.

I would be in support of any of the above, but I do not support Mike Hearn's 
proposed jump to 20 MB. Hearn's proposal kicks the can down the road without 
actually solving the problem, and it does so in a controversial (step function) 

One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.;117567292;y
Bitcoin-development mailing list

Reply via email to