Quote from: someone42 on June 10, 2015, 06:36:30 AM

Quote from: Meni Rosenfeld on June 07, 2015, 08:21:15 PM

1. Floating block limits have their own set of problems, and may result in a scenario where there is no effective limit at all.

2. Even if you do place a floating block limit, it doesn't really relieve of the need for an elastic system. Whatever the block limit is, tx demand can approach it and then we have a crash landing scenario. We need a system that gracefully degrades when approaching the limit, whatever it is.

Why not have both an elastic block cap and floating block limits? A common argument against floating block limits is "big miners will create super-sized blocks full of crap to artifically inflate the block limit". This attack is conveniently addressed by your rollover penalties, as the penalty is a function of block size (not of transaction fees), so miners cannot game the system by including self-mined transactions.

Consider the following floating block limit function:

Code:

T = k * median(block size of last N blocks)

evaluated every N blocks.
With k = 1.0 and N = something large like 8064, we have an equilibrium situation consisting of the status quo, where everyone stays under the soft cap of T. If a large mining cartel wishes to inflate block sizes against the will of smaller miners, they must begin creating larger blocks and paying penalties towards the smaller miners, for each block. With sufficiently large N, this is not sustainable.

Let's say Bitcoin experiences sustained, long-term growth and the fee pool/demand increases. Now everyone, including smaller miners, is creating blocks larger than T. Everyone pays penalties, but in doing so, the "penalty" isn't really a penalty; everyone receives about as much from the rollover pool as they pay. After 8064 blocks, T increases to account for this genuine, long-term increase in demand.

There are lots of parameters here, and they can be adjusted to disincentivize a mining cartel from artificially inflating block sizes. For example, increasing N and making the limit function f(x) "harder" will both increase the cost to artificially inflate block size limits. Another possibility is setting k < 1.0 (e.g. k = 0.98), which means that maintaining the status quo has a cost. If miners unanimously decide to maintain the status quo, then no-one is actually penalised because everyone receives as much from the penalty pool as they pay. However, if smaller miners feel that the status quo is unreasonable (because of past bloat from a large mining cartel), they can choose to make smaller blocks and "bleed" penalties from the larger miners. However, I am concerned that setting k < 1.0 might implicitly set an absolute minimum transaction fee.

tl;dr version:
With floating block limits + rollover penalties:
mining cartel tries to artificially inflate blocks => they must subsidize smaller miners with penalties
Bitcoin experiences genuine, long-term growth => miners unanimously include more transactions => block sizes will increase

Sounds good. I tend to agree there is good synergy between the two modifications - the limit will float only after it is stretched and penalized, making sure there is an actual need for it. I agree the time scales need to be fairly large, to make it expensive to artificially inflate the limit. Anyway, this requires more research.