Good morning Subhra, > Hi ZmnSCPxj, > Thanks for the explanation. Pardon my knowledge in this domain but what > I meant is that sender has malicious intent and wants honest parties to > suffer. So by leaking secrets, I meant not revealing its or receiver's > identity to the forwarding nodes, but somehow manipulating subset of the > nodes so that an attack can be launched in the network. For example, consider > path S->A->B->C->D->E->F->R. If we consider the protocol anonymous multihop > lock, S samples secret x_a,x_b,x_c,x_d,x_e,x_f for the nodes A,B,C,D,E and F > respectively. R gets the key k=x_a+x_b+x_c+x_d+x_e+x_f. If S colludes with B > (possibly leak the value x_c,x_d,x_e,x_f to B), lock funds C,D,E but then not > allowing it to relay funds (possibly do a griefing attack?). What I meant is > that if one totally relies on S for the setup phase, won't it lead to other > vulnerabilities? The situation might sound unrealistic but I still have doubt > whether we guarantee fairness if put our trust entirely on one single entity.
Note that in the context of PTLCs, R does not get a key (as in private key) of x_a+x_b+x_c+x_d+x_e+x_f. Instead, R still continues to use its normal private key for claiming HTLC/PTLC. We simply have R generate an adaptor signature first and hand that over to F, such that completing the signature and publishing it onchain will reveal a secret x_r (which is NOT the node privkey of R). What happens really here is that each hop sets up a PTLC. The sender is responsible for ensuring that the F->R PTLC is equal to x_r * G, that E->F is equal to (x_f + x_r) * G, that D->E is equal to (x_e + x_f + x_r) * G, and so on. However, the sender knows only (x_r * G) without knowing x_r, thus it never is able to completely control the secret at every point -- the receiver knows the other secret as well. That is the entire crux of the argument --- *both* sender and receiver control the secrets anyway, so it is not controlled by a single entity, at least for non-self-payments. > If S colludes with B (possibly leak the value x_c,x_d,x_e,x_f to B), lock > funds C,D,E but then not allowing it to relay funds (possibly do a griefing > attack?). Griefing attacks are only possible by not claiming or forwarding the attack. If S and B "collude" to perform a grief, then either B never forwards to C, in which case there is no possible way to attack, or C receives it and claims it but B does not claim it, in which case B paid out money and is now idiotically refusing to claim money. Grief attacks are attacks by payers and payees on intermediate nodes (S and R attacking A,B,C,D,E,F), and in that case the entire payment secret would be known by both S and R anyway. So S and B cannot cooperate to perform a griefing attack on the path. Regards, ZmnSCPxj > > On Wed, Apr 1, 2020 at 10:39 PM ZmnSCPxj <[email protected]> wrote: > > > 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 > > -- > Yours sincerely, > Subhra Mazumdar. _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
