Why Low Transaction Fees Are Not an Issue for Bitcoin

I would like to apologize for not posting an article in a very long time. While I have been able to post and comment on r/btc, I have been busy with University, and I haven't come around to making articles in a long time because it generally requires a lot of resources and effort to make them (I generally don't make a lot of articles, because I am more focused on the quality of articles rather than the quantity). I have many ideas for articles that I'm working on, but they will likely be in the somewhat far future due to the amount of research I'm doing on them, and the fact that I'm constantly learning more and more about Bitcoin every day. The amount of knowledge I've gotten from r/btc alone has really been able to give me an informed view on subjects related to Bitcoin and cryptocurrency as a whole. I would like to thank r/btc for how much I've learned, because knowledge is one of the greatest gifts of all ;)

I've seen many people (those who are opposed to low fees to use the blockchain) arguing that high fees are needed to secure the network, and keep miners incentivized to include transactions into the next block. The security model of Bitcoin long-term certainly is something worth thinking about, and I often think about it a lot myself. There are many discussions on r/btc regarding a fee-market, and the potential issues Bitcoin may face (economically) when the block reward becomes effectively none. While this is a valid concern (albeit, blown WAY out of proportion), I often see people argue that to make up for the subsidy, we absolutely NEED high transaction fees to secure the network from both the supply shock of a halving, and keep the blockchain sustainable from both an economic and security perspective. A lot of the times when I try making a discussion around this "issue" (a non-issue in my opinion), the argument goes something like this:

1. For the network to remain secure, fee revenue needs to eventually make up the entire block reward as the subsidy tends towards 0 Bitcoins per block. This is especially important as the block reward exponentially decays by half every four years.

2. If fees are low (less than a penny), we would need an absurdly high amount of volume to generate the same amount of money in fees, and ridiculously large blocks, with an example to argue their point as follows:
   - BTC transaction revenue/block is $10.00/tx × 2,500 txs/block = $25,000 in fee revenue/block
   - Even at Visa/Mastercard level throughput, transaction fees of $0.001 (or anywhere around under a penny) will not be enough to subsidize the block reward, and collect more in fees, where: $0.001/tx × 1,000,000 txs/block = $1,000.00 in fee revenue/block (or $0.01/tx, which is $10,000 in fee revenue/block)
   - ∴ transaction volume has to be 25x greater than the mentioned volume above (1,000,000 txs/block), equating to a number of 25,000,000 txs/block or 3,600,000,000 txs/day, which is not even close to happening, and would require 10 GB blocks to work

3. Therefore, the entire economic model of high transaction throughput with lower fees is not only unsustainable, but also undesirable from both the perspective of profitability, economic sustainability, and security of the blockchain.

4. This means that only high fees are sustainable, and are the only way to secure the blockchain in a way that is economically sustainable, reliable, and desirable.

I think to some extent, even big-blockers have also fallen for this flawed argument (myself included, as illustrated in this reddit thread, and even this article I made a while ago discussing the fee revenue of Bitcoin [Cash] at scale). Many others have bought into the line of reasoning because at a surface level, it seems legit (it's so simple that often the details are overlooked as to why it is a flawed argument and doesn't hold ground when we actually understand how such an economy would work at scale if it were to do so).

Another potential example of a big-blocker unintentionally (or perhaps not, if it is an example) buying into this would be Rick Falkvinge, where he details an example of how low transaction fees and high volume would work on Bitcoin at scale. I think he really hits the nail on the head when he explains why a pre-mature "fee-market" on Bitcoin is an inappropriate solution to something that is currently a non-issue when he discusses and mentions a quote from a book called The Art of Computer Science by Donald Knuth:

Premature optimization is the root of all evil

And I think this perfectly encompasses the view that I, along with many others have about the current "fee-market", or as Rick says it as it fundamentally is, a barrier to entry. This not only does not solve the problem, but it is like putting a dam in a river to stop the flow of water before we even know that flooding will be an issue to begin with. The functionality and usability of the system is compromised, and there is no additional realized benefit to running the system in this way. In fact, it might even have long-term consequences, both from the perspective of economics and security.

Anyways, I digress... Coming back to Rick's example of Bitcoin working at scale, his example, as he puts it, because he wants to answer the question by not answering it, goes something like this:

