however, the median transaction fee drastically drops as a result, and in a continued attack soon you could see that ~10% of transactions pay more than the median fee.
And if we use:
% of transactions with a fee higher than (median transaction fee of transactions with a fee)
This excludes zero fee transactions in the calculation of the median transaction fee.
In that case a large quantity of zero fee transactions (and spam) does not have influence on the median transaction fee.
perhaps a threshold? The problem is that spam is usually sent as a single transaction with 0.001btc fees and hundreds of recipients 0.0000001BTC that get. There should be protection in place that ensures sending thousands or millions of dust payments becomes prohibitively expensive, without limiting its use for colored coins or increasing fees to the regular user.
right now, the only sort of filter for this is the miners deciding whether to include or not include a transaction, and will include a spam transaction if theres a justifiable fee to do so.
IMO, the simplest way to specify the max size is as
Max Block Size = [2.50 * (average size of last 6000 blocks)] + [0.50 * (average size of last 600 blocks)]
That provides a max size thats 3x the size of the average block over the past 1000hrs (41days). If demand suddenly rises, the max size can double within a week.
say current block is ~0.5MB on average. The new size cap under this formula is 1.5MB (50% larger than it is now)
assume by the end of 2015 theres now 2MB/block on average, with business hours being around 5MB/block.
Max Block Size = [2.50 * (2)] + [0.50 * (~3MB during a busy week)] = 6.5MB
assume by the end of 2016 theres now 12MB/block on average, with business hours being around 30MB/block.
Max Block Size = [2.50 * (12)] + [0.50 * (~20MB)] = 40MB
assume that in the following week bitcoin gets popular, and suddenly there are 30-40MB blocks almost 24/7. within 4 days, the blocksize will increase to
Max Block Size = [2.50 * (~14)] + [0.50 * (~35MB)] = 52.5MB