Published on: 2019-04-04T14:48:54+00:00
In a discussion on the Lightning-dev mailing list, several proposals were put forward to enhance the anonymity, scalability, and security of the Lightning Network. One proposal suggested a design for trampoline-level onions that would enable the replacement of the first hop. This design involved sending the first hop of the inner trampoline-level onion without encryption, while still encrypting the outer link-level onion. When the receiving node identified itself as the first hop, it would decrypt the rest of the onion to route to the next trampoline-level node. If the node couldn't find the front of the trampoline-level onion, it could route it to another node more likely to know the destination.Another issue discussed was the unintentional creation of overlapping routes by trampoline nodes. This occurred when a trampoline onion was created, and the receiving node found that the direction with low capacity, so it routed over the outer onion instead. It was determined that this was not a problem as Hashed Time Locked Contracts (HTLCs) still resolved correctly, ensuring atomic and secure payments. The skipped nodes might lose some fees, but this was no different from a failed payment attempt being retried from the sender.The shift from HTLC to Point-Locked Timelocked Contracts (PTLC) was also discussed as an improvement in terms of security and scalability. PTLC involved locking funds using elliptic curve cryptography and releasing the private key required to unlock the funds after a predetermined amount of time. This shift reduced the risk of attacks such as hash collisions and allowed for faster payments.The Lightning Network also considered implementing multi-trampoline routing systems to increase flexibility in crafting payments. This system would enable payments to be bounced through multiple trampolines without revealing their position in the nested path. Using a smaller onion for the inner trampoline-level route would delegate payment routes and increase the chances of successful payments.In terms of compatibility, there were concerns about whether HMAC would still be valid if more than one intermediate node was inserted to reach the next trampoline. Alternative fee mechanisms were proposed, where sending nodes offered fees for successful routing. However, this required intermediate nodes to know the ultimate destination of the payment, which raised concerns about determining reasonable next hops.Another proposal involved using the upcoming "Multi-frame sphinx onion format" to trustlessly outsource the computation of payment routes. This would reduce the load on sending nodes in terms of memory, bandwidth, and CPU usage. However, fee computation would have to be pessimistic. Rendez-vous routing was also suggested, where the sender provided a rendezvous point from their local network and the recipient provided a route to themselves. Only the recipient needed to know the entire network topology.Overall, these proposals aimed to improve the efficiency and privacy characteristics of trampolining in the Lightning Network.
Updated on: 2023-07-31T21:31:34.347690+00:00