Good morning Subhra, > Thank you for the clarification. Sorry for misinterpreting the paper of > anonymous multihop lock. A bit of rephrasing of what I exactly meant and > apologies for describing vaguely. Following your discussion on griefing > attack, it is clear the payer and payee wants to intentionally deprive > intermediate nodes, by colluding. However, by griefing (a misnomer for this > situation) I didn't mean exactly withholding the solution but something like > this: > Given S->A->B->C->D->E->F->R, S, B and F are controlled by the same adversary > and considering all the parties have completed the lock phase. Now R triggers > release phase and F gets x_r from R. However, F adds x_f to x_r forwards it > directly to B, doesn't complete signature with E and cancels the HTLC just > before the elapse of expiration time, E terminates its HTLC with D and so on. > B has x_c+x_d+x_e+x_f+x_r (shared by F and shared by S). It continues > normally completing payment with A and then S. I am not sure whether again > this attack makes sense.
If S controls F, then it could have just forwarded F->R directly without involving C D E at all, so in both cases C D E would also not earn any forwarding fees; instead now C D E learn of this payment, so the collusion S B F just unnecessarily leaks its intent to pay R by doing this. Again, S B F cannot steal funds from C D E by this method, it can only grief them, but it could grief C D E by just B and F, not involving any S or R, so this does not increase the attack surface at all. So I do not see the point of this exercise; S controls F anyway, so it could just as well have forwarded F->R directly. Regards, ZmnSCPxj > > On Thu, Apr 2, 2020 at 6:04 AM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > > > 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 <zmnsc...@protonmail.com> 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. > > -- > Yours sincerely, > Subhra Mazumdar. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
