Author: Mats Jerratsch 2015-12-08 17:13:22
Published on: 2015-12-08T17:13:22+00:00
The author discusses a design for a system to ensure privacy in payment transactions. The proposed system uses Onion Routing, which routes payments over a rendezvous point and encrypts them using an onion scheme. The sender and receiver of the payment would not learn any additional information about each other by default. If A wants to make a payment to E, E will choose a RP C and create an onion object which will allow C to route the payment further towards E. A will not know which node is receiving the payment, A only knows that it should route the payments towards C. The author explains that they have to decide whether the onion-routing should be one-time and one-directional or not. In the previous design, the onion objects were filled with zeros, making it impossible for the receiver to send a message back to the sender. Therefore, the payment request was one-time only. However, the author proposes that it would be possible to have a message system integrated where each node could encrypt and append the pubkey of the node it received the object from together with the ephemeral key used initially. When the receiver wants to send a message back, he encrypts it using some designated ephemeral key included by the sender and uses the onion object to send it back. This means that a payment request is just a way of contacting the receiver to obtain information about making a payment.The author also highlights some potential issues with this design, such as a possible security risk if someone obtains the onion object and 'hunts down' the sender by targeting the nodes consisting of the route one by one. Additionally, it is difficult to provide reasonable DoS protection against nodes spamming the network with unnecessary messages. The author suggests assigning super tiny payments to the process of sending a message to counter spam, but it might be difficult to implement.
Updated on: 2023-05-23T21:46:44.095628+00:00