Author: Joost Jager 2023-02-15 10:56:23
Published on: 2023-02-15T10:56:23+00:00
The performance of Lightning Network for payment routing depends on the type of payment flows considered. End-users sending payments to local vendors would benefit from fast payment, whereas those doing remittance payments would prefer cheap fees. Adding latency as a criteria for pathfinding construction has been suggested in the past for LDK. The hope is that lightning nodes become efficient enough to eliminate the trade-off between cost and speed. Forward-error-correction code on top of MPP could be used to reduce payment latency. Adding more signal channels between HTLC senders and routing nodes offering capital liquidity can lead to better allocation of capital. Routing nodes may use more liquidity to serve finely tailored HTLC requests by senders, but this liquidity should be rewarded with higher routing fees. Careful policy rules design and deployment on the base-layer is necessary to ensure smooth upgradeability, preventing re-deployment cost towards new versions that might incentivize old routing nodes to stay on non-optimal versions.Highly available can be defined with multiple senses, like fault-tolerance, latency processing, and equilibrated liquidity. A routing node may not be able to optimize its architecture for the same end-goal as more watchtower on remote hosts probably increases the latency processing. Without shadow channels, it is impossible to guarantee liquidity up to the channel capacity. It might make sense for senders to only assume high availability for amounts up to htlc_maximum_msat. To avoid performance discrepancies between node implementations or versions, sender assumptions should be well-documented. Signal availability should be explicit rather than implicit, even if it consumes more gossip bandwidth data. Relying on new gossip messages where they can be filtered according to the level of services required is interesting.
Updated on: 2023-06-03T11:52:04.061779+00:00