ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-04-01 📝 Original message: Good morning Subhra, > Hi ...
📅 Original date posted:2020-04-01
📝 Original message:
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 <ZmnSCPxj at 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.
📝 Original message:
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 <ZmnSCPxj at 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.