# How Splices Impact Lightning Network Fees

In previous posts we have discussed how an intermediate node, Carol, routes payments between Alice and Bob. In order to route payments, Carol must have her channels funded in advance. This implies occasionally rebalancing her payment channels.

There are at least three possible ways of rebalancing: circular payments, fee management and splices. Perhaps the most important difference between them is that, while circular payments and fee management redistribute payment capacity among different paths, splices can actually change the payment capacity of the network. Also, unlike circular payments or fee management, splices work well even in a poorly connected or poorly funded network. For the purpose of this post **we’ll consider Carol uses splices to rebalance her channels.**

There are at least two costs involved in routing payments: the operational costs of opening and closing channels and the financial costs of having money locked in. Carol will attempt to cover the costs of routing these payments by charging fees. **Studying the way nodes manage costs is crucial, since it reveals how fees will be in the Lightning Network.**

To better understand this article, you should be familiar with the basics of payment channels and the Lightning Network. If you are not, we highly recommend reading this post first.

### Operational Costs and Fees

Every time Carol routes a payment, her balance in the sender’s channel increases by the amount transacted and her balance in the receiver’s channel decreases by the same amount. Over time, routing payments tends to unbalance Carol’s channels.

Eventually, Carol will have insufficient money in a channel to route a payment, and will need to redistribute her funds. She will do this using splices, that imply broadcasting Bitcoin transactions and paying for on-chain fees, thus incurring in operational costs.

Carol needs to find a way to cover these costs, and every time she routes a payment is an opportunity to charge a fee. **The total sum of these fees should cover the costs of rebalancing her channels.**

But, how much should Carol charge for each routed payment? To answer this, she first needs to know the average number of payments that can go through a channel before it gets depleted.

Carol could then decide to treat all payments equally and charge a constant fee per routed payment. However, this would disregard an important fact: some payments tend to unbalance her channels faster than others.

### Model

We’ll model a random process to understand what determines the average number of payments that can go through a channel before it gets depleted. We’ll call this variable *N*.

Just as before, Alice and Bob want to transact with each other using Carol as an intermediate node. Three factors determine the value *N* of each channel:

- The amount of money Carol commits to them. The higher this amount, the longer it will take for the channel to get depleted. In this model, Carol will commit
*a*BTC to each channel. - The amounts being transacted. Big payments tend to unbalance channels, shortening their lifetime. For simplicity, we’ll assume all payments equal to
*z*BTC and see what happens for different values of*z*. - The flow of payments between Alice and Bob. Payments travelling in opposite directions can cancel each other out, at least partially. So, Carol’s channels will get depleted faster if only Alice makes payments. In this model, Alice will pay Bob with probability
*p*and Bob will pay Alice with probability*1 — p*.

To summarize, in each step either Alice or Bob will make a payment of *z* BTC. The probability of being the sender of the payment is *p *for Alice and *1 — p* for Bob. Carol’s initial balance in both channels is *a *and we’ll do this until one of her channels gets depleted.

Let’s see how different values of *p *affects the dependency of *N *on *a *and *z*.

### Alice always pays Bob

In this case all payments go in one direction, which means *p = 1*. This could be the case where Bob is a merchant. The case where *p = 0* is analogous.

The number of payments Alice can make before Bob’s channel gets depleted is:

The bigger the payments are, the shorter the lifetime of Bob’s channel is. Also, if Carol commits more money to her channels, they will last longer.

### Alice and Bob act the same

In this setting, Alice and Bob make payments with equal probability, that is, *p=1/2*. Channels have longer lifetimes than when *p = 1* or *p = 0* as payments going in opposite directions cancel each other out. Such a perfectly unbiased behaviour is very unrealistic, but it helps our analysis.

By applying probability theory, we know that the average number of payments Alice and Bob will make before one of the channels is depleted is:

Note that in this case routing bigger payments risks more frequent rebalancing.

