Lightning network is the up and coming standard for sending payments throughout the Bitcoin network, it makes tiny fee and fast payments a reality that Bitcoin’s current network can not promise. But Lightning introduces new attack vectors, most important of which is called the Loop Attack. The basic idea is that a sender and receiver collude to create a long circuit and refuse to settle or fail the HTLC¹ at the end until the last possible moment.

Lightning works by making “Payment Channels” between Lightning nodes, so if you would like to get a payment from your end to another node, you use payment channels between you and this other node to reroute the payment, this is a very simple explanation to a much more detailed process. Each node in the route must first confirm that it received the payment then reroute it to the next node, this process is done by Hashed TimeLock Contracts (HTLC for short), these are payments that use hashlocks and timelocks to require the receiver of the payment to confirm the payment before a certain deadline or forfeit his ability to claim the payment at all.

Loop attacks works by delaying this confirmation until the last second, this causes the funds to be locked up in every channel in the route, and since Lightning uses Onion routing, you can never know which node in the route is the root of all problems, as every node can always say there’s a node downstream that’s causing the delay.

There are a few suggested solutions for this attack, according to developer Jim Posen:

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 for nodes.

The first two options have their weaknesses so we will not discuss them here. The third option is the one that intruiged Jim, the idea here is simple in concept, each node will keep a reputation for the nodes it is connected to, this reputation depends on the amount of accepted, refused and delayed payments. This is not only connected to this specific node, a node will lose reputation if it routed the payment to an attacking node, even if it itself isn’t attacking the network. Now a way of measuring this reputation is that money fees collected through routing payments raise the reputation of the channel peer, but accepting an HTLC and delaying will lose you reputation proportional to its value and the time you delay it for. Each node can track peers for three things, the total fees collected from forwarding on routes where the peer is the prior hop and where it is the next hop, it will also keep tabs on the total value locked in HTLC multiplied by the time, so when a node offers another an HTLC, it starts a timer until that HTLC is either settled or refused, once the timer stops the node registers the total time elapsed multiplied by the value of the HTLC.

This will act as an incentive for nodes to send honest nodes the payments, as your node will pick the highest reputation node available that has a route to your target node, while it also acts as a disincentive to dishonest nodes as they will both lose potential routing fees and have to pay fees to re-earn the reputation they lost.

This option was faced with a little criticism as it can decrease the reputation of honest nodes that only have a connection to a dishonest node, but it was argued that a node can always refuse the payment instantly if it sees that this payment will only reduce its reputation in the future, so it becomes a risk game, where your node will calculate the risk of accepting a payment and compare it with the fees attached to this payment, if it sees that this is a risk it is willing to take it will accept the HTLC and if not, it will just instantly refuse it.

This subject is one that will have a lot of discussions as it will need to be heavily tested before it can get anywhere near implementation, if you’d like to keep up with the discussions you can always read the mailing list attached.