Block space as a commodity (a transaction fee market exists without a block size limit)

[Peter R]

I spent time this weekend working on my proposal (due tomorrow) for the Scaling Bitcoin conference in Hong Kong. The committee has asked for proposals that are 1 - 2 pages in length, so this is about as long as the proposal can be.


PROPOSAL FOR POWERPOINT PRESENTATION AT SCALING BITCOIN

The Size of Blocks: Policy Tool or Emergent Phenomenon?

Abstract. This talk will explore the question of whether block size is a useful tool for enforcing policy or an emergent phenomenon of the network. From the policy-tool perspective, the block size represents a “lever” that policy makers might use to balance the cost of operating a node with the market price for block space (i.e., transaction fees). Assuming only that block space obeys the laws of supply and demand, we will show that for any given market condition, there exists an artificial block size limit that will produce greater network security and slower blockchain growth than the equivalent no-limit case, at the expense of higher transaction fees and reduced economic activity. Despite the flexibility offered by the policy-tool approach, we will show that little empirical evidence exists that the network is capable of enforcing a strict block size limit, questioning whether the policy-tool perspective is valid. We conclude by suggesting a simple change to the Bitcoin software to empower each node operator to more easily express his free choice regarding the size of blocks he is willing to accept while simultaneously ensuring that his node tracks consensus.

Key words: 1. Block size limit. 2. Consensus rules. 3. Rationalism. 4. Empiricism.

1. Introduction

I envision the block size debate as two groups standing on either side of a lever labeled “block size.” The group on the right is pulling the handle while yelling “lower fees and more economic activity!” The group on the left is pulling back shouting “lower node costs and higher security!” I will refer to both of these groups as the Rationalists. There is also a third group I call the Empiricists: this group is observing the debate, pondering whether the lever is actually connected to the network.

The talk I am proposing for Hong Kong has two purposes. The first is to view the block size limit from the perspective of the Rationalists and deduce how the position of the block-size lever affects the network. The second is to view the problem from the perspective of the Empiricists and, based only on what we have observed about the network, abduce the rules that the network obeys (including whether the network obeys a rule regarding the block size limit at all). The talk will conclude by showing that strict agreement on a block size limit is not required, and by suggesting a simple change to the Bitcoin software to promote scaling.

2. Quasi-static Variation of the Block Size

During this part of the talk, we will deduce how changes to the block size limit, Qmax, affect the behavior of the system, while holding all other variables constant, and assuming that the maximum size of blocks can be programmed. We will build off of the supply and demand curves presented by the author in his Montreal talk, and show that:

(1) Policy actions are only effective for Qmax < Q*, where Q* is the free market equilibrium block size.

(2) Network security is maximized for some Qmax | 0 < Qmax < Q* , resulting in greater network security than the no-limit case.

(3) The Blockchain’s growth rate increases monotonically as Qmax increases (for Qmax < Q*).

(4) The price per byte for block space decreases monotonically as Qmax increases (for Qmax < Q*).

(5) Total economic activity grows monotonically as Qmax increases (for Qmax < Q*), and is maximized for all Qmax >= Q* .

3. What Laws does the Network Obey Empirically?

In the previous section, we assumed that the network would obey the programmed rules and then we used deductive reasoning to study the effect of varying one of those rules (block size limit). In this segment of my talk, we will use empirical observations and abductive reasoning (assuming no a priori knowledge of the program code), to conclude that the network obeys the following rules:

(1) Coins cannot be moved without valid signatures.

(2) Coins cannot be spent twice.

(3) The rate at which new coins are created is strictly controlled.

(4) Nodes build upon the chain that contains the greatest cumulative work (referred to simply as the longest chain).

We will then look for empirical evidence of a block size limit. I will show that over the history of Bitcoin, the block size distribution has shown distinct “peaks” at certain block size extrema, but that these peaks have often collapsed as new peaks formed at greater block sizes. Without a priori knowledge of the program code, only sparse evidence for a block size limit exists.