• SWIFT processes $5 trillion worth of transaction volume per day[3]

• We can assume an average transaction value of $10 (for the sake of argument)

• Only 1 out of every 100 transactions pays a fee

• That fee is only $0.01

Then it holds true that:

• Bitcoin will make $50 million in transaction revenue daily

• This is already much more than Bitcoin currently makes in transaction revenue through the block subsidy ($18,000,000 at the time of the video, and $32,000,000 right now)

While Rick makes it clear that this rough calculation is just an example "for fun", I think this gives way too much credit to the original view... Why? Because it makes it look like we will need an absurd amount of transaction volume to sustain the system and keep it going, which gives credit to the second part of the first argument. In his example, the assumption being made is that we will have 500 billion transactions happening daily on the blockchain. While this is possible if the blockchain gets lots of adoption, it certainly looks ridiculous in the near future, and it makes the actual argument look weaker than it really is. In this article, I'm going to break down why this is even less of a non-issue than even Rick points it out to be. I will be elaborating on each of these points:

1. Average transaction fees don't need to be $0.001, and we can see average fees of even 25 cents while Bitcoin is basically free to send

2. A genuine fee-market naturally puts a limit on the blocksize

3. There is a lot of time before the block subsidy runs out, so lower fees should be encouraged

4. Therefore, the design of bigger blocks are far better for ensuring sustainability in the economics and security of the blockchain

Now to get into each point:

Average transaction fees don't need to be $0.001, and we can see average fees of even 25 cents while Bitcoin is still almost free to send

A lot of the time, when I have seen arguments discussing the fees for individual transactions because people think the equation is as simple as taking a 250 byte transaction, multiplying it by the number of potential transactions in a given interval (such as a block, or a day), and then multiplying that number by an average transaction fee of $0.001 to get some small number in fee revenue. This doesn't work in terms of forming an argument against low fees, and higher transaction volume, because the argument itself is an oversimplified way of looking at how transactions (on the blockchain) would work in a larger economy. Right now, both Bitcoin Core AND Bitcoin Cash, the economy is pretty small, so we don't see very many large transactions in proportion to the "normal" ones.

