Bitcoin Vs Bitcoin Cash Scaling: Why Lightning Network is More Expensive than Bitcoin Cash

0 Shares

This article is a Bitcoin vs Bitcoin Cash scaling comparison that takes a look at why transactions on the Lightning Network is more expensive than Bitcoin Cash transactions.

TL;DR: While Lightning node payments themselves cost less than on-chain BCH payments, the associated overhead currently requires a LN channel to produce 16 transactions just to break-even under ideal 1 sat/byte circumstances and substantially more as the fee rate goes up. Further, the Lightning network can provide no guarantee in its current state to maintain/reduce fees to 1 sat/byte.

Let's Begin With An Ideal World

Lightning network fees themselves are indeed cheaper than Bitcoin Cash (BCH) fees, but in order to get to a state where a Lightning Network (LN) fee can be made, you are required to open a channel, and to get to a state where those funds are spendable, you must close that channel.

On the Bitcoin network, the minimum accepted fee is 1 1 sat/byte so for now, we'll assume that ideal scenario of 1 sat/byte. We'll also assume the open and close is sent as a simple native Segwit transaction with a weighted size of 141 bytes. Because we have to both open and close, this 141 byte fee will be incurred twice. Here’s the calculation:

The total fee for an ideal open/close (of using Lightning Network) transaction is 1.8¢.

For comparison, a simple transaction on the BCH network requires 226 bytes. The minimum fee accepted in the next block is 1 sat/byte. At the time of writing an ideal BCH transaction fee costs ~ 0.11¢

This means that under idealized circumstances, you must currently make at least 16 transactions on a LN channel to break-even with fees.

(See more: Guide to Blockchain Scalability: Bitcoin Scalability Problem and Effects)

Compounding Factors

Our world is not ideal, therefore, here is a list of compounding factors, common arguments, an assessment, and whether the problem is solvable to begin with.

Problem 1: Bitcoin and Bitcoin Cash prices are Asymmetrical

Yes, this is true. If Bitcoin Cash had the same market price as Bitcoin, our ideal scenario changes substantially. An open and close on the Bitcoin network still costs 1.8¢ while a simple Bitcoin Cash transaction now costs 1.4¢. The break-even point for a Lightning Channel is now only 2 transactions.

Is this problem solvable?

Absolutely.

Bitcoin Cash has already proposed a reduction in fees to 1 sat for every 10 bytes, and that amount can be made lower by later proposals. While there is no substantial pressure to implement this now, it is far more likely to be implemented once Bitcoin Cash reaches the same network usage as Bitcoin currently does. If implemented at the first proposed reduction rate – under ideal circumstances – Lightning Channel would need to produce around 13 transactions for the new break-even point.

But couldn't Bitcoin reduce fees similarly?

The answer there is really tricky. If you reduce on-chain fees, you reduce the incentive to use the Lightning Network as the network becomes more hospitable to micropayments. This would likely increase the typical mempool state and decrease the Lightning Channel count some. The upside is that when the mempool saturates with low transaction fees, users are then re-incentivized to use the lightning network after the lowest fees are saturated with transactions. This should, in theory, produce some level of a transaction fee floor which is probably higher on average than 0.1 sat/byte on the BTC network.

Problem 2: This isn't an Ideal World, We Can't Assume 1 sat/byte Fees

Both sides have points here. It's true that if the mempool was in the same state as it was in December of 2017, a user could have potentially been incentivized to pay an open and close channel fee of up to 1000 sat/byte to be accepted in a reasonable time-frame.

With that being said, two factors have resulted in a reduced mempool size of Bitcoin:

Increased Segwit and Lightning Network Usage
Overall cooling of the market

Instead of speculating as to what percentage of which is due to each factor, let’s analyse the mempool statistics for the last few months where both factors are present. We can get an idea of current typical Bitcoin network usage fees by looking at Bitcoin’s mempool:

For the last few months, the bitcoin mempool has followed almost the exact same pattern. Highest usage happens between 10AM and 3PM EST with a peak around noon. On the weekly horizon, usage usually peaks on Tuesday or Wednesday with enough activity to fill blocks with the least minimum fee transactions from Monday to Friday during the noted hours and usually just shy of block-filling capacity on Saturday and Sunday.

These observations can be additionally evidenced by transaction counts on bitinfocharts. It's also easier to visualize on bitinfocharts over a longer time-frame.

Opening a Channel

Under pre-planned circumstances, you can offload channel creation to off-peak hours and maintain a 1 sat/byte rate. The primary issue arises in situations where either:

