Economics of block size limit

[markm]

Good point, okay, how about interleave the two adjustments, halving the subsidy halfway through each doubling of the size period aka doubling the size halfway through each halving of the subsidy period?

-MarkM-

[misterbigg]

Good point, okay, how about interleave the two adjustments, halving the subsidy halfway through each doubling of the size period aka doubling the size halfway through each halving of the subsidy period?

I think that any fixed block size inflation schedule or any inflation schedule that is based on static measurement of block chain history, would require an oracle to tune correctly. Since we do not have an oracle, it is guaranteed that the block size will either grow too quickly, or grow too slowly. The consequence of growing too slowly is that we incurred the cost of a hard fork for nothing (although it can be argued that it is better than having no change in the limit).

But the consequence of growing too quickly is severe, a large drop in fees. Even if you stagger the subsidy cut and the block size increase, there is a mismatch in the two growth curves.

Each successive cut in the subsidy has an exponentially decreasing effect on the network. Consider the last cut, going from 2 satoshis down to 1. It is practically nothing. Most of the coins were created in the first 4 years. Over the next 4 years we will create 25% of all the coins that will ever be created. Let's pretend that the subsidy will end in 40 years. By that time the block size will be 512 megabytes. You have an inverted curve compared to the money supply. Most of the block size increase will happen in the last 4 years of the inflation schedule, at a time when very few coins are created. Just when we need transaction fees the most (at the end of the inflation schedule), we would create  the largest decrease in the market for fees ever: each doubling of the block size sets a new record for reducing scarcity.

An exponential growth characteristic seems wrong. Now you might say, well why don't we make it geometric? Say, a percentage increase each time? The problem, while not as severe, still remains: you need an oracle to tune the percentage correctly. Even if we knew the "god percentage" (globally optimum growth value), we could have oscillations where sometimes the optimum percentage is too little, and sometimes its too much.

At the same time, this analysis completely ignores the effect of bandwidth. If we take that into account, every doubling of the block size will double the minimum bandwidth requirement. If transmitting a block took 5 seconds for the average node, it would take 42 minutes after 40 years (using the example above). Are we going to bet Bitcoin's existence on average bandwidth increasing by a factor of 500 in 4 decades?

Again, I think we should drop the idea of a fixed schedule of block size increases. Furthermore, for the analysis I gave elsewhere we should drop the idea of any sort of static measuring system to adapt the block size. I think that so far only the voting system is resistant to all the problems I mentioned.

The optimum method for increasing the block size would have to factor in the exchange rate, people's tolerance for fees, and the effects of the increased bandwidth requirement. I do not believe this can be modeled in an automated fashion. Therefore, we solve the problem in parallel by letting miners try to solve this complex equation for their own use-case and vote on the result.

[markm]

If so then we are down to determining what percent to increase by per referendum and what percent yes vote in the referendum is required to cause that increase.

Maybe frequency of referendi too. (Faux Latin! Or is that real Latin? (By some sheer fluke.))

-MarkM-

[misterbigg]

If so then we are down to determining what percent to increase by per referendum and what percent yes vote in the referendum is required to cause that increase...Maybe frequency of referendi too.

The nitpicking details of what percentages to use are just constants. It is still a voting system. I'm sure we could come up with an infinite set of variations on the voting theme. Maybe instead of a yes/no vote everyone just votes on what they think the new size should be (this would let it go up and down). Then we take some sort of smoothed median? Who knows.

Maybe someone can come up with a better idea than voting. In my mind there are only two workable choices for addressing max block size:

1) leave it alone
2) vote in the block chain

As far as the percentages go, the amount of increase should be small enough so that we always err on the side of being conservative with the increase. It is always preferred to raise the block size limit by too little rather than too much. In other words, better that the fees are too high (more security) than too low. As far as the 90% well that would be a politically driven choice.

[markm]

(this would let it go up and down).

Can we really not get rid of any going back down? If it can come down later it ought not to have gone up in the first place.

-MarkM-

[TierNolan]

1) leave it alone
2) vote in the block chain

3) Base it on some metric

Adding a formal way to measure orphans would be one way to see if the network can handle the current block size.  This could be accomplished by adding another field into the header to list orphans (maybe a merkle root), since the last difficulty adjustment. 

