Good morning Subhra, > Commenting on it : "As for ZmnSCPxj's suggestion, I think there is the same > kind of issue. > The secrets we establish with anonymous multi-hops locks are between the > *sender* > and each of the hops. In the route blinding case, what we're adding are > secrets > between the *recipient* and the hops, and we don't want the sender to be able > to > influence those." > Is it a good idea to rely entirely on the sender for sampling the secrets as > well as generating the PTLC? As happens in anonymous multi-hops locks, for > example. Or as it has been discussed later in the thread, both receiver and > sender must be involved in creation of PTLC? What happens if sender/receiver > is/(or both are) corrupted? Can it leak secrets to other parties?
If both are corrupted, this brings up the question: who are you hiding any information from? The corruptor has already corrupted both: there is no security or privacy possible, the payment is already totally compromised. The operation of forwarding nodes is simple enough that in general they cannot be attacked: sure, the sender and receiver together knows who they are, but forwarding nodes are the ones who advertise themselves in order to be forwarded through, so they already are known anyway. When considering privacy, we should always consider that it is the payment as a whole which we want to have privacy: we want that third parties will not be able to nail down which particular sender sent to which particular receiver. Thus if the sender already leaks who it is paying to, that is pretty much the entire loss of privacy. Now, currently on Lightning, in general the receiver does not know the sender node. (Applications on top of Lightning might have the receiver require the sender to provide private data, such as a drop point to send a physical product to, but *looking only on Lightning* the sender does not send any of its information to the receiver). However, currently, the exact receiver node has to be known by the sender, in order for the sender to make a route to it. This is a concern since it may be possible for layer-crossing shenanigans to be performed, for example the sender might attempt to eclipse the receiver on the Bitcoin blockchain layer and make it lose funds by not realizing that a PTLC/HTLC has been timed out (because the eclipse attack prevents new blocks from propagating to the receiver, who blithely continues to think that the timeout has not been reached when in fact it has). The proposal to have a receiver provide a partial, blinded path gives the receiver better privacy protection against the sender: the sender knows it is one of a possible number of nodes within some number of hops from a particular node, but does not know if it is that exact node, one of its neighbors, or one of its neighbor neighbors (etc.) is the actual receiver. This should make it harder for the sender to attack the receiver by attempting to locate its node and eclipse it at the Bitcoin layer, or other blockchain-layer shenanigans. Now, the argument I make is that while the blinding factors in a decorrelated PTLC-based payment may be generated by the sender in order for the sender to have path privacy, it is safe for the receiver to provide blinding factors to a partial path as well. We should remember that the blinding factors are just scalars added to the final point/scalar at the ultimate recipient, and the final point/scalar pair is completely controlled by the recipient anyway, so it should not be an issue here: the point that the sender will target at the first node in the receiver-provided partial route is no different from the final point that the sender would have targeted if it knew exactly who the receiver is. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
