# Game theory to enforce multi-hop payments (deter reserve credit attacks )

A major problem in multi-hop payments is the reserve credit attack , that a person can initiate a payment and then cause it to never finish, thus locking credit forever. This attack can be prevented by financially punishing the attacker. The mechanism for such penalty differs depending on who the attacker is, and a complete solution requires a three step payment agreement, commit , seal , finalize , with fees paid by the buyer added on top of the payment and agreed on beforehand.

The game theory can be explained by starting with the last step and then showing how the steps leading up to it are required to organize that last step. During finalize , each intermediary from the direction of the seller and towards the buyer will complete the payment. At the same time, the amount that can be finalized starts to gradually decrease after the timeout has been reached. Thus, an intermediary who does a stop-propagation attack  (the mechanism to cause the reserve credit attack ) will end up with less incoming payment than their outgoing payment they already finalized. They thus end up having to pay a penalty. This step thus requires that there is a continuous cancellation  on the buyer side of the intermediary who propagates finalize . This continuous cancellation  is set up using the two previous steps, seal  and before it commit .

The seal  step is a bridge between the first step commit  and the finalize  step. Primarily, seal  signals that the buyer has revoked their right to cancel (the right of the buyer to cancel is indispensable to organize the first step, commit ). It is very important that the buyer revokes this right and that each intermediary knows that they did. On top of that, any user who has propagated seal  will start to continuously cancel the payment (thus adding the enforcement penalty onto finalize ). This continuous cancellation  also serves as an enforcement to propagate seal  itself, but only because the previous step, commit , had set up a continuous finalization . Thus an intermediary who does a stop-propagation attack  on seal , will end up having their outgoing pending payment gradually finalized while their incoming pending payment is gradually cancelled (at equal rates seems best). They thus end up having to pay a penalty. This penalty that enforces seal  thus required the continuous finalization  to have been organized originally during the commit  step.

The commit  steps main role is to ensure everyone is on board with the payment and goes all-in  on it. To ensure this, we rely on that the buyer will be punished if everyone has not agreed yet and the payment times out (and thus forced to use buyer cancels  to cancel the payment). For this punishment, we need to add a fee on top of the payment, that has been agreed on by all people in the payment. This fee will be a percentage of the payment, and each person in the payment will demand a certain rate and the buyer will prefer the path with the lowest total fees. The fees are paid out at the same rate as the continuous cancellation  and continuous finalization  (i.e., a single rate that says how much of the payment has been either cancelled or finalized as well as paid out as fees yet ). The fees are paid out in every step of the payment (both commit , seal  and cancel ) and they compensate the people who are victims of a reserve credit attack  (and if no attack or network failure occurs and the payment finishes before timing out, no fees is paid out). The fees are paid out in proportion to how much of the payment had time to be processed , if the payment was stuck for a half of the time it would have taken to cancel/finalize the entire payment, half the fees are paid out.

So, we have single ticking rate for cancelling the payment, finalizing the payment, and paying out the fees. The fees deter the buyer from doing the reserve credit attack . The cancellation and finalization deters everyone else (for the seller, they are always guaranteed to get the full amount as long as commit  succeeds and the seller themselves do not do stop-propagation  at finalize , so the buyer will know that the payment was successful even if the seller tries to do such attack, the seller can never claim oh someone attacked and I got nothing  if they are themselves the one attacking, and if anyone else attacks the seller always gets the full amount, paid for by the attacker).