# 3-phase commit to deter Denial of Service (DoS) attacks in multi-hop payments

2-phase commit systems in multi-hop payments can be built in two different ways, depending on if the timeout defaults to cancel or finish the payment. In either alternative there will only be a penalty on one of the phases, and the penalty will be on the opposite phase for either alternative (on the first phase for finish on timeout and on the second phase for cancel on timeout). To have a penalty on both phases, both variants of 2-phase commits have to be combined, with an intermediary phase to change the timeout action between the phases (this intermediary phase also informs all nodes that the first phase succeeded and that it can no longer be cancelled).

### 2-phase commits

@startuml
start
:Prepare;
note right: No penalty
note left: Cancel on timeout
:Commit;
note right: Penalty
end
@enduml

@startuml
start
:Prepare;
note right: Penalty
note left: Finish on timeout
if (All agree?) then ([Yes])
:Commit;
note right: No penalty
end
else ([No])
:Cancel;
note right: Penalty
stop
endif
@enduml

### 3-phase commit

@startuml
start
:Prepare;
note left: Finish on timeout
note right: Penalty
if (All agree?) then ([Yes])
:Pre-Commit;
note left: Cancel on timeout
note right: Penalty
:Commit;
note right: Penalty
end
else ([No])
:Cancel;
note right: Penalty
stop
endif
@enduml

## Chunked penalty 

With 3-phase commit, the penalty is what prevents DoS attacks rather than the time until the pending payment has been fully timed out. The pending payment can remain open as long as the penalty is actively deterring an attacker. This allows for a slow and gradual penalty, and this reduces the risk that a non-attacker is punished disproportionally.

# The rules needed to coordinate decentralized multi-hop payments

The building block is a timeout that defaults to either finish or cancel the payment. It can enforce an action if it causes someone to end up with a net negative balance. When it defaults to finish the payment, it can penalize the person who has a pending outgoing balance but no pending incoming balance (initially the buyer). When it defaults to cancel the payment, it can penalize the person who has a pending incoming balance but no pending outgoing balance (initially the seller).

This building block can be used in either configuration to successfully coordinate a multi-hop payment. When it defaults to finish the payment at the timeout, the person who has a net negative balance is incentivized to cancel the payment unless they are certain everyone has agreed to it. When it defaults to cancel the payment at the timeout, each person who has their outgoing payment claimed from the next hop is incentivized to claim their incoming payment from their previous hop.

When either of those configurations is used alone, the penalty for not succeeding to make or pass on a decision before the timeout is the full payment. I.e., if the buyer does not cancel in time (or if an intermediary does not propagate the decision to cancel in time), they end up paying out the full payment to whoever is the last person in the chain. And if an intermediary does not finalize in time (when the timeout is set to default to cancel), they end up paying for the full payment to the seller.

The coordination relies on that people put away money and promise it to the payment. The timeout places a limit on how long the money can be locked. The longer the timeout gets, the bigger the problem with Denial of Service attacks, i.e., payment attempts that are done only to lock the money of other people or sabotaged in such a way that the payment gets stuck.

The penalty can also be done in chunks , i.e., after the timeout only a chunk  of the payment is cancelled or finalized, and then after the next timeout another chunk  is processed, etc. Such a gradual penalty tends to increase the time until the payment has fully timed out, and therefore worsen the problem with Denial of Service attacks.

To resolve the issue of Denial and Service in full, the attacker has to always be penalized. When the timeout is used in the second configuration (defaults to cancel and finishes from the seller), the initial agreement to do the payment (that starts the timeout, done from the buyer towards the seller) is not enforced by any penalty. When the timeout is used in the first configuration (defaults to finalize and starts from the buyer), the penalty is active from the start, but once the buyer decides that the payment succeeded (everyone agreed to start it), the penalty does not enforce that each intermediary forwards this decision (the penalty can only enforce that the decision to cancel is forwarded). So the solution is to combine both of these payment solutions, to first start the payment from the buyer with the penalty started right away, and then finish the payment from the seller. As DoS attacks are then prevented, there is no obstacle to using the chunked penalty  (that tends to increase the time until the payment has timed out in full).

The two-step payment (start from the buyer and finish from the seller, with the timeout initially defaulting to finalizing and then defaulting to cancelling) deters Denial of Service attacks in all scenarios except when the attacker controls both ends of the penalty (the person being penalized and the person receiving the penalty). To deter DoS attacks in that scenario, fees have to be added on top of the payment, paid out in proportion to how long the payment was stuck in DoS attack.

When the timeout is used in the first configuration, finalize on timeout to finish from the buyer and forwards, there is nothing to enforce propagation during the finalization of the payment, thus this configuration by itself is open to Denial of Service attacks.

@startuml
start
:Lock credit from buyer and forwards;
note right: Finalize on timeout
if (All agree?) then ([Yes])
:Finalize from buyer and forwards;
end
else ([No])
:Cancel from buyer and forwards;
stop
endif
@enduml

When the timeout is used in the second configuration, cancel on timeout to finish from the seller and backwards, there is nothing to enforce propagation during the initial payment request sent from the buyer and towards the seller, thus this configuration by itself is open to Denial of Service attacks.

@startuml
start
:Lock credit from buyer and forwards;
note right: Cancel on timeout
:Finalize from seller and backwards;
end
@enduml

To deter Denial of Service attacks, both configurations have to be combined, with the first configuration leading into the second at the branch where everyone agrees to start the payment.

@startuml
start
:Lock credit from buyer and forwards;
note right: Finalize on timeout
if (All agree?) then ([Yes])
:Pre-finalize from buyer and forwards;
note right: Cancel on timeout
:Finalize from seller and backwards;
end
else ([No])
:Cancel from buyer and forwards;
stop
endif
@enduml

# Decision-making process for decentralized multi-hop payments

The problem in decision-making in a person-to-person chain is that a single link in the chain can break it. Primarily, a link in a chain can block decisions (by not agreeing on and forwarding it). In person-to-person payments, a blocked decision results in credit being locked indefinitely as the payment cannot proceed (it simply gets stuck). It is possible to prevent attacks that block decisions by punishing the attacker. As organizing such a punishment is itself a decision that can get blocked, the payment has to be done in such a way that the decision to start the penalty is itself enforced by a penalty, and the decision to end the penalty (and the payment) is also itself enforced with a penalty. Logically, the decision to start the payment (and the penalty) has to affect the outgoing balance (and thus start from the buyer) and the decision to finish the payment (and the penalty) has to affect the incoming balance (and thus start from the seller). When finishing the payment, there is a gradual decrease in how much can be claimed, and when starting the payment, there is a gradual decrease in how much can be cancelled (along with fees added on top of the payment that are paid out in proportion to how long the payment was stuck). With this penalty system, the buyer will request an agreement to start the payment. Depending on if everyone agrees, the buyer will either cancel the attempt, or go through with it. For either outcome, each intermediary and the seller is incentivized (by the penalty) to conform to it. The decision to go through with the payment requires two steps. First, the buyer has to inform each intermediary that they decided to do the payment (i.e., that they revoke their right to decide to cancel the payment). Then, the payment has to be finished from the seller and backwards, so that the penalty can enforce it (i.e., the penalty when finishing the payment has to affect the incoming balance, by reducing it relative to how much had been finalized already at the outgoing balance).

# Incentive system for decentralized multi-hop payments

Multi-hop payments across one or more intermediaries has the problem that a decision can get stuck if an intermediary does not forward it to the next hop . The solution to this problem is an incentive system. With the correct incentives, the decision-making in a decentralized payment chain can be guaranteed to either end with a successful payment or with a cancelled payment. The incentives have to enforce that an agreement is made to either succeed with the payment or cancel the payment.

The decision to either succeed or cancel has to be centralized down to a single authority. When it comes to agreements along a chain of people, the only person who can be certain about if everyone agreed is the last person in the chain (the receiving end of a decision can be certain that previous hops agreed on it, but the sender cannot be certain that hops further down the chain will agree on it). Thus logically, the authority for the decision should be either the buyer or the seller.

The incentive needed is a penalty that forces the buyer to make the decision to either succeed with or cancel the payment, and, a penalty to enforce that this decision is agreed on by everyone else in the payment chain. To enforce that the buyer makes the decision, the penalty should gradually decrease the amount that the buyer can cancel, thus forcing the buyer to either cancel, or seal  the payment (and when sealed  the payment will always succeed, one way or another). To enforce that either decision is agreed on by everyone in the payment chain, the same gradual decrease in the amount that can be cancelled will enforce the cancel agreement, and a gradual decrease in the amount that can be finalized will enforce a finalize  agreement (with the seal  agreement in between enforced by a combination of both effects, acting on either end of an intermediary).

These two penalty mechanisms, that can act on either a person's outgoing balance (the continuous finalization) or a person's incoming balance (the continuous cancellation), enforce agreements in every scenario, except when both the buyer and seller attack the system (i.e., both the buyer and seller deliberately cause the payment decision-making to get stuck). When both the buyer and seller attack, the two penalty mechanisms have no effect (the attacker ends up sending money to himself or ends up cancelling the full payment). To deter stuck decision  attacks in that scenario, fees are added on top of the payment, paid by the buyer to everyone else in proportion to how long the payment got stuck. These fees also have a secondary effect of compensating victims of a stuck decision , and the buyer also gets compensated at the same time because the attacker ends up paying the seller.

Most of you are familiar with Ryan's "late-receipt penalty". By 2010-2012 this penalty was the full payment, but earlier back in 2006 it was continuous with a "late-receipt penalty rate" (mentioned on https://sourceforge.net/p/ripple/mailman/message/1307752/). The "late-receipt penalty" solves a "stuck decision" problem when finishing the payment, it enforces that each hop (from the seller towards the buyer) propagates the decision to finish the payment. But, the use of a continuous penalty (a "penalty rate") required a decision that could also get stuck, so Ryan abandoned that idea (but he did not abandon the "late-receipt penalty", instead he made the penalty the full payment. Interledger later by 2018 tried to "fix" the problem with the full payment penalty by reducing the size of the payment, but this is not the right approach).

The problem introduced with the "late-receipt penalty rate" (that it requires a decision that can get stuck) is solved with a "late-cancel penalty", that is also proportional to the same "penalty rate". This "late-cancel penalty" is the exact opposite of the "late-receipt penalty". The "late-receipt penalty" reduces the amount that can be finalized, whereas the "late-cancel penalty" reduces the amount that can be cancelled. While "late-receipt penalty" acts on whoever is at the end of the payment (thus at first the seller and then the next hop, etc), the "late-cancel penalty" acts on whoever is at the beginning of the payment (thus first the buyer and then next hop, etc).

The "late-receipt penalty" is a form of "continuous cancellation" (i.e., it reduces the amount that can be finalized), whereas the "late-cancel penalty" is a form of "continuous finalization" (i.e., it reduces the amount that can be cancelled).

The "late-receipt penalty" is used to finish the payment and the "late-cancel penalty" is used to start the payment.

Conveniently, the decision to go from the "continuous finalization" during the "late-cancel penalty" step to the "continuous cancellation" during the "late-receipt penalty" step, is naturally enforced as well (if that decision gets stuck, there is a net penalty on the person that caused it to get stuck).

These two penalty mechanism, the "late-receipt penalty" defined by Ryan 19 years ago and the "late-cancel penalty" defined by me this spring (does anyone know if it has been suggested by someone else earlier?) provides the incentive for true decentralized multi-hop payments. As what Ryan envisioned with Ripple Inter Server Protocol.

These two opposite penalty mechanisms work in every case except when the attacker is both the buyer and the seller (naturally). To also deter that scenario, fees have to be added on top of the payment (that are paid out to each person in the payment chain, in proportion to how long the payment got stuck).

# Rules to deter "stuck payment" attack in multi-hop payments

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:

1) From the buyer towards the seller, where each node who propagated the decision then leaves the payment.
2) From the seller towards the buyer, where each node who propagated the decision then leaves the payment.
3) From the buyer towards the seller, where each node who propaated the decision stays in the payment.

These movements can be eforced with two mechanisms, that are used either alone or combined. These mechanisms are:

A) "continuous finalization", all nodes continuously finalize small "chunks" of the payment
B) "continuous cancellation", all nodes continuously cancel small "chunks" of the payment

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 three steps of a multi-hop payment

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.

# Rules to deter "stuck payment" attack in multi-hop payments

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:

1) From the buyer towards the seller, where each node who propagated the decision then leaves the payment.
2) From the seller towards the buyer, where each node who propagated the decision then leaves the payment.
3) From the buyer towards the seller, where each node who propaated the decision stays in the payment.

These movements can be eforced with two mechanisms, that are used either alone or combined. These mechanisms are:

