Post
Topic
Board Development & Technical Discussion
Re: Increasing the block size is a good idea; 50%/year is probably too aggressive
by
NewLiberty
on 18/10/2014, 19:30:12 UTC
I'd welcome comments / criticism of why having such a feedback mechanism is a good or bad idea.

As with the proposal I offered, this proposal has the virtue of expanding MAX_BLOCK_SIZE when it is in demand, and contracting if fees are not sufficient to support the network (so that fees will rise).

Some issues for examination:
Previous block size:
In its simplest form the tdrja proposal the block size of previous epochs aren't factored.  This makes MAX_BLOCK_SIZE subject to rapid switching which as tdrja mentions could be cured by hysteresis, or also (new suggestion borrowed from my proposal) by having the MAX_BLOCK_SIZE a product of previous MAX_BLOCK_SIZE, modified by the tdryja proposed transaction fee metric (so a % increase/decrease).  The rapid switching may be problematic if some event stimulates a desire in many decentralized miners to radically reduce block size limit in order to restrain commerce during an event.  (It doesn't take a conspiracy, a single factor influencing miners in aggregate can do this.)

Coinbase Fee
As mentioned I like the tdrja proposal for its simplicity so I'd look ways to keep that virtue.  Still, if transaction fees are the primary metric, it would seem there may be some peril in ignoring the coinbase entirely due to it's impact on mining in the early years.  It is currently about 300x the transaction fee and so it almost entirely supports the mining effort.

There may be a way of using the coinbase fee also in this calculation, but treated differently.  The coinbase fee primarily serves the emission and distribution functions, but also stimulates adoption in the early years.  It might be used as a way of amplifying the metric in the early years (when lack of adoption is a significant existential risk, and percentage growth is presumably higher) and then let this effect subside in later years by some form of multiplying by (Coinbase)-1/2

Currently the cost per transaction, with the coinbase included, is often higher than the transacted amount.  Such transactions would not occur without the coinbase, so a way to accomodate for what this proposal would mean (because we would be unlikely to have any meaninful MAX_BLOCK_SIZE increases so long as coinbase transactions are the funding source for the network.

It would be good to increase MAX_BLOCK_SIZE long before the coinbase reward is no longer the driving force of network growth.

Squeezing out arbitrariness
There isn't much in the tdrja proposal which is arbitrarily declared by decree (fiat) other than the allocation of "What should it cost to run the bitcoin network?"
We have some indication of this from the hash rate and the total fees.  Currently total fees (coinbase and transaction) are stimulating growth in difficulty even in declining markets.