Post
Topic
Board Development & Technical Discussion
Re: Elastic block cap with rollover penalties
by
thezerg
on 03/06/2015, 12:48:09 UTC
An elastic supply is very important, but I think it can be accomplished more simply, without a pool.

Allow blocks to be expanded beyond their "nominal" size with high fee transactions.  The higher the fee, the further it can appear in the block.  Formally, define a function fee = T(x), where x is the location in the block.  If a transaction's fee is >= T(x), it can be placed in the block at location x.  T(x) = 0 for all x < 8MB (say) and increases super-linearly from there.


Note that this proposal does NOT look at the fees in aggregate -- the max block size <= S(sum(fees)), where S is some super-linear function.  That does not work because a miner could create a dummy transaction that pays himself a very large fee, thereby increasing the block size to allow space for a lot of low fee transactions.

Meni may have added the idea of a pool to solve the above problem.  But I believe that it is more easily solved by not looking at fees in aggregate.


EDIT: the biggest problem with this class of proposal is sizing the fee.  Especially given bitcoin's volatility.  However, if the fee function chosen starts at 1 satoshi, a high bitcoin price will tighten the elasticity of supply (in practice) but not entirely remove it.  At the same time, we STILL need to grow the "nominal" block size: i.e. 8MB + 20% per year, or risk pricing out personal transactions as adoption increases.  However, this class of proposal allows the network to react in a classic supply/demand fashion.  This reduces the pain when supply is exceeded, meaning that a "last-minute" hard fork as proposed by many of Gavin's opponents would be a lot less damaging to the network (block size increases could trail adoption rather than precede it).