That isn't perfect, since a majority of miners might refuse to include blocks that list miners (assuming miners want to increase the size, even though there are orphans).

[oleganza]

People often overlook two things:

1. When there are more transactions that blocks can handle, they will not be dropped, but will go elsewhere. Namely, through some escrows. So instead of congesting bandwidth in some part of the network, they will take up bandwidth in some other part of the network. It's just a question of who will get paid for it: miners or escrows.

2. Bandwidth is not a static environment that we happen to float in. It is a series of tubes that are owned by someone and paid by people who use them. If someone wants to send or receive more data, he will pay for it. If he is not willing to pay more than $X, he will not send/receive more than Y bits/s. So there is no question of "lets save precious bandwidth", everyone decides on his own.

It is absolutely irrelevant what you think about how security "as a whole" is achieved through fees and mining profits. Miners have interest in keeping transactions validated and blocks pushed to *other* miners as quick as possible. Users and escrows are interested in having their transactions validated as quick and as cheaply as possible. So it is irrelevant what you, independent non-mining "validator", thinks about your own bandwidth. If you cannot keep up with the miners, no one will notice. Yes, maybe security will be worse without you. But it does not matter, because people will continue doing what they do as long as they think the security is "good enough". It is absolutely possible in the future to have some miners build their own optical fiber channels between each other to provide the fastest validation possible for biggest blocks possible. Everyone else will naturally join the network to read the latest data from it at their own pace with their own bandwidth.

In fact, this happens already. If an owner of mining equipment wants to avoid issues with bandwidth and orphaned blocks, he simply joins the mining pool. So you end up having small number of well-connected miners who actually collect and validate transactions, while everyone else who has invested in hardware can use slower bandwidth and perform hashing only, without a need to send/receive blocks. If however, the costs of bandwidth are lower for miner than pool fees, then he will mine on his own. It is pure economics that will determine how the bandwidth is used.

Some people worry that this may end up as a single global super-mining-pool. It will not, because the pool by itself is useless: it is actual miners who connect to the pool make it valuable. They, of course, want to hedge their risks, so they will never end up in a huge pool. So there is always an opportunity for competitors to establish their pools. And then every pool owner will strongly desire the best connectivity to his competitors to reduce his own costs.

I predict that the limit will either be abolished completely (less probable, considering amount of FUD), or bumped from 1 MB to 2 MB, then to 4 MB etc. as long as demand for transactions increases. When the bandwidth will get in the way of miners, they will reduce block size voluntarily regardless of the hard limit.

Also, think of it this way: imagine year 1998 when everything was slower. The Bitcoin would have artificial limit of 50 Kb per block. Does it look that everyone would prefer having this limit today, pay $50 in transaction fees and pass all sub-$1000 transactions through escrows? Of course not. The same goes for 1 Mb limit today. In 5 years it will look just silly.

[markm]

Also, think of it this way: imagine year 1998 when everything was slower. The Bitcoin would have artificial limit of 50 Kb per block. Does it look that everyone would prefer having this limit today, pay $50 in transaction fees and pass all sub-$1000 transactions through escrows? Of course not. The same goes for 1 Mb limit today. In 5 years it will look just silly.

1998 : 00.05 MB (50k)
2002 : 00.10 MB
2006 : 00.20 MB
2010 : 00.40 MB
2014 : 00.80 MB

Hey, you're right, 50k in 1998 with the 4 years thing we're only a little ahead of schedule, but are nowhere near hitting the max. Cool, start the 4 year doubling way back in 1998 then.

If we start it now though, we could instead end up with

2014 : 02.00 MB
2020 : 04.00 MB
2024 : 08.00 MB
2028 : 16.00 MB

So at 2028 and onward we'd be starting into some seriously large increases in size.

As you said, miners are free to voluntarily use smaller if they choose.

-MarkM-

[oleganza]

I was never saying anything about the *schedule* of changing the block limit. I was saying that as soon as limit is limiting, it will be raised. It may happen in 10 years or 10 months. Nobody knows and I don't care. Even if today miners+users agree to some schedule, if they hit the limit much sooner than the next increase, they will vote to raise the limit earlier.

