# [Lightning-dev] Fee structure

I’ve been thinking about the current fee structure I believe it may be
problematic
as there is no inherent way to incentive balanced channels.

This may be a bit far down the road as there are more direct problems
that need to be addressed first. However if you all believe there might be
some
merit in this line of thinking I can spend some more time formalizing a
more proper
implementable proposal and run some simulations to verify it’s impact on
throughput
and robustness.

Although there are methods to balance channels it would be beneficial if the
fee could reflect the state in which the channel is left.

Currently the fee is only proportional to the liquidity used, not the state
of the channel.

Suppose there exists a channel between Alice and Bob with 10 million
satoshis in it.
Two payments, [image: P_{1}] and [image: P_{2}] are routed through the
channel from Bob to Alice.
Both use the same amount of liquidity, 3,500,000 satoshis each, but they
start from
two different initial states [image: B_{1}] and [image: B_3].

The two payments would incur the same fee,

[image: F_{P_1 P_2} = F_B + (3,500,000 * F_R / 1,000,000)]

but leave the channels in completely different states.[image: P_1] at [image:
B_2] and [image: P_2] at [image: B_4].
It is of course possible to reset the channel price after [image: P_1] to
be more expensive,
but suppose a third larger payment [image: P_3] going from [image:
B_1] to [image:
B_4] would still run
into this problem.

It is possible to limit the maximum allowed payment, to say 1/5 of the
total channel
capacity, so a fee could be broadcast between payments. However
that would reduce possible transacting parties in the network, limiting
connectivity.

If the price structure was a scheme of brackets instead, where the cost
depend on the channel position, these issues may be resolved.
Each satoshi in the channel may be seen as a different bracket, with a
different price for each
satoshi moved. The channels would then broadcast a cost function instead of
the fixed fee.

[image: fee_scheme.png]

>From the cost function the fee may be retrieved by calculating the area
under the graphs.
Some deterministic way to round the fee to whole satoshis and some way to
verify the
function is formulated correctly must be defined.

The fees for [image: P_1], [image: P_2] would be very different with this
brackets method.

[image: F_{P_1} = F_{B} + \int_{B_1}^{B_2} f(x) dx = F_B + 13,502,153,930
\mu S]

[image: F_{P_2} = F_{B} + \int_{B_3}^{B_4} f(x) dx = F_B + 88,984,850,361
\mu S]

Here the fees are much larger for the payment that unbalances the channel
than the
payment that balances it.

Brackets would incentivize payments to route in such a way to keep channels
balanced which may lead to higher throughput.

This method clearly has some headaches accompanying it. It may be
unnecessarily complex and
would requires deterministic ways to calculate integrals over multiple
systems. There might be better
ways to solve this problem and there might be problems with this approach
I’m unaware of.
Anyway, some small tweaks in the protocol may lead to a much healthier
network which
may be worthy of exploration.

Best regards,
John-John Markstedt

_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev