Published on: 2023-03-02T13:35:38+00:00
In a recent email, g0b1el proposed two improvements to the Lightning Network's payment protocol. The first improvement simplifies rendezvous routing by allowing nodes on the route to receive the same amount of reservation without needing to put the amount inside the onion. This results in smaller onions, as the onion now only holds the next hop information. The second improvement eliminates the need for an HTLC onion in the second step by including all necessary information in the route hops. This reduces payment latency by just one more call between the route nodes. The proposal can be found on the mailing list archive.Another proposal on the Lightning mailing list suggests implementing ASCII graphics to enhance the user experience for command line tools. However, some users have reported issues with rendering these graphics in certain environments. To address this problem, g0b1el recommends referring to the proposal on the mailing list archive where the graphics are rendered correctly. The proposal introduces a feature that allows users to view transaction details and other information in a visually appealing format using ASCII graphics. Users would also have options for customization. However, concerns have been raised regarding the practicality of this feature, including how well the graphics will render in different environments and their accessibility to all users. Performance and resource usage are also factors of concern.The Lightning Network proposes a new payment routing method called Payment Route Reservation. This method splits the payment process into two steps, with the routing node reserving a specified amount of satoshis with a timeout. If the reservation is not canceled, the satoshis can be used in the next payment step. This approach offers several advantages, such as higher reliability, lower latency and fees, increased privacy, and a healthier, more decentralized network. In cases where a routing node cannot add a new reservation due to insufficient balance, it can attempt to find another route to reserve the missing amount for the next downstream node. This is known as Route Split Reservation, which involves sharing the same payment hash between a new route and the main route. To avoid infinite reservation recursion calls, the route split node passes a tuple indicating the maximum fees and cltv_delta it will accept from the new route.To address the lack of information about fees and payment duration in the Trampoline Routing method, the Lightning Network has introduced Trampoline Route Split Reservation. This allows senders to split payments into smaller parts and create multiple reservation routes. By waiting for N routes to return successful reservations before initiating payment, senders create market competition for faster and cheaper routes.The capacity of nodes should not be used as a heuristic in Lightning Network routing algorithms, as it can be misleading. Instead, nodes should publish their cumulative outbound liquidity over all channels to signal where liquidity is needed and where there is excess. Routing decisions could then be based on node-reported balance, hop count, and randomness. For privacy currencies like Monero, channel capacity publication is unnecessary, and routing decisions would rely solely on hop counts and randomness.Fast spam prevention involves throttling reservations from channels that generate numerous reservation errors per minute. If spam persists, the node operator can inform the neighbor node operator to investigate, and the channel may be closed if the issue persists. To prevent an attacker from creating a circular route, prepayments can be demanded, with fees adjusted accordingly. The first node in the route can take the prepayment if it is less than or equal to the fees it will earn by routing the payment.With route split reservations, the need for splicing-in and partially splice-out operations to increase channel capacity is eliminated. Instead, N smaller channels between two nodes can be treated as one big channel by reserving a route through all N channels during reservation. Closing one channel becomes a splice-out operation. Additionally, the Lightning Network acknowledges that payments may still fail due to reservation timeout, node unavailability, or griefing nodes. However, Stuckless Payments can help increase reliability to around 99 percent.
Updated on: 2023-08-01T01:04:09.724134+00:00