Multi-hop payments have the "stuck payment" attack problem, that any node in the payment can decide to not propagate a decision, thus causing the payment to get stuck at that node. This problem can be resolved by adding a penalty system that enforces propagation by penalizing any node that causes the payment to get stuck. As the payment can get stuck on any decision, and by any node, this penalty system consists of three mechanisms, used to account for every possible scenario.
The decisions in the payment need to move in three different ways:
These movements can be enforced with two mechanisms, that are used either alone or combined. These mechanisms are:
To enforce 1 you need to use mechanism A. To enforce 2, you need to use mechanism B, and to enforce 3 you need to combine A and B.
These two mechanisms can apply enforcement in either direction, and cover all scenarios except when the attacker is both the buyer and seller. This is where the third mechanisms is used. The third mechanism is the addition of fees that are paid on top of the payment by the buyer.
With these three mechanisms, the propagation of any decision is enforced at any hop.
The movements described above, 1, 2, and 3, are building blocks for a secure multi-hop payment. They can be combined so that 1 is used to start the payment, 2 is used to complete the payment, and 3 is used to go from 1 to 2.
The first decision that is propagated with 1, ensures every node agrees to start the payment. It is a decision to cancel the payment (signed by the buyer) and is used in case the agreement to start the payment fails.
If every node agreed to the payment (the seller tells the buyer everyone has agreed), decision number 3 is used. This is the decision that the buyer revokes their right to cancel.
Once decision 3 reaches the seller, they send decision 2. This completes the payment.