Unless you have some sort of function of number of transactions (like difficulty is function of number of blocks, not time). But the more complex schedule you propose, the more unreliable it will be to implement and less probable to vote it in.

[markm]

Much the same probably applies to the security.

Before the twin towers got knocked down, did people vote in the removal of of what liberties or privacies they had not already lost by then? Or did it take a catastrophe  to make an entire nation or maybe even continent finally upgrade its infrastructure enough to hopefully make it invulnerable to that kind of attack going forward?

Of course some people are not going to want to be invulnerable to a too large block, as they are going to want to be the attacker. Others will not because they cannot afford the far far too excessively huge setting the fat cats think is fine for a max block, so simply will not put enough resources in place to handle it.

When the attack comes, paralysing the whole nation we'll be going like damn just leaving the max block size at a reasonable level would have nipped that in the bud. Prevented it outright.

We really kind of need it to be achievable all around, not so high that tons of pipes never actually bother to even try to really be capable of it because it just seems like some number the megacorps put in to blow them away with, not a reasonable defensive measure at all. If it is there so the megacorps can blow you away you might as well just wait for them to blow you away instead of blowing yourself away voluntarily ahead of time by trying to upgrade to prepare for it when you aren't even getting anywhere near enough transactions yet to even fill the current limit.

Remember, final settlement with, for example, paypal, takes six months. So having transactions take up to six months to finally get into the chain is a good thing, its by design in networks like paypal.

-MarkM-

[oleganza]

Could you please provide a proof for your assertion?

1. Do you seriously suggest that you are better protected after 9/11? Considering amount of non-justified warfare in muslim world for the last 10 years, I would think that any US citizen is now more vulnerable to random terrorist attacks than before. Also, everybody knows how efficient TSA is at finding actual bad guys.

2. That unlimited block size is a path for massive all-destroying attack. In other words, what is the recipe to bring down the network when block size is not limited? Also, I'm really interested how this situation is different from, having a powerful miner who does not include any useful transactions in his blocks.

Also, do not forget that Bitcoin operations were never based on good will of people how endlessly cooperate in the name of common good. Everyone is running his node for his own benefit since the inception. And anyone who wants to play by different rules, is free to do so and some people do. The whole network never needed any appeal to "common good" and "lets all think for the future".

When each individual user weights risk of theoretical flood-attack with a higher block size limit against his actual measurable costs transactions, the decision will be made. I cannot say how much increase will be justified by vast majority: 2 Mb, 10 Mb or 1000 Mb, this will depend on the lowest common denominator for 99% of users. The remaining 1% will have to play along. Just like some people who do not like 6 Gb blockchain, they have to either accept it, or trust someone else to keep it. The fact that Bitcoin is decentralized does not mean that everybody must always agree with each other on everything. If vast majority expects benefit from change, the change will come ;-)

[cypherdoc]

It is crucial to understand the concept and, yes, economic impact of a hard fork before even approaching the economic analysis of changing the max block size.

A hard fork is a significant event that knocks legitimate users off the network, makes coins unspendable, or potentially makes the same coins spendable in two different locations, depending on whether or not you're talking to an updated node.

It is, to pick a dramatic term, an Extinction Level Event.  If done poorly, a hard fork could make it impossible for reasonable merchants to trust the bitcoins they receive, the very foundation of their economic value.

Furthermore, a hard fork is akin to a Constitutional Convention:  a hard fork implies the ability to rewrite the ground rules of bitcoin, be it block size, 21M limit, SHA256 hash, or other hard-baked behavior.  Thus, there is always the risk of unpredictable miners, users and devs changing more than just the block size precisely because it makes the most engineering sense to change other hard-to-change features at the time of hard-fork.

It is a nuclear option with widespread economic consequences for all bitcoin users.

thank you for this.  thus, i would suggest making any changes to block size only if absolutely necessary.

[Technomage]

thank you for this.  thus, i would suggest making any changes to block size only if absolutely necessary.

I don't think many here is suggesting we do a hard fork unless absolutely necessary. Thing is, it's very likely to become necessary at some point. It isn't necessary now, or in a while yet, but we anticipate it will be in the future.

