Probing final receiver with refund timeout



Summary:

The context discusses a potential attack vector in the Lightning Network, where an intermediary node can determine if a sender is generating all their payments or relaying payments for someone else by plotting the timeouts of the payments. If the sender generates all payments with a timeout larger than a minimum value X, they are likely just randomizing them. However, if the initial refund value is lower than X, the payment might not succeed due to intermediate nodes deducting too much. The number of nodes in the route is not constant and therefore adds another degree of freedom to choose the initial value. The solution proposed is to use randomized timestamps in the onion object to prevent explicit information on the number of previous hops. The sender will choose a good starting value and deduct MIN_TIMEOUT * MIN_OVERLAY * RANDOM from it. This mechanism is the same as the one used by intermediate hops to come to that value.


Updated on: 2023-05-23T22:37:54.628068+00:00