Next, we will examine various emergent properties of the Bitcoin network including the market price of a bitcoin, the network hash rate, and Bitcoin’s adoption metrics. I will show that quantitative measures for each of these emergent phenomena are highly correlated with each other, and grow exponentially with time, albeit at different growth rates. I will then compare their growth patterns with the growth of the average block size, concluding that historically the block size has behaved very similarly (i.e., it behaves like an emergent phenomenon).

4. How Should the Decision Regarding Block Size Be Made?

In this final section, I will postulate two theorems:

(1) A node with a block size limit greater than the hash-power weighted median will always follow the longest chain.

(2) An excessive (e.g., greater than 1 MB) block will be accepted into the longest chain if it is smaller than the hash-power weighted median block size limit.

I will argue that it is more important that nodes follow the longest chain composed of valid transactions than dogmatically adhere to an arbitrary block size limit. I will end my talk by proposing a simple change to the bitcoin software to allow a node operator to express his free choice regarding the size of blocks he is willing to accept while simultaneously ensuring that his node tracks consensus (e.g., be "BIP101 ready").

 

[theZerg]

Great! Sounds like you are formalizing the theoretical framework for Bitcoin Unlimited!

"abduct the rules that the network obeys" -> are you sure that you can verbify the adjective abductive? Cause I can't find it in the online dictionaries...

 

[Peter R]

"Great! Sounds like you are formalizing the theoretical framework for Bitcoin Unlimited!"

Yup!

"abduct the rules that the network obeys"

Yeah, I was concerned with that too. I changed it to "abduce" which still seems a bit weird to me (although there is some precedence).

 

[JVWVU]

Wow it sounds as if they are limiting ideas and scopes for more presentations instead of locking every one in a room and fixing the issue. I was hoping for something at halving but 8 months wont cut it.

 

[dgenr8]

Network security is maximized for some Qmax | 0 < Qmax < Q*

The model is making a simplification here that needs to be explored at some point. Namely, it only looks at the technical computing linkages between blocksize and security.

There are positive linkages between the scope of economic activity and security, and a cryptocurrency with tiny adoption relative to the worldwide economy is vulnerable to economic attack. A small group of large fiat holders could deploy an open altcoin and aggressively exchange fiat value into it, stealing bitcoin's position as the cryptocurrency with the largest market capitalization. This in turn would attract hash power, usage, and development attention away from bitcoin. Fiat holders have a strong incentive to do this because they could "front run" the rest of the world.

The more economic activity occurs in bitcoin, the more difficult this attack, since the new altcoin faces a steep adoption curve with the wider economic ecosystem.

 

[Peter R]

The model is making a simplification here that needs to be explored at some point. Namely, it only looks at the technical computing linkages between blocksize and security.

There are positive linkages between the scope of economic activity and security, and a cryptocurrency with tiny adoption relative to the worldwide economy is vulnerable to economic attack. A small group of large fiat holders could deploy an open altcoin and aggressively exchange fiat value into it, stealing bitcoin's position as the cryptocurrency with the largest market capitalization. This in turn would attract hash power, usage, and development attention away from bitcoin. Fiat holders have a strong incentive to do this because they could "front run" the rest of the world.

The more economic activity occurs in bitcoin, the more difficult this attack, since the new altcoin faces a steep adoption curve with the wider economic ecosystem.

Yes, I agree with everything you just wrote. My statement is still true however because we are holding all other variables constant (including changes with time such as increased adoption). That is, for a given demand curve, network security will be higher with an artificial limit than without. However, economic activity will also be lower, suggesting that the demand curve will grow at a slower rate (a larger demand curve also increases security).

I was worried that if I took too much of a "pro big block" stance in my proposal, that it would be at a higher risk of being rejected. Instead I am just trying to present facts without too much interpretation.

 

[Peter R]

Mike Hearn from 2011 with a great analogy for why fees would never collapse to zero (even ignoring orphaning costs):

The death spiral argument assumes that I would include all transactions no matter how low their fee/priority, because it costs me nothing to do so and why would I not take the free money? Yet real life is full of companies that could do this but don't, because they understand it would undermine their own business. Consider a bus driver. He waits at point A until he has a few passengers who paid his fee and then starts driving to point B. If at the moment he's about to leave you run up and say you'll pay half price or walk, it doesn't matter ... he won't let you on board even though the marginal cost of including you is nearly nothing.

 

