From john-john at markstedts.org Wed Mar 13 14:55:10 2019 From: john-john at markstedts.org (John-John Markstedt) Date: Wed, 13 Mar 2019 15:55:10 +0100 Subject: [Lightning-dev] Fee structure Message-ID: 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]. [image: protocol_upgrade.png] 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: