Author: Christian Decker 2020-02-21 21:22:41
Published on: 2020-02-21T21:22:41+00:00
Rusty Russell suggests creating a circular path for onion routing, in which the sender constructs an onion that creates a path from themselves to the recipient and back, ensuring different nodes on the forward and return directions. Christian Reitwiessner agrees with this proposal, but notes that the "recipient" cannot add any reply without invalidating the HMACs on the return leg of the onion. However, he has a construction of the onion routing packet that allows it to be compressed in such a way that it fits inside of the payload itself. This rendez-vous construction is more involved since it requires fitting an onion into another onion of the same size. If a new messaging system requiring end-to-end communication is designed, then introducing an end-to-end payload might be worth considering. This would simplify the system and allow storage of a full, unmodified, return onion in the end-to-end payload. Another advantage is that the end-to-end payload is not covered by the HMACs in the header, meaning that the recipient can construct a reply without having to modify the routing onion.Reitwiessner also notes that the use case for circular payment, where two parties can communicate using the same circuit after the first message is received, is only suitable for certain circumstances like 'offers' which cause an invoice request, followed by an invoice reply. The disruption of a circuit by a node in the circular path may require higher-level protocols to resume the conversation on another circuit.
Updated on: 2023-06-02T23:49:20.181188+00:00