[Zangelbert Bingledack]

@Peter R

I think Mike is pointing toward the phenomenon of imperfect competition and how it keeps profits from zeroing out. Since there is a cost for a bus to be waiting around, there's little benefit to doubling up on routes if there are few people. The situation in Bitcoin is more like a whole bunch of buses leaving continually that have to compete for passengers. So the customer says, "No problem I'll just go with this guy over here who is offering a lower rate." That particular element of imperfect competition isn't there. Then everyone undercuts everyone else until marginal revenue is approaches marginal cost, driving profits toward zero as in any industry. Not all the way to zero, though, since there is still imperfect competition even if not to the extreme that bus companies have.

The floor for fees is then the market clearing rate. This doesn't mean zero fees, but it also doesn't mean miners "would include all transactions no matter how low their fee/priority." It will be a thin margin business, but of course still profitable (or else no one would do it, in which case it would get profitable again).

The more transactions, then, the better for miner profitability - as common sense suggests. The reason competition doesn't drive profits all the way to zero, and miners do make money, is because of imperfect competition. Bus pricing is an example of imperfect competition, which is there because of logistics and other things. I'm not sure what would cause imperfect competition among miners, but there have to be some things that would.

 

[cypherdoc]

Mike Hearn from 2011 with a great analogy for why fees would never collapse to zero (even ignoring orphaning costs):

That's a great quote from Mike

 

[Mengerian]

Great Work Peter!

(2) Network security is maximized for some Qmax | 0 < Qmax < Q* , resulting in greater network security than the no-limit case.

As a corollary, this Qmax corresponds to the greatest revenue for miners, so we could expect miners to have an incentive to restrict block sizes to this limit.

However:
1) It is impossible to know what through "rational" means what this Qmax will be, since it relies on decentralized knowledge of the preferences and choices of all network participants and potential participants.

2) It is likely that this Qmax value could change rapidly over time.

For both of these reasons, it would be unlikely that this Qmax could be found by a centrally imposed blocksize limit coded in the software. It is possible, however, that miners could group together in a cartel-like manner to orphan blocks above a certain size. Or they could achieve a similar effect by refusing to include transactions with low fees below a certain limit. Whatever method they choose, however, would be subject to market forces (cartels are fragile) and could not force unreasonable constraints on the network.

 

[Peter R]

As a corollary, this Qmax corresponds to the greatest revenue for miners, so we could expect miners to have an incentive to restrict block sizes to this limit.

Yes! Even though the protocol may not enforce a hard limit, doesn't mean that miners won't work to create a limit to increase aggregate revenue. However, unless *all* miners play along there will always exists a hard limit that increases aggregate revenue for a given demand curve (assuming demand is fixed in time).

However:
1) It is impossible to know what through "rational" means what this Qmax will be, since it relies on decentralized knowledge of the preferences and choices of all network participants and potential participants.

Correct, just because some value for Qmax exists that maximizes security, it doesn't mean that Core Dev will be able to identify it better than the miners.

Furthermore, it is fact that for any given demand curve there is a security / fee tradeoff. What is best of the network is neither lowest fees nor greatest security. It is some balance between the two. Thinking the Core Dev can identify this better than the market is the epitome of arrogance.

2) It is likely that this Qmax value could change rapidly over time.

Right, and we know how fast Core Dev can respond.

For both of these reasons, it would be unlikely that this Qmax could be found by a centrally imposed blocksize limit coded in the software. It is possible, however, that miners could group together in a cartel-like manner to orphan blocks above a certain size. Or they could achieve a similar effect by refusing to include transactions with low fees below a certain limit. Whatever method they choose, however, would be subject to market forces (cartels are fragile) and could not force unreasonable constraints on the network.

Agreed.

 

[Mengerian]

Looking at it this way also explains why BIP 100 seems to be popular with the miners. They have an incentive to restrict block sizes somewhat, and BIP 100 gives them a mechanism to do so.

