Probing final receiver with refund timeout [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2016-03-22T01:14:15+00:00


Summary:

In the Lightning Network, Mats Jerratsch proposes a solution to prevent nodes from knowing if a payment is originating from another source or being relayed. The proposal involves each node publishing its MIN_TIMEOUT, which is then used to calculate the initial HTLC timeout for payments. The payer adds some random value to the timeout and subtracts the last hops' MIN_TIMEOUT for subsequent layers of the onion routing packet. This prevents nodes from detecting patterns in payment timeouts.The context also discusses a potential attack vector where an intermediary node can determine if a sender is generating all their payments or relaying payments for someone else. To address this, randomized timestamps are suggested in the onion object to prevent explicit information on the number of previous hops. The sender deducts MIN_TIMEOUT * MIN_OVERLAY * RANDOM from the initial value to further randomize the refund time.Mats Jerratsch also suggests adding complexity to prevent free payments and potential blocking of future features involving multiple payments to one R value over the same route. He proposes using bitwise identical onion routing information to prevent malicious nodes from manipulating the routing onion. However, he acknowledges that there may be patterns that clever individuals could exploit.Furthermore, there is a vulnerability in the onion routing of Bitcoin's lightning network discovered by Mats Jerratsch. It allows an attacker to initiate a probing attack by setting too short of an absolute CLTV refund timeout. Rusty Russell suggests mitigating this attack by remembering the onion and always failing an identical one. Randomizing the timeout for the next hop is also suggested, at least subtracting MIN_TIMEOUT to MIN_TIMEOUT*2. The appropriate HTLC timeout is still under discussion.Overall, these proposals aim to enhance the security and privacy of the Lightning Network by preventing detection of payment sources, randomizing timeouts, and addressing vulnerabilities in the onion routing mechanism.


Updated on: 2023-07-31T18:53:02.788514+00:00