Scaling Bitcoin workshop : Hong Kong 2015
Why miners will not voluntarily individually produce smaller blocks
Marginal cost is very low.
In about 2011, people started discussing the idea of needing an artificial cap for a block size limit to kind of kick up the transaction fees. The orphan risk is a marginal cost the larger the block, the higher the chance of an orphan.
Now I've got some issues why orphan risk may not be so great. As technology improves, over time the technology cost of orphaning gets lower and lower, so you are relying on driving miner revenue or fees, would become less relevant. I also think that orphans just by nature are kind of bad, and the aim of the system is to prevent orphans. Another reason is that orphan risk in general, the larger you are, the larger your mining operation, you don't need to propagate to yourself. This incentivizes mining centralization, because a smaller mine rwould have to propagate to a larger portion of the network.
The defense that people give to the orphan risk idea is that, orphan risk is not a great concern and it's jus tanother cost to miner like rent and salary and electricity, and the Chinese already have a capacity advantage, so all we're doing is adding one more cost, which just increases decentralization because Chinese already have the lead here. But orphan risk is quite unique. With these other cost, it's economies of scale that could run out. If you have low energy cost, if you are near hydrothermal or something, you will use up that capacity eventually. Orphan risk is lower for larger miners and this is an inherent property of the system and might always encourage centralization. With the other costs, we hope that the impact eventually runs out, but orphan risk might not.
And then there's the question of how does marginal orphan risk vary when the block size varies? As the block size increases, does the oprhan risk go higher and higher? Whatever happens, you're always going to be in a bad scenario. This is an illustration of the graph. The dark green line is the marginal orphan risk cost. The yellow line below it is the average orphan risk cost. You have the other two lines, are the fees or the demand curve. This seems that miners keep producing blocks up to the point where marginal orphan risk equals the marginal transaction fee. You can see the red area is the total orphan risk. And the yellow area is the total average transaction fee. In this exponential scenario, the red area is a large portion of total revenue. What is total margin risk? Total orphan risk relative to miner fee revenue? If I was to draw this line where there was a linear relationship to block size and marginal orphan rate, then it would actually say 100% of miner revenue would be equal to the economic value of orphan risk. I think this is quite potentially dangerous, or potentially dangerous to rely on orphan risk to drive the fee market.
A very common question is why don't miners voluntarily produce smaller blocks? Why does a fee limit matter? Miners will just produce smaller blocks. This was discussed in 2011. Each individual miner wants to generate as much cash as possible. They will include as many transactions as possible. One is to look at the whole mining industry as a whole, maybe the mining industry will produce smaller blocks to produce and protect the Bitcoin industry. The incentives for each individual miner is they want to generate as large blocks as possible. A lot of people don't agree, they think this is too theoretical, it's unproven game theory, the focus is too much on the local and not the longer-term. I think this tragedy of the commons problem we can see today in the commodities markets. If you look at iron ore, the miners keep producing more and more, and the price keeps falling of iron ore. It's a benefit to the industry for the miners to cut production, and for price to rise, but the game theory doesn't work out like that. They each produce as much as possible to generate as much cash as they can. They never voluntarily reduce production. They keep producing as much as they can, to produce cashflow to ensure their survival.
This is probably fine in most commodity markets. But in bitcoin, we always need a healthy mining network. There's a spectrum of how miners think. One group of people would say that miners care about long-term interests of the system, and they are playing a game of Life. But the other end of the spectrum is that miners care more about short-term profit optimization. But the reality is that nobody is right here, there's a whole spectrum of mining priorities.
If the miners care more about long-term interests of the system, then maybe they wont include big blocks. We need to be aware of how miner incentives change. We need to build a robust economic system across the system. At the moment, everyone is collaborating. There is a risk that this will change in the future. Because of this risk, we need to realize that people could become very selfish and care only about the next block.
Now I am going to talk about bip100 and why it might solve some of these issues. Under bip100, miners must vote for the block size they want. Rational miners should vote to maximize their revenue. Some might care about long-term revenue, and some about short-term revenue. Revenue is block reward exchange rate + transaction volume average fee * exchange rate. Miners would vote in a balanced way, so at the moment people are debating the relative importance of the fee level or the transaction level or exchange rate, bip100 would be where miners dynamically vote in a balanced way to reflect these competing priorities. They will make their decision based on expected elasticity of their supply curve. The supply curve would be a straight curve, and miners would vote to move it back left or right, and the ywould try to maximize their fee revenue. This is quite contentious because most people don't like this straight vertical line, because it implies that the ... whereas other people think there's always excess capacity. I don't think we should make a decision now. What we need to do is just keep our options open. Don't adopt a scaling proposal that locks us into constantly increasing block size. I don't think we have enough information now to find a right or wrong answer, we should keep an open mind, or adopt a proposal that allows us to go in either direction.
A common criticism of bip100 is that bip100 is a cartel. I admit it does have characteristics similar to a cartel. It enables cartel-like pricing. It's like an open framework that allows miners to decide on the block size limit in a transparent way. I think it's a good idea because I think miners would form a cartel anyway, to restrict supply space in blocks anyway, and drive up transaction fee prices. bip100 could prevent the actual cartel from forming perhaps.
Another proposal I have is that we need to recognize the difference between an increase in the limit, and a decrease in the limit. A majority of miners can impose a decrease in the limit anyway without the need for a hard-fork or any change, because 55% of the miners or whatever can always reject any block larger than some amount. This is why I think these voting mechanisms should reflect this. I think there's a proposal that requires 80% to decrease the limit, whereas I think it should always be 50%. If 79% vote for a limit reduction, this sort of advertises that 79% want it down, and this will serve as a catalyst for cartel formation anyway. If 79% can just reduce the limit, then they can ignore the voting mechanism and undermine it through forming a cartel. So I think the voting mechanisms should be designed in a way to keep this in mind, and discourage cartel creation.
I am not claiming that bip100 is perfect. It has a lot of problems. The block size limit would be sub-optimal. It's very difficult to say because the utility is kind of subjective anyway. I like bip100 from an economics perspective, there are far better technical experts than me that we can't increase the limit, I am in favor of upper and lower bounds.
There are no perfect solutions, and we need to be pragmatic and work together and be willing to compromise and accept something we don't like, because there's a lot of pressure. I think there are good proposals out there. BIP100, BIP102 and BIP103 seem like somewhat reasonable interim solutions. Thank you very much, and I'll take questions.
Q: I had an idea that I wanted to hear your take on. Rather than creating a block size changing as a way for miners to change the supply for block space, why not use miner policy, a non-fork related aspect, to control the minimum price available, so basically putting a fee floor for inclusion of transactions into blocks? What do you think? The idea is to use altruistic punishment in order to enforce the fee floor. Miners could set a certain percentage of their hashpower to intentionally orphan miners who break that. I'm not sure if I like this.
A: It's interesting. I've thought about it for a bit. I think that people already don't like bip100 because they feel they are putting the miners in control. Having a fee floor kind of manipulates the market even more and is liable to make people even less happy. That is effectively a mining cartel, and we want to avoid that as possible.
Q: collective bargaining.
Q: I've noticed that some miners have credibly said tha the 1 MB limit is already straining the network quite significantly. What do you think is the prudent approach, since we're talking about scaling the network, however proposals have suggested it might be prudent to go and wait and see. Do you think the comments from the miners that 1 MB is difficult enough, should be taken seriously?
A: I think it should be taken seriously. I think we shouldn't rush to have a big jump in block size. I think we need a moderate approach and balance that considers everyone's data. I think there's a risk that if we don't do anything, people are going to split and one side might have an aggressive explosive position that will be more difficult to reconcile in the future. Remaining together in one group might be impossible.
Q: What is your stand on bip105 and bip106?
A: Sorry, I don't know those.