Crypto 360°

Saturday, 8 September 2018

Bitcoin Cash BCH - North Queensland Style

submitted by /u/where-is-satoshi
[link] [comments]

source https://www.reddit.com/r/btc/comments/9e28ib/bitcoin_cash_bch_north_queensland_style/

A (hopefully mathematically neutral) comparison of Lightning network fees to Bitcoin Cash on-chain fees.

A side note before I begin

For context, earlier today, /u/sherlocoin made a post on this sub asking if Lightning Network transactions are cheaper than on-chain BCH transactions. This user also went on to complain on /r/bitcoin that his "real" numbers were getting downvoted

I was initially going to respond to his post, but after I typed some of my response, I realized it is relevant to a wider Bitcoin audience and the level of analysis done warranted a new post. This wound up being the longest post I've ever written, so I hope you agree.

I've placed the TL;DR at the top and bottom for the simple reason that you need to prepare your face... because it's about to get hit with a formidable wall of text.

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 1sat/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 1sat/byte.

Let's Begin With An Ideal World

Lightning network fees themselves are indeed cheaper than Bitcoin Cash fees, but in order to get to a state where a Lightning network 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 1sat/byte so for now, we'll assume that ideal scenario of 1sat/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. The total fee for an ideal open/close transaction is 1.8¢

For comparison, a simple transaction on the BCH network requires 226 bytes one time. The minimum fee accepted next-block is 1sat/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

Compounding Factors

Our world is not ideal, so below I've listed compounding factors, common arguments, an assessment, and whether the problem is solvable.

Problem 1: Bitcoin and Bitcoin Cash prices are asymmetrical.

Common arguments:

BTC: If Bitcoin Cash had the same price, the fees would be far higher

Yes, this is true. If Bitcoin Cash had the same market price as Bitcoin, our ideal scenario changes substantially. An open and close on Bitcoin 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 1sat for every 10 bytes, and that amount can be made lower by later proposals. While there is no substantial pressure to implement this now, if Bitcoin Cash had the same usage as Bitcoin currently does, it is far more likely to be implemented. If implemented at the first proposed reduction rate, under ideal circumstances, a Lightning Channel would need to produce around 13 transactions for the new break even.

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 micropaments. 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 lowes 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 1sat/byte fees

Common arguments:

BCH: If you tried to open a channel at peak fees, you could pay $50 each way

BTC: LN wasn't implemented which is why the fees are low now

Both sides have points here. It's true that if the mempool was in the same state as it was in December of 2017, that 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, and an overall cooling of the market.

I'm not going to speculate as to what percentage of which is due to each factor. Instead, I'm going to simply analyze mempool statistics for the last few months where both factors are present.

Let's get an idea of current typical Bitcoin network usage fees by asking Johoe quick what the mempool looks like.

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. Weekly, usage usually peaks on Tuesday or Wednesday with enough activity to fill blocks with at least minimum fee transactions M-F during the noted hours and usually just shy of block-filling capacity on Sat and Sun.

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 1sat/byte rate. The primary issue arises in situations where either 1) LN payments are accepted and you had little prior knowledge, or 2) 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:

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

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

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.

I don't mean to dismiss either argument, but option C opens a can of worms that alone 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 crypto.

With option B, you would absolutely need to pay the peak rate (likely higher) for a single transaction as a Point-of-Sale scenario with a full mempool would likely require at least one confirm and both parties would want that as soon as possible after payment. It would not be unlikely to pay 20-40 sat/byte on a single transaction and then pay 1sat/byte for an open and close to enable LN payments later. Even in the low end, the total cost is 20¢ for on-chain + open + close.

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

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

In closing, 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 and the software automatically calculates fees based on current rates. If this is the 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 / Segwit utilization, or increase on-chain capacity. If it gets to a point where transactions stack up, users will be required to pay more than 1sat/byte per transaction and should expect as much.

Current Bitcoin network utilization is close enough to 100% to fill blocks during peak times. I also did an export of the data available at Blockchair.com for the last 3000 blocks which is approximately the last 3 weeks of data. According to their block-weight statistics, 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.

Common arguments:

BCH: You can get into a scenario where you don't have output capacity and need to open a new channel.

BCH: A hostile actor can cause you to lose funds during a high-fee situation where a close is forced.

BTC: You can easily re-load your channel by pushing outbound to inbound.

BCH: You can't control whether nodes you connect to are online or offline.

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 as of right now, but connected 3rd-parties can affect the state of this contract. There are some interesting scenarios that develop because of it and you aren't always in full control of what side.

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 0 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. I've seen proposals like using Bitrefill to push capacity back to your node. In order to do this, you would 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, I don't think this alone is a horrible solution to the LN outbound capacity problem... Although it depends on the fee that bitrefill charges to maintain an account and account charges could negate the effectiveness of using the LN. Still, we will assume this is a 0 on-chain scenario and would only cost 1 LN fee which remains relatively negligible.

If no network loop exists from you 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 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.

Hostile actors

There are some potential attack vectors previously proposed. Most of these are theoretical and/or require high fee scenarios to come about. I think that everyone should be wary of them, however I'm going to ignore most of them again for the sake of succinctness.

This is not to be dismissive... it's just because my post length has already bored most casual readers half to death and I don't want to be responsible for finishing the job.

Pushing outbound to inbound

While I've discussed scenarios for this push above, there are some strange scenarios that arise where pushing outbound to inbound is not possible and even some scenarios where a 3rd party drains your outbound capacity before you can spend it.

A while back I did a testnet simulation to prove that this scenario can and will happen it was a post response that happened 2 weeks after the initial post so it flew heavily under the radar, but the proof is there.

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.

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 pathfinding algorithm so 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... but...

Problem 4: Lightning Network is not infinite.

Common arguments:

BTC: Lightning network can scale infinitely so there's no problem.

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

Note - in the above I confused the complexity of the traveling salesman problem with Dijkstra when they do not have the same bound. With that being said, the complexity of the LN will still diverge with size

In lay terms, what that means is 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?

Signs point to 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.

In fact SHA256 is a newer NP-hard problem than the traveling saleseman problem. That means that statistically, and based on the amount of review that has been given to each problem, it is more likely that SHA256 - the algorithm that lends security to all of bitcoin - is cracked before the traveling salesman problem is. Notions that "a dedicated dev team can suddenly solve this problem, while not technically impossible, border on statistically absurd.

Edit - 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 it's 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, I'd like to add, 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 (as far as I can tell) on-chain transactions (very likely) scale more effectively than Lightning Network in its current state.

Additional notes:

My computational difficulty assumptions were based on a generalized, but similar problem set for both LN and on-chain instances. I may have overlooked additional steps needed for the specific implementation, and I may have overlooked reasons a problem is a simplified version requiring reduced computational difficulty.

I would appreciate review and comment on my assumptions for computational difficulty and will happily correct said assumptions if reasonable evidence is given that a problem doesn't adhere to listed computational difficulty.

Further, the Lightning network can provide no guarantee in its current state to maintain/reduce fees to 1sat/byte.

submitted by /u/CaptainPatent
[link] [comments]

source https://www.reddit.com/r/btc/comments/9dx24f/a_hopefully_mathematically_neutral_comparison_of/