Skip to content

Instantly share code, notes, and snippets.

@gavinandresen
Last active February 2, 2016 22:55
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gavinandresen/d2eec8172fc3c0db5924 to your computer and use it in GitHub Desktop.
Save gavinandresen/d2eec8172fc3c0db5924 to your computer and use it in GitHub Desktop.
Flexcap as a long-term maximum size solution

Thoughts on "flexcap"

In December, Mark Friedenbach presented a "flexcap" proposal for a long-term solution to the block size limit: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/3_tweaking_the_chain_2_friedenbach.pdf https://youtu.be/vfIs_trEhao?t=35m45s

He proposes a scheme where miners voluntarily give up part of the block reward (subsidy plus transaction fees) raise the size of the blocks they create (or, conversely, claim reward given up previously to create smaller blocks).

There is a 'base block size limit' (1megabyte in his implementation), and a non-linear function that defines how much block reward miners must give up to increase the limit above that base limit. The proposed function is quadratic past a certain point, making it increasingly expensive to produce larger blocks.

He proposes that the shape of that function be partly defined by a voting process using 'bitcoin days destroyed'; the idea is to lets transaction creators decide whether it should be more or less expensive for miners to create bigger blocks.

I have a lot of technical issues with the proposal, but I'm going to set those aside and just focus on some economics.

First, requiring miners to give up block rewards in exchange for the privilege of including more transactions in their blocks is, from the transaction creator's perspective, exactly equivalent to setting minimum transaction fees. The transaction fee must be high enough to overcome the reward that the miner is giving up, and there will be some cost for a miner to include even one extra transaction above the base block size limit. That cost rises the more there is transaction demand; the result will be an effective minimum transaction fee, defined by the transaction demand and the shape of the cost function.

Second, the incentives for transaction creators is clear: they will want the cost function to be as inexpensive as possible. Why would they ever 'vote' to make transaction fees more expensive? If they are given complete control over the cost curve, then it will be flat-- it won't cost miners anything to make larger blocks.

If they are not given complete control over the cost curve, then we are back to developer making economic policy decisions "for the good of the network."

Finally, there are several magic constants in the flexcap proposal, the most important of which is the 'base block size limit.' Each of those constants is an economic policy judgement by the developers.

If developers believe that they are in a position to make economic policy judgements, then simply imposing a mandatory minimum transaction fee would be the simplest way to control the size of blocks. A larger fee will reduce the number of transactions on the network and reduce the size of blocks, maintaining whatever network properties the developer deem most relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment