Re: [Lightning-dev] Mitigations for loop attacks

On Fri, May 11, 2018 at 9:18 AM, Jim Posen wrote: > Hmm, I'm not quite following the situation. What do you mean by "directs > normal traffic"? Since the sender constructs the entire circuit, routing > nodes do not get any discretion over which nodes to forward a payment to,

Re: [Lightning-dev] Mitigations for loop attacks

Hmm, I'm not quite following the situation. What do you mean by "directs normal traffic"? Since the sender constructs the entire circuit, routing nodes do not get any discretion over which nodes to forward a payment to, only whether to forward or fail. What an attacker could do is perform a loop

Re: [Lightning-dev] Mitigations for loop attacks

hello, I'm a curious lurker trying to follow this conversation: On Thu, 10 May 2018, 2:40 pm ZmnSCPxj via Lightning-dev, < lightning-dev@lists.linuxfoundation.org> wrote: > > The concern however is that the CLTV already partly leaks the distance > from the payee, whereas the reputation-loss-rate

Re: [Lightning-dev] Mitigations for loop attacks

Good morning Jim, > One more point in terms of information leakage is that noise can be added to > the "this is the rate that you'll lose reputation at" field to help obfuscate > the number of upstream hops. I proposed setting it to "this is the upstream > rate that I'm losing reputation at" +

Re: [Lightning-dev] Mitigations for loop attacks

One more point in terms of information leakage is that noise can be added to the "this is the rate that you'll lose reputation at" field to help obfuscate the number of upstream hops. I proposed setting it to "this is the upstream rate that I'm losing reputation at" + downstream HTLC value, but a

Re: [Lightning-dev] Mitigations for loop attacks

Thanks for the thoughtful responses. > You missed the vital detail: that you must prove channel closure if you > can't unpeel the onion further. That *will* hit an unresponsive party > with a penalty. Ah, that is a good point. I still find the proposal overall worryingly complex in terms of

Re: [Lightning-dev] Mitigations for loop attacks

Jim Posen writes: > There are two directions of solutions I have heard: 1) protocol support for > decrypting the onion route if the HTLC is kept in-flight for too long 2) > requiring fees even if the payment fails as a cost to the attacker 3) some > sort of reputation system