LN payments are accepted and you had little prior knowledge, or
You had a previous LN pathway to a known payment processor and one or more previously known intermediaries are offline or otherwise unresponsive causing the payment to fail

Your options are:

Option A: Create a new LN channel on-the-spot where you're likely to incur current peak fee rates of 5-20 sat/byte.

Option B: Create an on-chain payment this time and open a LN channel when fees are more reasonable.

Option C: Use an alternate currency for the transaction.

There is a fundamental divide among the status of C. Some people view Bitcoin as (primarily) a storage of value, and thus, as long as there are some available onramps and offramps, the currency will hold value. There are other people who believe that fungibility is what gives cryptocurrency it's value and that option C would fundamentally undermine the value of the currency.

This is not meant to dismiss either argument, but option C opens a can of worms that can fill economic textbooks. For the sake of simplicity, we will throw out option C as a possibility and save that debate for another day. We will simply require that payment is made in cryptocurrency. It is important to understand the differences between a cryptocurrency coin and a token.

With option B, you would absolutely need to pay the peak rate (likely higher) for a single transaction as a Point-of-Sale scenario. A full mempool would likely also require at least one confirmation which would be required by both parties after payment. It would not be unlikely to pay 20-40 sat/byte on a single transaction and then pay 1 sat/byte to open and close LN channels for later payments. Even at the low end, the total cost is 20¢ for on-chain transaction together with opening and closing an LN channel.

With present-day-statistics, your LN would have to process 182 transactions to make up for the one peak on-chain transaction you were forced to do.

With option A, you still require one confirmation. Let's also give the additional leeway that in this scenario, you have time to sit and wait a couple of blocks for your confirmation before you order or pay. You can thus pay peak rates alone. This will most likely be in the 5-20 sat/byte range. With 5 sat/byte to open and 1 sat/byte close an LN channel, your LN transaction would have to do 50 transactions to break even.

With regards to closing the channel, fees are incurred by the funding channel so there could be scenarios where the receiving party is incentivized to close in order to spend outputs. The software will then automatically calculate fees based on current rates. In this case, the receiving party could incur a higher-than-planned fee to the funding party.

With that being said, any software that allows the funding party to set the fee beforehand would avoid unplanned fees, so we'll assume low fees for closing.

Is this problem solvable?

It depends.

In order to avoid the peak-fee open/close ratio problem, the Bitcoin network either needs to have much higher LN or Segwit utilization, or to increase on-chain capacity. If it gets to a point where transactions stack up, users will be required to pay more than 1 sat/byte per transaction and this should be expected.

Currently, the Bitcoin network utilization is close enough to 100% to fill blocks during peak times. An analysis of the last 3,000 blocks found that the average Bitcoin block is 65.95% full. This means that on-chain, Bitcoin can only increase in transaction volume by around 50% and all other scaling must happen via increased Segwit and LN use.

Problem 3: You Don't Fully Control Your LN Channel States

There's a lot to digest here, but LN is essentially a 2-way contract between 2 parties. Not only does the drafting party pay the fees instantaneously, connected 3rd-parties can also affect the state of this contract. There are some interesting scenarios that has developed because of it and you aren't always in full control.

1. Lack of Outbound Capacity

First, it's true that if you run out of outbound capacity, you either need to reload or create a new channel. This could potentially require 0, 1, or 2 additional on-chain transactions.

If a network loop exists between a low-outbound-capacity channel and yourself, you could push transactional capacity through the loop back to the output you wish to spend to. This would require zero on-chain transactions and would only cost 1 (relatively negligible) LN fee charge. For all intents and purposes, this is actually kind of a cool scenario.

If no network loop exists from you-to-you, things get more complex. There are proposals such as using Bitrefill to push capacity back to your node. In order to do this, you would need to have an account with them and they would lend custodial support based on your account. While people opting for trustless money would take issue in 3rd party custodians, this alone isn’t a horrible solution to the LN outbound capacity problem. However, the fees that Bitrefill charges to maintain an account charges could negate the effectiveness of using the LN. Still, we will assume this is an on-chain scenario and it would only cost 1 LN fee, which remains relatively negligible.

If no network loop exists from and you don't have a refill service set up, you'll need at least one on-chain payment to another LN entity in exchange for them to push LN capacity to you. Let's assume the ideal fee rates. If this is the case, your refill would require an additional 7 transactions for that channel's new break-even. Multiply that by number of sat/byte if you have to pay more.

Opening a new channel is the last possibility and we go back to the dynamics of 13 transactions per LN channel in the ideal scenario.

2. Hostile Actors

There are some potential attack vectors previously proposed. Most of these are theoretical and/or require high fee scenarios to come about.

3. Pushing Outbound to Inbound

