Published on: 2019-03-14T22:18:26+00:00
In the email thread, Rene Pickhardt responds to concerns raised by ZmnSCPxj and Ariel Lorenzo-Luaces regarding his proposal for Just-In-Time (JIT) routing on the Lightning Network. ZmnSCPxj suggests introducing a 'success_rate' for JIT routing, but Rene advises against including it in the protocol, stating that rebalancing should only occur when liquidity is actually needed, and nodes should make their own decisions about engaging in JIT rebalancing. He also suggests reusing the payment hash with JIT Routing to mitigate probing-based network analysis and reduce payment failures, but mentions technical challenges such as potential deadlock problems. To address this, Rene proposes a MUST-rule and suggests setting a base-AMP feature flag or creating a new one for JIT-routing.Despite these challenges, Rene believes that reusing the payment hash is desirable if they can prove its feasibility and address the technical issues. In a separate message, ZmnSCPxj proposes a rule for determining when rebalancing would be beneficial to a node, involving comparing the fee offered for forwarding, the estimated success rate after forwarding, and the cost of rebalancing. The success rate can be computed statically from node data, but augmenting this information over time with experienced success rates for all forwards is preferable. The email also provides information on how to compute the fee amounts and includes links for further discussion on the Lightning-dev mailing list.JIT Routing is introduced as an alternative to source-based routing on the Lightning Network, aiming to reduce the need for guessing routes with sufficient liquidity. It makes the routing process more like IP-forwarding and allows local channel balance information to be incorporated without compromising node privacy. However, JIT Routing may not always be economically incentivized for routing nodes, and sub-routing processes initiated during JIT routing may extend the overall routing time. Capacity reservation before setting up HTLCs is recommended to prevent hostile recursive chains of rebalancing operations.Base AMP is suggested as a solution for routing single big payments, but it still relies on source-based routing and poses challenges for senders in guessing viable routes. The recommendation for implementing 'How to JIT Routing?' is provided along with an example of how JIT Routing works. It enables nodes to quickly rebalance channels and pass the original onion with a value tailored for the route. However, it may trigger additional JIT operations at other nodes or make later stages of the original onion harder to forward. A promising heuristic for channel rebalancing is proposed, involving analysis of the friend-of-a-friend network and removing the node that wants to rebalance from the graph. The resulting smaller graph allows for cheap rebalancing suggestions. The code for this rebalancing schema will be released soon, and feedback is encouraged during its development.
Updated on: 2023-07-31T21:28:18.659878+00:00