Blind paths revisited



Summary:

In this email thread, Subhra and ZmnSCPxj discuss the use of anonymous multihop locks in the Lightning Network protocol and potential vulnerabilities. ZmnSCPxj clarifies that in the context of PTLCs, R does not get a key but generates an adaptor signature which is handed over to F. Both sender and receiver control the secrets in the PTLC, so it is not controlled by a single entity. Griefing attacks are only possible by not claiming or forwarding the attack. ZmnSCPxj argues that privacy should be considered for the payment as a whole and that if the sender leaks who it is paying to, that is pretty much the entire loss of privacy. Currently, the exact receiver node has to be known by the sender in order for the sender to make a route to it, which could be a concern for layer-crossing shenanigans.The sender could attack the receiver on the Bitcoin blockchain layer by attempting to eclipse it and making it lose funds. To prevent this, a proposal has been made for the receiver to provide a partial, blinded path which gives better privacy protection against the sender. This makes it harder for the sender to locate the receiver's node and perform an eclipse attack at the Bitcoin layer. The blinding factors in a decorrelated PTLC-based payment can be generated by the sender, however, it is safe for the receiver to provide blinding factors to a partial path as well. The final point/scalar pair is completely controlled by the recipient, so it should not be an issue whether the sender targets the first node in the receiver-provided partial route or the final point of the ultimate recipient.


Updated on: 2023-06-03T00:04:03.661768+00:00