While scenarios were discussed for this push above, there are some strange scenarios that arise where pushing outbound to inbound isn’t possible. There are even some scenarios where a 3rd party drains your outbound capacity before you can spend it.

A testnet simulation was conducted on the viability of this scenario and there was credible proof that it can occur.

The moral of this story is in some scenarios, you can't count on loaded network capacity to be there by the time you want to spend it.

4. Online vs Offline Nodes

We can't even be sure that a given computer is online to sign a channel open or push capacity until we try. Offline nodes provide a brick-wall in the path-finding algorithm. Therefore, an alternate route must be found. If we have enough channel connectivity to be statistically sure we can route around this issue, we're in good shape. If not, we're going to have issues.

Is this problem solvable?

Only if the Lightning network can provide an (effectively) infinite amount of capacity. However, it comes with several limitations.

Problem 4: Lightning Network is Not Infinite

Unfortunately, LN is not infinitely scalable. In fact, finding a pathway from one node to another is roughly the same problem as Dijkstra's algorithm, which is a problem that diverges polynomially. The most efficient proposals have a difficulty bound by O(n^2).

In lay terms, what this means is that every time you double the size of the Lightning Network, finding an indirect LN pathway becomes 4 times as difficult and data intensive. This means that for every doubling, the amount of traffic resulting from a single request also quadruples.

You can potentially temporarily mitigate traffic by bounding the number of hops taken, but that would encourage a greater channel-per-user ratio.

For a famous example, the game “6 degrees of Kevin Bacon” postulates that Kevin Bacon can be connected by co-stars to any movie by 6 degrees of separation. If the game is reduced to “4 degrees of Kevin Bacon,” users of this network would still want as many connections to be made, so they'd be incentivized to hire Kevin Bacon to star in everything. You'd start to see ridiculous mash-ups and reboots just to get more connectivity. Just imagine hearing Coming soon – Kevin Bacon and Adam Sandlar star in “Billy Madison 2: Replace the face.”

Is this problem solvable?

This points to a ‘NO’.

So technically, if the average computational power and network connectivity can handle the problem (the number of Lightning network channels needed to connect the world) in a trivial amount of time, Lightning Network is effectively infinite as the upper bound of a non-infinite earth would limit time-frames to those that are computationally feasible.

With that being said, BTC has discussed Lightning dev comments before that estimated a cap of 10,000 – 1,000,000 channels before problems are encountered which is far less than the required “number of channels needed to connect the world” level.

While the case isn't quite as bad as the traveling salesman problem, the problem will still diverge with size and finding a more efficient algorithm is nearly as unlikely.

This upper bound shows that we cannot count on infinite scalability or connectivity for the lightning network. Thus, there will always be on-chain fee pressure and it will rise as the LN reaches its computational upper-bound.

Because you can't count on channel states, the on-chain fee pressure will cause typical sat/byte fees to raise. The higher this rate, the more transactions you have to make for a Lightning payment open/close operation to pay for itself.

This is, of course unless it is substantially reworked or substituted for a O(log(n))-or-better solution.

Finally, it must be pointed out that creating an on-chain transaction is a set non-recursive, non-looping function – effectively O(1), sending this transaction over a peer-to-peer network is bounded by O(log(n)) and accepting payment is, again, O(1). This means that on-chain transactions (very likely) scale more effectively than Lightning Network in its current state.

Additional Notes:

The computational difficulty assumptions were based on a generalized, but similar problem set for both LN and on-chain instances. Additional steps needed for the specific implementation may have been overlooked. Reviews and comment on the assumptions used for computational difficulty is more than welcome and will happily be corrected if reasonable evidence is given that a problem doesn't adhere to listed computational difficulty.

You might also be interested in: Guide to Open Source: Importance of Open Source Technology in Cryptocurrency.

Beneficial Resources To Get You Started

If you're starting your journey into the complex world of cryptocurrencies, here's a list of useful resources and guides that will get you on your way:

Trading& Exchange

Wallets

Enroll in our Free Cryptocurrency Webinar now to learn everything you need to know about crypto investing.

Get our exclusive e-book which will guide you on the step-by-step process to get started with making money via Cryptocurrency investments!

You can also join our Facebook group at Master The Crypto: Advanced Cryptocurrency Knowledge to ask any questions regarding cryptos!

CaptainPatent

Bitcoin vs. Bitcoin Cash: What’s the difference?

Let's Begin With An Ideal World

Compounding Factors

Problem 1: Bitcoin and Bitcoin Cash prices are Asymmetrical

Problem 2: This isn't an Ideal World, We Can't Assume 1 sat/byte Fees