If the economy of cryptocurrency grows, we absolutely will see much larger transactions taking place. Potentially those in the tens to hundreds of kilobytes for transactions that either have multiple inputs, multiple outputs, or even multiple inputs AND outputs. Why? Because such transactions are necessary and are inevitably going to happen when there are bigger merchants accepting cryptocurrencies for payments. For example, if a merchant is extremely popular, and is getting 2,500-3,000 transactions/purchases a day (let's assume a semi-large online retailer, who has to move their transactions daily to a multi-sig wallet that makes payments monthly), they will have transactions that are 300-500 KB in size. At current fee rates, that could be anywhere from $2-$20, depending on how urgently the merchant needs the transaction to be included into the next block. This is just a rough calculation, but it gives you an idea that with many merchants, average transactions sizes will be much larger, and therefore have a big impact on the average transaction fee.

This means that we could see fees of several dollars as the average transaction fee, but Bitcoins are still virtually free to send. I was curious as to how the distribution of payments might actually be at scale, so I looked at some statistics for payment processors, and how often merchants can get payments using a credit card. Here's what I found:

• All of the big credit card processors have 40-50 million merchants respectively

• There is a lot of overlap of merchants that accept all credit cards as a method of payment

• Payments on credit cards take roughly 1-3 business days to settle

Knowing this information, which is only relevant to the PoS use-case (which is only a fraction of all potential use-cases), I would have to make a few assumptions regarding how transactions would work in terms of size for PoS transactions. The assumptions I am making are that:

• The merchants almost completely overlap, making the total number of merchants accepting credit card payments 50 million

• All of the credit card companies cumulatively process 10,000 transactions per second, and therefore 864 million transactions per day (we will round it to 1 billion to make things easier)

• Diving the number of transactions per day (~1 billion), by the number of merchants gives us an average transaction count of 20 transactions per merchant daily

• Merchant payments are sent every 24 hours, and therefore fully settled

• 50 million merchant payments are settled daily with an average of 20 inputs, and 1 output per transaction, giving us an average payment size of 3 KB

• The average transaction fee per byte is $0.0002 or $0.20 per kilobyte, making a merchant payment pay $0.60 daily in fees

• Each customer payment gives a lower fee (due to it being less necessary to be included in the next block) of $0.000005, giving an average transaction fee of $0.001 for a 200 byte transaction

Using all of these assumptions, we can calculate the average fee for a transaction, including both our merchant AND customer transactions by multiplying the average fee for each type, and then returning the average value:

[(50,000,000 merchant payments × $0.60/payment)+(1,000,000,000 customer payments × $0.001/payment)]/1,050,000,000 total payments = ~$0.03 per transaction

As we can see, the average fee is a good amount per transaction, and this is just discussing the PoS use-case, which is just one of many. What we can conclude is that despite transaction fees being next to nothing for the customer making a payment, the average transaction fee is a few pennies for a transaction. This is only an example, but it gives us an idea how the economics of a blockchain might work at scale. When we account for other use-cases with large transactions such as:

• Cashfusion

• Dice games (an example would be satoshi dice)

• dividend payments

• Gambling (Poker, Blackjack, Roulette, etc.)

• DEXs

• Smart contract payments (such as Flipstarter)

• Large business transactions with hundreds or thousands of both inputs and outputs

• Transactions with additional data (OP codes, multisignature, escrow, etc.)

With these use-cases, all of the transaction fees add up, and the average transaction fee could potentially be much larger, even if normal transactions are still very cheap. What makes it brilliant is that as the velocity of network transactions increase, so do the number of inputs potential transactions might have, further increasing fee revenue.

A genuine fee-market naturally puts a limit on the blocksize, because there is a cost to accepting transactions and larger blocks

When it comes to the topic of low fees, people think that just because fees are low for individual transactions that spam will occur on the network, and that blocks will have to be terabytes in size to get any meaningful revenue in fees, which will result in mass centralization. This is generally a slippery-slope, and strawman argument that many in favour of small-blocks use to justify keeping the blocksize limit at 1 MB (SegWit too). A great example of this would be a speech by Andreas Antonopoulos, in which his justification for not increasing the blocksize goes as follows:

1. At the moment, Bitcoin produces a 1 MB block every 10 minutes, and there about 3 million people trying to get their transaction into that 1 MB block, and as a result, fees have gone up.

2. Fees are a market based system for deciding which transactions are worth doing, and which transactions are not worth doing.

3. A lot of people don't like this. They don't like this solution. They would rather go back to a time when Bitcoin's fees were either negligible, or fixed.

4. There needs to be a mechanism by which transactions are prioritized and considered worth putting in, and there are two ways of solving this problem: The first would be someone deciding which transactions are spam, and which ones are worthwhile.
   
   Inevitably, this person maybe a developer or group of developers who are writing code to prioritize transactions. This solution is undesirable because it gives power to a small group of people.
   
   The other solution would be to keep the "market-based" system by which transactions are limited through the blocksize limit, and only "non-spam" transactions can go through.

5. To accommodate growth, we can keep the blocksize limited, so fees need to be increased for a transaction not to count as spam, or the blocksize limit can be increased.

6. Blocksize limits would have to be increased accordingly with more adoption:
   
   1) Let's say that in 2 years, we have 30 million people using Bitcoin. So to maintain exactly the same level of fees we have today, we need a block that is 10 MB; one order of magnitude bigger.
   
   2) 5 years from that, Bitcoin gets really really successful, and we need to get 300 million people to use it. Now we need 100 MB blocks.
   
   3) 5 years from that, if Bitcoin and other technologies become astonishingly successful, we would need another order of magnitude to accommodate user. Now we're at gigabyte blocks, but it gets worse.
   
   4) If we want transactions to be faster and cheaper, so you need another order of magnitude increase, just to make it cheaper than today, so that is a 10 GB block to accommodate 3 billion people.
   
   5) But then we want people to use it as day-to-day currency, and use it like cash. Instead of 5 transactions a month, they want to do 50 transactions a month, and now you've got 100 GB blocks.
   
   6) Even 100 GB blocks are pointless, because it only accommodates cash as a use-case. For small transactions to also be accommodated, we would need an order of magnitude increase, another order of magnitude increase for microtransactions, and then an additional order of magnitude increase for nanotransactions. This would mean petabyte blocks, therefore increasing the blocksize limit is not a solution.
   
   There is another variation of this argument that follows:
   
   - For 1 million people to make 5 transactions per month, we would need 500 KB blocks
   - For 10 million people to make 5 transactions per month, we would need 5 MB blocks
   - For 10 million people to make 50 transactions per month, we would need 50 MB blocks
   - For 100 million people to make 50 transactions per month, we would need 500 MB blocks
   ... And so on