It really doesn't matter even if Bitcoin doesn't become the jack of all trades (which I think it won't because the blockchain structure is just too heavy for doing everything), it's just that the usage of it in any mainstream capacity will become fairly impossible for anything other than the transfer of very large amounts, unless this is eventually changed. 7 transactions per second is simply not enough.

It's extremely important for people to stop looking at this like we either have Bitcoin as this very rigid and inflexible system that can store value well, or we "try to scale it infinitely and risk safe value storage". The real issue is anything but that. There is a clear middle ground which is what we should aim for.

Bitcoin is not suitable for all possible transaction types that people have need for but it can do more than 7 transactions a second, and it needs to do more than that. Otherwise we will at some point hit a brick wall in Bitcoin adoption.

[solex]

Bitcoin is not suitable for all possible transaction types that people have need for but it can do more than 7 transactions a second, and it needs to do more than that. Otherwise we will at some point hit a brick wall in Bitcoin adoption.

Exactly.

Also, that point is within a year, based upon the long-term growth rate:

http://blockchain.info/charts/n-transactions?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=1&address=

I calculate 345,000 per day as the level where 1Mb block saturation occurs.

[Syke]

Bitcoin is not suitable for all possible transaction types that people have need for but it can do more than 7 transactions a second, and it needs to do more than that. Otherwise we will at some point hit a brick wall in Bitcoin adoption.

Exactly.

Also, that point is within a year, based upon the long-term growth rate:

http://blockchain.info/charts/n-transactions?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=1&address=

I calculate 345,000 per day as the level where 1Mb block saturation occurs.

I hesitate to call SatoshiDICE spam or dust, but the vast majority of those transactions are small transfers going back and forth between the same 2 addresses. It would be a very bad idea if we created a hard fork just so people could transfer one BTC back and forth constantly.

[solex]

Bitcoin is not suitable for all possible transaction types that people have need for but it can do more than 7 transactions a second, and it needs to do more than that. Otherwise we will at some point hit a brick wall in Bitcoin adoption.

Exactly.

Also, that point is within a year, based upon the long-term growth rate:

http://blockchain.info/charts/n-transactions?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=1&address=

I calculate 345,000 per day as the level where 1Mb block saturation occurs.

I hesitate to call SatoshiDICE spam or dust, but the vast majority of those transactions are small transfers going back and forth between the same 2 addresses. It would be a very bad idea if we created a hard fork just so people could transfer one BTC back and forth constantly.

Absolutely! SD is just over 50% of the vols, but unless it voluntarily closes down, (and no similar sites pop up) then the mathematics have Bitcoin hitting a self-imposed limit this year. Perhaps SD should internalize their transactions to give more time for the 1Mb limit to be addressed. Note that SD also pays a lot in fees. None of this is a black-and-white issue.

[justusranvier]

Ideally we want mining to be supported by transaction fees rather than the block subsidy so that mining capacity will scale with demand. So the question to answer is when that will happen.

Right now with the blocks about 25% full we are seeing about 50 BTC of transaction fees per day. This means that with 1 MB blocks the network will earn 200 BTC/day in transaction fees or 1.4 BTC/block.

That's obviously not much of an incentive. At 18 MB blocks, however, transaction fees should equal the block reward. With twice the effective income the incentive to mine will double, so we should expect double the investment in ASICs. Since there will be multiple suppliers in the market soon this should result in an increase in the number of miners. If the block size is allowed to increase to meet demand then every increase will result in more economic incentive to mine and this more miners.

[misterbigg]

Right now with the blocks about 25% full we are seeing about 50 BTC of transaction fees per day. This means that with 1 MB blocks the network will earn 200 BTC/day in transaction fees or 1.4 BTC/block.

No it doesn't. Read the other threads to understand why.

[justusranvier]

No it doesn't. Read the other threads to understand why.

The other threads are full of unsubstantiated irrational assertions, and short on data. They rely on the observed relationship between transaction volume and fee revenue to magically reverse for no reason.

[misterbigg]

No it doesn't. Read the other threads to understand why.

The other threads are full of unsubstantiated irrational assertions, and short on data. They rely on the observed relationship between transaction volume and fee revenue to magically reverse for no reason.

The only reason people pay fees now is because there is a minimum fee requirement in order for transactions to get relayed. Paying more than the minimum fee requirement doesn't help because blocks aren't full.