Nice animated graphs, weex.

Here's a plot of the mempool size for the past day, for comparison to normal levels.  



Also note the spike in required fees, brought about by the higher-than-average fees being paid by the spammed transactions.

Live graphs are available here.

An argument for your consideration -

1. The purpose of the graph is to help users decide what fee rate to pay with their transaction.

2. The assumption is that miners (mostly) prioritize transactions by their fee rate, so by looking at the intersection of the graph with the line y = <typical max block size of 750-1000 kB>, we can gauge what fee rate is required to get into the next block, if it arrives now.

3. Miners do not, however, use a floor tx size of 1 kB when calculating fee rate (not in the reference implementation i.e. CreateNewBlock, nor is it economically rational - a miner should prioritize for example a 250 byte transaction over a 1000 byte one, if they are both paying the same fixed fee).

4. Therefore the data as presented now, with the floor size, is distorted with respect to its purpose in (1).

As a concrete example, consider a flood of 250 byte transactions, each paying a 0.1 mBTC fee. On the graph, it will show up as a fee rate of 0.1 mBTC / kB, because of the floor.

Next, consider a user who wants to jump ahead of the queue, so he views the graph and says, OK, I'll pay 0.2 mBTC per kB instead. His transaction is say 1 kB, so he pays a 0.2 mBTC fee.

However, in reality he would not have jumped ahead of the queue at all, because the fee rate of the flooded transactions (0.4 mBTC per 1000 bytes) is higher than that of his transaction.  So, he was not helped by the graph.

Thanks Jorge for the mini-analysis.  I'm the developer of that site.

The plot you linked is a dynamic one; so here is the static plot of that time interval:



And the same graph, but scaled for viewing of the tx byterate:



Some things to note (I should have added this on the site, ideally):

1. The tx byterate estimation is done using a exponential moving average, with a halflife of 1 hour.

2. The capacity byterate is given by

blockrate * expected max block size

where expectation is taken over the mining pools; estimates for pool max block size policies can be found here.

Just a comment on the following:


I don't think you can say that - that would be like saying, queues are never a problem as long as utilization is < 1 (which of course is required for stability). But long queues do in fact develop when utilization is < 1, due to variability in service / arrival times (re: bitcoin, the dominant source of variability is in inter-block times).

As long as there are queues, fee tension will be present, as mempool transactions are largely prioritised by feerate. Empirically, we are observing periods of fee tension (i.e. busy periods, when pools' max block size is reached) quite often these days.

Otherwise I like this perspective on the block size problem (even though I can't really comment on the proposed solution), in particular the observation that in the short term transaction demand is inelastic. (Upon further thought, however, proponents of increasing block size would say that the inelastic demand problem doesn't really apply if the block size cap is sufficiently higher than the average transaction rate.)