7. Therefore increasing the blocksize cannot be a solution, and it is a game we cannot win.

The essence of the argument here is that we would need petabyte blocks to accommodate global adoption, therefore we shouldn't increase the blocksize limit AT ALL. It's an absurd argument because it suggests that we shouldn't even bother putting a "temporary solution" unless and until we get a permanent one, despite the fact that preventing a temporary solution makes the issue worse, not that the premise itself is correct to begin with. Just to illustrate how ridiculous this is, here's an example:

1. Let's say your son/daughter has a disease that is terminal and will kill them in a matter of a few months. They are potentially on their death bed.

2. The cure for the disease is still being discovered, and might take a few months more than the day they die. There is no guarantee that it will save them, but there is a chance it could. The hospital you are in is working on the cure for said disease.

3. There is a temporary solution that will buy your kid more time, and there is enough to keep them alive for said timeframe, potentially allowing for them to have access to the cure when it comes out, saving them (if it works).

4. The only issue with this temporary solution is that every time a dose is taken, it has to issued at a regular interval (weekly), which costs resources and is less effective over time, which is why it can only buy a few more months of time. Additionally, this will add another $5,000 to your hospital bill.

5. Your doctor argues that since no cure is ready or exists right now, you shouldn't take the temporary solution either because "it's a game [you] can't win", and that you should allow your kid to die.

6. Your kid dies.

After you're done with the hospital, the doctor hands you a $100k bill. Do you happily pay for it and applaud the doctor for "technological innovation" and not taking "the easy solution"? Do you also continue to think to yourself gee, it sure sucks that my kid died, but at least I'm not going to have fun staying poor because my hospital bill is cheaper.

It illustrates how stupid the argument of keeping the blocksize limited to a ridiculously small amount is because it shows a belief that it is worth the cost of stalling, and potentially even harming adoption, or even killing Bitcoin long-term just so that some potential user can run a full-node (of which they have no financial or general incentive to do so), meaning that Bitcoin is "decentralized". I also want to address the fact that the slippery slope argument does NOT in any way justify keeping the blocksize to 1 MB. It is a non-answer that is frustrating to argue with because it still doesn't justify keeping the limit.

Getting to the topic of fee-markets, what's happening on BTC is not a fee-market. It is an artificial barrier to entry. In fact, it is potentially a bad thing, because it prevents economic activity from actually happening on the network. This is a term in economics known as a deadweight loss. Both Bitcoin Out Loud (John Moriarty), and Peter Rizun make great videos on this discussing the issue of preventing a free-market equilibrium through small blocks, and how allowing for bigger blocks allows a free market equilibrium to take place. I won't get into the full details, but here's the run-down:

There is a cost to making bigger blocks, and propagating them across the network (as blocks get bigger, each transaction (as a part of the block) costs more to include). This cost naturally puts a limit on the blocksize if miners want to maximize their revenue.

As someone who has some knowledge in economics, I find myself agreeing with this perspective because the cost of a block potentially being orphaned is an idea in microeconomics known as the marginal cost of producing a good. When talking about marginal costs, they specifically are defined as:

The change in total production cost that comes from making or producing one additional unit [of a good]

Additionally, transaction fees are the incentive to include a transaction in the next block, which is otherwise known in economic terms as marginal revenue, which is defined as:

The revenue gained by producing one additional unit of a good or service.

With this in mind, we know that:

1. There is a cost to including additional transactions in a block, which increases as blocks get bigger

2. There is revenue (marginal revenue) made from each transaction paying a fee.

Therefore, it holds true that:

