Quote from: Meni Rosenfeld on June 02, 2015, 09:45:47 PM

Quote from: ArticMine on June 02, 2015, 09:12:50 PM

The key here is how is T set. If T is fixed then 2T becomes the hard limit and the problem remains. If T is set based on an some average of previously mined blocks then this may address the problem

We still need some way to determine the optimal block size, but we have much more leeway. The wrong choice will not cause catastrophic failure, rather gradually increasing fees which will indicate that a buff is needed. The flexibility will make it easier to reach community consensus about changing hardcoded parameters.

Reusing what I wrote to Gavin an a private exchange - I don't believe in having a block limit calculated automatically based on past blocks. Because it really doesn't put a limit at all. Suppose I wanted to spam the network. Now there is a limit of 1MB/block so I create 1MB/block of junk. If I keep this up the rule will update the size to 2MB/block, and then I spam with 2MB/block. Then 4MB, ad infinitum. The effects of increasing demand for legitimate transaction is similar. There's no real limit and no real market for fees.

Perhaps we can find a solution that uses an automatic rule for short-term fluctuations, and hardcoded parameters for long-term trends. If a good automatic cap rule can be found, it will be compatible with this method.

+1 to that. I think a max thats determined as either:
T = 2.50*(average(last 8000 blocks)) #T is set the average transactions for the last ~2 months. Plenty of room for slow and steady growth, and too great a timespan to attack the blockchain with spam. keep in mind that transactions at night will probably be 1/5th the volume of those during business hours
or
T = (2.00*(average(last 8000 blocks))) + (0.50*(average(last 144 blocks))) #This would allow short-term fluctuations that take a day or two to develop. Could be susceptible to a spam attack that last longer that 3+ days.

personally, i think a block limit thats set based on the average volume of the last 1-3 months would be fine. It would be flexible if the number of transactions increases very quickly, and could grow to 3-8x the maximum within a year if theres substancial volume. combined with your proposal above it could be extremely flexible. However...

I'm EXTREMELY cautious of altering how fees are created and distributed, as any changes made will directly impact miners and could lead to bribery and corruption of the bitcoin code to better pay the centralised mining companies. Any code changes that are implemented should not involve factors or values that will need to be adjusted down the road, or it will simply lead to a 'democracy' of core-qt 'improvement'