A) "continuous finalization", all nodes continuously finalize small "chunks" of the payment
B) "continuous cancellation", all nodes continuously cancel small "chunks" of the payment

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.

# 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 or that if it was not it was the seller themselves attacking and then the seller cannot claim that they were not paid).

## Agreeing on the buyer fees  and cleanup rate 

Simplest is that the buyer/seller says what fee the buyer will provide as well as what cleanup rate  (how fast the continuous cancellation, continuous finalization and fee payout happens, i.e., how fast a stuck payment is cleaned up and the pending payment object removed), and select paths that accept these values. People then have a lower bound for what fee they accept and a lower and upper bound for what cleanup rate  they accept. Thus a selection system is formed between buyer and intermediaries. Since penalty system exists to deter attackers, people would generally work to set good norms  for those two parameters, collectively (although in a decentralized way).

## Illustrations

A payment of 1000 XYZ gets stuck at D during the seal  step (D is doing a stop-propagation attack  or there was a network failure). The penalty rate  is 1 XYZ per hour (thus a little more than a month for 1000 XYZ), and 100 hours have passed (roughly 4 days), during which the payment has been stuck at D ever since it timed out (and the period until timeout was maybe 5 minutes then after the payment had been started 4 days prior to the moment illustrated below). The buyer fees  are 2%, i.e., for the full payment being cleaned up  each person would get 20 XYZ and now that only 10% has been cleaned up  each person has received 2 XYZ. The buyer thus has a negative balance of 8, while the seller has received 102. The buyer has thus been compensated with 92 XYZ (as their payment to E always succeeds as long as the buyer issued seal  and the seller themselves is not the attacker). Each intermediary as well as the seller has received 2 XYZ from the buyer fees, and thus been compensated for the stuck payment. Note, 900 is the pending payment amount, thus 1000 XYZ minus 100 XYZ.

Another payment also at 1000 XYZ and also at penalty rate  1 XYZ per hour as well as buyer fees at 2% that has been stuck for 100 hours (roughly 4 days) because of a problem at D (either a network failure or an attack). Here it is illustrated that the buyer A has an incentive to cancel the payment - and should have done so 4 days ago the moment it timed out 5 minutes or so after it was started! It would go without saying that the buyer cannot issue seal  here as they never got the signal from the seller E that commit  succeeded (since commit  never succeeded, it got stuck at D &)

And then a payment example also of 1000 XYZ with 1 hour per 1 XYZ penalty and having been stuck for 100 hours (with a 2% buyer fee). This time, it is stuck at C during finalize  (either because of a network failure or because C is an _attacker_). If C issued finalize  at the moment shown in the illustration below, they would be left with a penalty of 94 XYZ. The reason the illustration shows -994 is because they already finalized 1000 XYZ, but 94 XYZ is the actual penalty they would receive if the penalty period ended in the moment shown below (i.e., if C issued finalize ). Note that the buyer has here been rewarded with 992 XYZ as their payment still succeed (the payment always succeeds as long as the buyer does seal  and the seller is not the cause of the stuck payment).

And a final example, where the payment got stuck at commit  (at D) but then the cancel  signal also got stuck (at B), both either because of a network failure or an _attack_. Here the buyer is not penalized at all. Instead, the penalty starts to affect B, thus it enforces the propagation of buyer cancels  perfectly.

## Implementation

This game theory is very simple to implement. As it centers around a ticker  that is just the machine clock, any recordkeeping about how much was cancelled or finalized or paid out as fee only has to be done when there is a state transition such as from commit  to seal  or if the full payment was cleaned up  (the ticker reached the full payment amount) and then via a separate cleanup_payment  command handler. The game theory most likely works for something like Interledger and it also works for the person-to-person money system Ripple (i.e., it should work regardless of what a node  is defined as).

## Agreeing on the buyer fees  and cleanup rate 

Simplest is that the buyer/seller says what fee the buyer will provide as well as what cleanup rate  (how fast the continuous cancellation, continuous finalization and fee payout happens, i.e., how fast a stuck payment is cleaned up and the pending payment object removed), and select paths that accept these values. People then have a lower bound for what fee they accept and a lower and upper bound for what cleanup rate  they accept. Thus a selection system is formed between buyer and intermediaries. Since penalty system exists to deter attackers, people would generally work to set good norms  for those two parameters, collectively (although in a decentralized way).

# 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).