If a miner wants to maximize their profit, they will keep supplying blockspace to include transactions in their blocks until the marginal revenue (transaction fee) is equal to the cost of including a transaction into the next block. Given that there is a limit, as including more transactions burdens an additional cost in terms of block orphaning, while transaction fees remain flat, there is a natural limit to how big a miner can make a block until it is unprofitable to do so. Therefore, the blocksize won't be unlimited even if the limit itself is.

If we want to demonstrate this relationship, we can do so by measuring how orphan rate increases with the size of blocks, and what it costs to include a transaction into a given block. Reddit user u/phillipsjk does a great job of this with his post Estimating the marginal cost of a transaction on the Bitcoin (Cash) network. He goes into detail about all the costs involved in accepting a transaction into a block, and does a great in-depth analysis on how much it would cost to accept a transaction into the next block. The only issues with this model is that it doesn't factor in is the cost of block orphaning when a miner makes a block that is "too big", and it assumes VERY large blocks (8 GB). I can and will potentially calculate this if I can understand the equations for block orphaning probability and missed out revenue.

I don't know the equations for both block orphaning rates, and the cost to accept more data, but what I can assume (from the economic incentives) is that the rate of change (or slope/derivative) at which bigger blocks become more expensive to propagate increases... How do I know this? I know this because revenue (not profit) has to be a linear equation due to block revenue being a direct product of the fee per byte of block space, and therefore the slope is constant. For the marginal revenue to approach the marginal cost (and therefore the profit for an additional n bytes of data to also be $0) and be profitable before such a limit is reached, the equation for how 'expensive' a bigger block becomes to propagate has to have an increasing rate of change.

To model both the cost of propagating a block, and the revenue a given miner will get from accepting x bytes of data, I've made a graph. Let f(x) be the expense of propagating a given block, while g(x) is the revenue collected from fees (this is a very oversimplified because it doesn't take into account the coinbase reward/subsidy, and doesn't take fully into account the bidding that would be happening in the mempool, and instead assumes a flat linear fee):

As we can see, for bo th graphs, there is no gap at the beginning, where the block itself is empty. The miner is getting 0 revenue from fees, and is mining an empty block. As the miner includes more fees, they get more revenue. Notice the gap between the two functions? That is the profit a miner is getting for including x bytes of data. That represents the total profit from mining the block. We can subtract the expenses from the revenue to the the function of profit. The result is this:

If you look at the graph, you can see that bigger blocks in mining are more profitable to a point, but after that, it becomes a situation of diminishing, and even negative returns if the block is large enough for it to either be more expensive to include another transaction, or big enough to be orphaned, and the block reward not go to the miner in favour of a smaller block that propagated relatively quickly. This proves that there is a limit in reality for miners to make blocks bigger, and having no blocksize limit, or effectively no blocksize limit allows individual miners to set their own limits and maximize the profitability of mining blocks, thereby giving a better security model for Bitcoin. Not allowing miners to set their own blocksize limits (because of a quota that is well below how much can yield the maximum profit), will lead to a worse long-term security model because miners will no longer be able to make the best economic decisions when it comes to mining, making the entire system potentially unsustainable.

There is a lot of time before the block subsidy runs out, so lower fees should be encouraged

A lot of people seem to be extremely worried that Bitcoin's block reward halves about every 4 years. While the supply shock itself is an issue, it becomes less of an issue as fees make up a bigger percentage of the block reward. A common response to the issue of transaction fees making up a small percentage of the block reward is that "there is 120 years until the block subsidy runs out". Many people on the small block side of the debate do not consider this point because in some way, it does sound ridiculous because the economic consequences of a decreasing block reward are going to be felt way before the 120 year "deadline". Both points are correct. I find myself siding more in favour of the argument that we have 120 years for the block reward to run out because:

1. A fee market exists even without a hard cap on blocksizes

2. The growth for Bitcoin to sustain while still retaining value after every block reward halving is extremely sustainable, and can go on for a very long time.

We've covered the first point before, so I will be talking about the second one. Bitcoin's block reward started at 50 Bitcoins per block, and halved roughly every 4 years. Since we have gone through three halvings, the current block reward is only 6.25 Bitcoins per block. With this in mind, this means that Bitcoin itself has to double in value every 4 years just so the block reward can retain its value. It seems extremely difficult since exponential growth on its own is very unsustainable. While this will be true after a long amount of time, it won't be true for at least the foreseeable future. Here's some information just off the top of my head:

• Over the last 8 years, Facebook has grown at an average rate of 31.5% per year

• Over the last 12 years, eBay has grown at an average rate of 21.8% per year

• Over the last 10 years, Microsoft has grown at an average rate of 24.4% per year

• Over the last 10 years, Google has grown at an average rate of 21.0% per year

• Over the last 10 years, Amazon has grown at a rate of 34.2% per year

Now what does this have to do with Bitcoin? These are stocks in a regulated market with high liquidity, and they have increased in value by more than enough to offset any potential value lost by the block reward halving. For Bitcoin's block reward to retain value, it only needs to grow by more than 18.92% per year on average. To add to this, from 2012-2017, when the blocksize limit wasn't an issue, Bitcoin's transaction count doubled every year on average (actually even more, but this is a rough number). We can take this information, and model it to show how rewards can gradually make up more of the block reward while fees still remain low, and halvings are basically a non-issue. To model this, I will have to make a few assumptions:

• We are starting at genesis block on January 1st, 2010 (this is for the sake of simplicity, and giving us a round number to start with)

• Block reward halvings are exactly every 4 years, starting from 50 BTC per block

• There are 1,000 transactions on the day of the genesis block, and the daily transaction count doubles every year for the next 12 years, then 50% per year for the next 12, 25% for the next 12, and so on...

• The average transaction fee is $0.01

• The BTC price (assuming it continues growing because it gets more users and can scale) can be modelled by this equation:
  

  

  The given equation assumes a daily compounded return of 0.22% per day for the first decade, then 0.11% for the next one, 0.055% for the one after that, and so on...
  
  The reason I made this equation myself was because I wanted to come up with something that is accurate in portraying the eventual plateau in price for Bitcoins (if they become THE currency for people to use, assuming deflationary economics don't harm it). It's also especially good in reflecting the potential price performance of Bitcoin because it is partially based on my previous function of transaction growth (but the increase halving every decade instead of 12 years or 3 halvings), and it is in big-part based on Hal Finney's email correspondence where he calculates Bitcoin being worth $10 million per coin if it takes over the entire world economy. My function doesn't come close to that number until at least 75 years have passed by from the genesis block.

• Inflation is already priced in

• This price projection will continue indefinitely

With all of these assumptions, we come up with a few models for both Bitcoin's block reward, AND how sustainable fees are. I will make sure to add all of the files in a folder and share them so people can potentially take a look or make changes if needed to make the models more accurate.

To start, we can take a look at the block reward subsidy, and how it is affected after halvings. To do this, I multiplied the price by the block subsidy based on the number of years that have passed:

From this graph, we can see that the block reward subsidy only really becomes an issue and starts reducing significantly (and is unable to sustain) around 2045. That's a little bit less than 25 years from now, which is still a long time for the block reward to be subsidized. However, after 2045, it becomes a pretty big issue because the system absolutely needs to be sustainable by then unless Bitcoin happens to be less valuable per coin than the projected growth. Prematurely optimizing for this can have potentially severe economic consequences.

With our growth, we have assumed that Bitcoin transaction fees are $0.01 on average, starting with 1,000 transactions on the day of the launch (genesis), doubling at a rate of every year for twelve years, then increasing 1.5 times for the next 12, and so on. With this rate of growth, we see about 68 billion transactions by 2140, or the time when the block reward becomes 0 because of rounding. This is a realistic amount because the world population will be somewhere around 12,000,000,000 by then, meaning that the activity on the blockchain would be 5-6 transactions per person, per day, worldwide. When we add the total transaction fees with the subsidy, we get this graph:

Here is a linear scale of the same graph for comparison:

So the fees increase enough to compensate for any potential supply shock caused by the halvings. At first, there is quite a bit of volatility, but after a point, the halvings have next to no effect.

Bigger Blocks Ensure a Sustainable Economic and Security Model for Bitcoin

With all of this in mind, I think it goes to say that allowing for bigger-blocks leads to a better economic (and therefore) security model long term.

Note: I will make sure to add all of my files afterwards. I just need to get them together.