Furthermore, it is fact that for any given demand curve there is a security / fee tradeoff. What is best of the network is neither lowest fees nor greatest security. It is some balance between the two. Thinking the Core Dev can identify this better than the market is the epitome of arrogance.

Yeah, I agree. It's not obvious what the best tradeoff would be. Making it easier for miners to control the blocksize limit would enable miners to push more toward the "revenue maximizing / high security" end of this spectrum, which is not necessarily best overall. A "centrally imposed" blocksize limit is even less likely to be near this optimal tradeoff.

On the other hand, I have the feeling that a revenue-maximizing blocksize constraint would end up finding equilibrium in a high volume / low fee regime, so might not be too bad. But something that arises organically from the bottom up, and has more direct market feedback, would be even more likely strike a good balance.

 

[Peter R]

Equilibrium Block Size With Weak Blocks?

Let's imagine we implement a simple version of weak blocks using a 1/10th-difficulty target, such that every minute on average a new weak block, Bi, is found.

- Assume that miners build directly on top of the previous weak block verbatim such that

Bi = Bi-1 + ΔBi
= ΔB0 + ΔB1 + ... + ΔBi-1 + ΔBi

where ΔBi represents the new transactions propagated by the miner who found the i-th weak block.

- Assume that miners incur no orphaning risk for the weak block they build upon, but the full orphaning risk for the new information they propagate (their ΔB block).

How big will a miner make his ΔB block?

At first glance, it would appear that miners will build their ΔB blocks exactly as described in my paper. In the case, the network could support 10X larger blocks at the same orphaning risk (because everyone makes their ΔB blocks the same as before, but now on average each strong block contains 10 of the ΔB blocks).

But on second thought, if we imagine that the miners want to work together, they might make their ΔB blocks even bigger due to the fact that the probability of finding a weak block (in which case they can pre-progate more fee-paying TXs) is 10X greater than the probability of finding a strong block.

Can any one see a way to formalize this?

 

[Justus Ranvier]

Let's imagine we implement a simple version of weak blocks using a 1/10th-difficulty target, such that every minute on average a new weak block, Bi, is found.

- Assume that miners build directly on top of the previous weak block verbatim

If you're making a model that assumes that all the miners on the planet have exactly the same view of the network (including weak blocks produced by other miners), I have a difficult time seeing how it's going to produce useful results.

 

[Peter R]

@Justus Ranvier

We're making the assumption that the period between the weak blocks is large compared to the mean propagation time of those weak blocks, so that a large extent of the network is in sync regarding their history.

Once we solve this idealized case, we can explore how it changes as the period between weak blocks is reduced. Like you implied, at some point the model will no longer be useful simply because of the time required to propagate those weak blocks is on the same order of magnitude as the rate at which they are found.

For now, I just want to try to understand the simplest representative case first.

 

[Peter R]

what kind of transaction fees are we seeing per block? Any data source on this?

Here is a chart that @dgenr8 recently made:

Also, footnote 19 from my fee market paper might be useful as well:

 

[bitcartel]

@dgenr8 Is there a chart to show total fees in USD?

 

[solex]

Peter, could this data be used to get a ball-park number of how much (in fees) miners are missing out on due to the hard limit? The assumption being that fees are not only rising but some volume is not being handled at all.

If the y-axis was the fee per byte, then we should see a scatter which slopes down (pretty much the reverse of this chart). Where the trend-line intersects zero (maybe its 1.5MB) take the area of the triangle beyond 1MB for the fees which are theoretically available, but can't be realised. Does this make sense?

 

[awemany]

@solex: That's a great idea!

EDIT: I am not yet sure you'll actually see a downward slope, though. I could imagine that the triangle is big. (In other words: There's a lot of money to be made by scaling Bitcoin up and demanding 1ct/txn ...)

 

[solex]

@awemany Thanks

The triangle could be arbitrarily truncated. Yet, this information supports a headline like "Bitcoin Miner's Missing Income of $X,000 Per Day"
With a punchline "X/4 is F2Pool's money".

Most of this is pure profit going begging, as rent, hardware, salaries and electricity costs are unaffected. Might concentrate the minds of the miners to be more assertive with Core Dev in line with ZB's checks & balances flowchart.