After RipplePay in 2004, Ryan Fugger started working on a "Ripple Inter Server Protocol". His design ideas culminated in that the payment should finalize from the seller and towards the buyer (with "staggered timeouts"), enforced with a penalty for intermediaries who did not propagate the finalize signal. The penalty was the full payment (and as this was not acceptable, Ryan started to work on ideas for global commit registers instead).
Rather than using the full payment as penalty, as Ryan did, the size of the penalty can be reduced. Instead of letting the payment time out instantly, it can simply gradually reduce how much can be finalized, thus slowly penalizing an intermediary who does not propagate "finalize". This is conceptually trivial, but implementation is not entirely trivial. To use a reduced penalty, you first need to set up an agreement for the whole payment chain to start imposing such a penalty. To solve this, you need to rely on the fact that a "buyer cancels" signal can be enforced by a penalty as well.
Game theoretically, anyone who is in a net negative balance at a point during the payment can be forced to perform an action by the use of a penalty (I formally define this in
my whitepaper). This is quite easy to understand, and it is what Ryan Fugger made use of with his "seller finalizes" idea. With same penalty then, you can also enforce the agreement from buyer towards seller that everyone sets up the penalty system. This is enforced by that the penalty system acts on the buyer there (as they have the net negative balance) and thus forces them to cancel unless everyone agreed to "commit" to the payment (the seller is who signals the buyer when everyone committed...).
Thus "seller finalizes" and "buyer cancels" together with a penalty is the game theoretical foundation for how you can build a true Ripple Inter Server Protocol. "Buyer cancels" is necessary for the payment chain to agree to enforce the penalty, and "seller finalizes" is necessary to agree to finish the payment. In between those, you also need a signal to prove the buyer revoked their right to cancel (thus avoiding attack where "seller finalizes" and "buyer cancels" were issued at same time), this signal can also be enforced by the penalty system as such system was already set up during "commit" step.
A full implementation of these rules can be found on
https://bitbucket.org/bipedaljoe/ripple.
(The "penalty" itself is the users in the payment chain collecting fees in a process where cheating only impacts the user's own relationships. I.e., users who suffer a "reserve credit attack" simply pay themselves for the damage. This is fully implemented in my codebase. )
Note, besides the game theory for penalty as enforcement, you also need user-to-user consensus to solve two-general problem. This was mentioned by Ryan
as early as 2006 on Sourceforge forum and is not the hard problem for multi-server Ripple, but it is important nevertheless and also in
my whitepaper).
