http://amincd.tumblr.com/post/100736367493/the-economics-of-the-block-sizeI wrote this over a year ago, and I thought now would be a good time to share it. I didn't have time to make it shorter, so I hope it's not too long-winded to follow.
A block size limit or unlimited block sizes?Among the opinions advocating eliminating the 1 MB block size limit, the first point of divergence is whether to:
1) Replace the 1 MB block size limit with something else to control the growth in the size of blocks
or
2) Replace it with nothing and let the ‘free market’ (put in quotation marks not to disparage the free market, which I am a huge advocate of, but because the shared costs related to Bitcoin mining make it very much unlike a free market) handle block size
Bitcoin would be better off if an option in category 1) was adopted and the 1 MB block size limit was replaced with another protocol feature that controls the growth of the block size.
To explain why, we need to first understand the problem with the Bitcoin protocol:
Block generating nodes do not pay the full network cost of the bandwidth required to download/upload - and the disk space required to store - txs that they include in blocks.
This is a fundamental shortcoming of the Bitcoin protocolThis makes it economically rewarding or only only slightly costly for individual block-generating nodes to include some txs that are economically very costly for all block-generating nodes to have in the blockchain.
ExamplesA couple of examples can better demonstrate this problem. Let’s use a simplifying assumption in our examples: let’s imagine that there is an advanced micropayment channel network between all nodes that enables and incentivizes them to only relay those unconfirmed txs that meet the fee criteria of the receiving node.
For instance, if a node only accepts txs with a fee of at least 0.00001 BTC, its peer nodes will know not to forward to it txs with fees less than this amount.
This means that nodes do not need to use up bandwidth for any tx they do not intend to include in a block, since the txs forwarded to them are pre-vetted to ensure they meet their requirements for block inclusion.
In this setting, let’s suppose that there is one block generating node (N1) that has a hash rate equal to 20% of the network hash rate, meaning it finds 1 out of 5 blocks.
Now let’s examine how the network is affected by different behavior from N1.
Worst case scenarioThe worst case scenario is if N1 accepts every tx, including those with no fees.
We can imagine that N1’s fee policy is driven by a misguided belief that the more txs the Bitcoin network processes, the better it is for the whole Bitcoin economy. It doesn’t really matter what the motivation for N1’s behavior is, just that exhibition of such a behavior is not outside the realm of possibility.
Now, despite the protocol not imposing any limits on number of txs per block, there is a practical limit to how many txs N1 can accept into a single block. This is because, due to the time it takes to download very large blocks, nodes each have their own limits on what sized blocks they will build upon.
Blocks above a certain size won’t be accepted and built upon by enough block generating nodes to get over 50% of the network hash rate building on them, leading to those blocks eventually being orphaned, which would eventually create an incentive for all block generating nodes to not build upon them. This is the ‘informal block size limit’.
Let’s suppose that 8 GB is the informal block size limit while the average block size of blocks other than those generated by N1 is 100 MB.
N1 always includes 8 GB worth of txs, the maximum, in its blocks. 1 GB of those txs have a fee, while 7 GB are txs with zero fees. The informal block size limit prevents N1 from including another 2 GB of zero fee txs, while any tx with a fee is guaranteed a place in N1’s blocks.
Ideally, the incentives of block generation would result in block generating nodes only accepting those txs that have a fee that covers their cost for downloading, and if they find a block, propagating those txs.
Due to N1’s fee policy though, other block generating nodes would have no incentive to reject txs that have insufficient fees, because if they reject the txs, they will still have to use bandwidth to download them, when N1 finds a 8 GB block and they download it.
In this scenario, it’s in their best interest to get whatever fees they can, since they will be paying the bandwidth for the tx anyway.
The result is that all of the block generating nodes change their fee policy to accept txs with very low fees. Users are thereby incentivized to also lower the fees they pay, since almost any fee is enough to get their tx included in a block in a timely manner.
The fees being provided in a network with these characteristics would eventually become totally insufficient to pay for the cost of bandwidth, and the informal block size limit, along with the average block size, would steadily rise as smaller nodes with less bandwidth drop out of the network, leaving only the giants.
More realistic scenarioA more realistic scenario is if N1 has a fee policy of only accepting txs that have a large enough fee that it is not a net-loss for N1 to include them in the blocks it works on.
Let’s assume the bandwidth cost for all nodes to download and propagate 1 GB of transaction data is $1, and that txs are on average 500 bytes. Since N1 has a hash rate equal to 20% of the network, it will need an average fee on txs that equals $0.0000025 (1/0.20 * $1/GB * 500 bytes) to break even.
Let’s further assume that N1 generates block that on average are 500 MB in size, while the average block size of blocks generated by nodes other than N1 is 100 MB, because most nodes have a lower hash rate than N1, and therefore need to have a stricter fee policy that rejects more txs.
As in the last example though, eventually, the other nodes see that it is in their interest to accept txs that N1 is accepting, because if they don’t, they will miss out on a chance to earn the fee attached to the txs, and will have to use bandwidth to download the txs anyway when N1 finds a 500 MB block that includes them.
Also as in the last example, as more nodes start accepting lower-fee txs, users will reduce the fees they pay, because they know that any tx meeting N1’s fee policy will be included into a block in a timely manner.
The result would be that the average block size would trend toward 500 MB, with tx fees trending towards $0.0000025, or a total $2.50 of per block ($0.0000025/500 bytes * 500 MB).
The bandwidth cost for N1 per block would be $0.50 ($1/GB * 500 MB), and the amount it earns in fees would also equal $0.50 ($2.50 earned per block found * ⅕ blocks found), meaning it would break even.
N1 is not a typical node though. Most block generating nodes have a hash rate significantly lower than 20% of the network hash rate.
For instance, N2 has a hash rate equal to 1% of the network’s, so it will earn an average of $0.025 per block ($2.50 per block found * 1/100 blocks found). Bandwidth costs for N2 will be the same as for N1 however, at $0.50 per block, meaning that N2 will suffer a loss of $0.475 per block.
Repercussions for NetworkThe total block reward for the network (R) will equal the average fees per GB of tx data (F) * the average block size (B) + the block subsidy (S).
R = F(B) + S
The total bandwidth cost for the network per block (T) will equal the number of block generating nodes in the network (N) * the average cost of bandwidth per node per GB of tx data (C) * the average block size (B).
T = N(C)(B)
The amount of resources allocated to producing proof of work (H) will equal the total block reward for the network (R) - the total bandwidth cost for the network per block (T) - the equilibrium profit margin for block generation (P) * the total block reward for the network (R).
H = R - T - P(R)
or
H = F(B) + S - N(C)(B) - P(F(B)+S)
In less formal terms: block generating nodes, as a result of competitive incentives, will be driven to spend any block reward they earn, net their bandwidth costs and the amount of profit they take, on increasing the proof of work they generate. The greater the block reward relative to the bandwidth cost, the more proof of work the network will produce, and therefore, the more secure it will be.
The following graph shows the relationship between average block size (B) and the the amount of resources allocated to producing proof of work (H). It assumes:
the number of block generating nodes in the network (N) = 1,000,
the block subsidy (S) = $2,000,
the average cost of bandwidth per node per GB of tx data (C) = $1,
the equilibrium profit margin for block generation (P) = 1%,
the average fees per GB of tx data (F) = $5.00
As can be seen, with these constants, increases in the block size lead to rapidly diminishing resources being used to produce proof of work.
We can make more optimistic assumptions about the values of the constants and the situation still looks dire.
For example, if we assume that the troublemaking node, N1, requires tx fees that are 5 times larger than the cost of the bandwidth it needs to use to download and propagate the tx, rather than tx fees that merely allow it to break even on bandwidth costs, then its required fee on a 500 byte tx would rise to $0.0000125 (5 * 1/0.20 * $1/GB * 500 bytes), and the average fees per GB of tx data (F) would rise to $25 ($0.0000125/500 bytes * 1 GB).
The graph below shows the relationship between block size and resources dedicated to producing proof of work with this value for F:
The total block reward for the network (R) increases by only $35 as the block size increases from 100 MB to 1.5 GB, because transaction fees average only $25 per GB of tx data. Meanwhile, the total bandwidth cost for the network (T) increases by $1,400 as the block size grows 1.4 GB, due to network bandwidth costs of $1,000 per GB of tx data.
Even with more optimistic assumptions about the values of the constants, the situation still remains dire.
For example, if we assume the number of block generating nodes (N) is reduced from 1,000 to 100, and make the same optimistic assumption about the average fees per GB of tx data (F) being $25, this graph is the result:
There is no noticeable increase in the resources dedicated to producing proof of work, despite the much more optimistic assumption about the behaviour of the highest hash rate node and the total number of block generating nodes in operation.
In a situation where the very plausible starting assumptions of this analysis turn out to be true, the absence of a block size limit will mean reduced network security as transaction volumes increase.