Let’s see this in an example. If *z = 1* the average number of payments Bob and Alice will make before one of the channels is depleted is *a² *while if *z = a* the number of payments will be exactly *1*.

### Alice and Bob behave realistically

In a realistic peer-to-peer network, *p* will be different from *0*, *1* and *1/2*. This means either Alice or Bob will make more payments than the other, but they will both make some.

By applying probability theory, *N* can be approximated by a linear function:

where *q* equals the absolute value of *1/(2p — 1).*

Let’s look at an example to see why *N* behaves almost linearly. Suppose *p = 2/3*, so Alice makes the next payment with probability *2/3* and Bob makes it with probability *1/3*.

On average, for each payment Bob makes, Alice makes two. This means that, on the long run, most of the payments will go from Alice to Bob, resembling the case where *p = 1*. In this case *q = 3*, meaning *3* payments have a net effect of *1* payment, in terms of unbalancing Carol’s channels.

The conclusion above applies to all values of *p*, different from *0*, *1* and *1/2*. By canceling payments going in opposite direction, this case can be seen as if either Alice or Bob, whoever has a greater value of *p*, is the only one making payments. It just takes longer to deplete a channel. Precisely, *q* times longer.

As seen above, the lifetime of Carol’s channels will be approximately linear on *a/z*. The only case where this wouldn’t be true is if Alice and Bob make perfectly unbiased payments, which seems unrealistic. So we can safely say that *N(a, z) = q (a / z).*

### Fees in the Lightning Network

The model sheds light on how the lifetime of a channel varies for different values of *a*, *z *and *p*. What does this tell us about how Carol should charge for each payment?

Carol’s total fees is the sum of the fees she charges per payment. If we define *F(z)*, the function that receives a payment of size *z* and calculates the fee that Carol charges for it, the total fees satisfy:

At the same time, the total fees should equal the cost of rebalancing channels, *c*, which we can assume to be constant over a short period of time.

By applying *N(a, z) = q (a / z)* to the previous equation we get that

Carol’s strategy, implicit in this equation, should be to charge a fee proportional to the transacted amount. This would cover the operational costs of her node.

### Financial costs

Aside from the operational costs of rebalancing channels, Carol also incurs financial costs because her money is locked inside channels. She cannot move it, spend it or invest it. These costs are usually modeled by some interest *r* she will pay, let’s say, annually.

Unlike operational costs, financial costs depend on time so Carol will have to pay for them regardless of whether she routes payments or not. This means that financial costs can covered following different strategies.

For instance, if Carol expects to route approximately *k* payments during the next year, she could add the term *(ra)/k*. The fee function would look like this:

In this case, fees will not necessarily be cheaper if Carol commits more money in her channels. Also, if financial costs are split equally between payments very small payments will still have a very high fee.

Other ways of reflecting financial costs in the fee function could be based on the amount transacted. If Carol expects to route a total amount of *Z* BTC in the next year, she could simply increase the proportion being paid in each transaction by adding a term *(rnz)/Z* to the fee function. The fee function will look like this:

### Conclusion

We have come to the conclusion that **intermediate nodes will charge fees proportional to the amount transacted** in order to cover their operational costs.

Because fees are proportional to the amount, big payments will be charged with bigger fees. This might trigger big payments to be on-chain transactions. The Lightning Network would still offer immediacy, so this could still be a reason for going off-chain anyway.

We have also analyzed different ways of including financial costs in the calculation of fees and the implications of each strategy.

The Lightning Network is moving fast and we are excited to see new advances in the following weeks. If this topic is interesting to you, write us and join the conversation!

For more details about the calculation of *N*, you can read the paper written by Simina Brânzei, Erel Segal-Halevi, Aviv Zohar

Visit Muun Website: https://muun.com/

Follow Muun on Twitter: https://twitter.com/MuunWallet

*Originally published at **blog.muun.com** on November 22, 2018.*