Published on: 2018-11-15T07:22:09+00:00
ZmnSCPxj and Christian discuss the flexibility and security of their rendezvous construction compared to HORNET. While HORNET allows only one rendezvous node, Christian believes their construction is similar except for an ephemeral key switch at the rendez-vous point. Christian states that although the locations are different, the constructions are not. The only issue mentioned is that HMAC verification won't work if a specified shared secret cannot be generated at the RV.A proposal for multiple rendezvous nodes is discussed in the Lightning-dev mailing list. It differs from HORNET by allowing multiple rendezvous nodes. However, concerns are raised about possible security degradation. A member suggests implementing HORNET, which supports rendezvous routing and is formally proven. The group discusses potential issues with the mechanism described during the spec meeting and how it could violate the wrap-resistance property of the ideal onion routing scheme. A new proposal is presented involving an additional ECDH at the rendezvous point, ChaCha20 encryption, and scalar multiplication to generate the next ephemeral keys. This aims to hide the fact that RV was a rendezvous point.In another discussion on routing and payment splitting in Lightning Network, Conner Fromknecht suggests using the formal proof of HORNET as a solution. He argues that introducing re-routing or rendezvous routing in the current manner would violate the wrap-resistance property of the ideal onion routing scheme. Christian Decker proposes a solution involving an additional ECDH at the rendezvous, ChaCha20 encryption, and scalar multiplication to generate the next ephemeral keys. ZmnSCPxj points out that even with a single channel, link-level payment splitting/re-routing is possible using rendezvous routing.The use of HORNET, which supports rendezvous routing and is formally proven, is proposed. The mechanism described during the spec meeting raises concerns about the padding at the rendezvous point. A new scheme involving additional ECDH, ChaCha20 encryption, and scalar multiplication is proposed. However, there is a problem with finding an identical ephemeral key that D requires to decrypt the onion correctly. Despite this issue, ZmnSCPxj believes in the potential of link-level payment splitting and rendezvous routing. He suggests routing through alternative channels when one channel direction is saturated.The author proposes using rendezvous routing and link-level payment splitting in Lightning Network. Christian raises concerns about the padding mechanism in the proposal and suggests zero-filling the padding and performing an additional ECDH at the rendezvous point. However, this scheme makes it impossible to find an identical ephemeral key required for decryption. Despite the issues, ZmnSCPxj sees potential in link-level payment splitting and re-routing, even with a single channel. He suggests routing through alternative channels when one channel direction is saturated.In the recent discussion on the Lightning-dev mailing list, the concept of link-level payment splitting and re-routing is proposed. It is possible to perform link-level payment splitting/re-routing even with a single channel to the next node. The idea involves routing payments through alternative channels if the primary channel is saturated. For example, C can route to D via A instead if the CD channel is saturated. This allows for re-routing or payment splitting over multiple hops, providing an alternative to failing the routing and earning nothing.In the same discussion, it is confirmed that link-level payment splitting has been accepted and there is provisional acceptance of rendezvous routing. The idea of re-routing or payment splitting over multiple hops is also raised. Even with only one channel to the next node, it is possible to reroute or split payments. For example, if C cannot send to D due to a saturated channel, it can route to D via A if A supports rendezvous routing. This provides a chance for success in sending the payment to the final destination.
Updated on: 2023-07-31T20:40:09.986633+00:00