Re: Game theory that removes race condition from Interledger "universal mode"

*A very simple explanation:*

To move a decision from buyer towards seller where everyone who made the
decision leaves the payment ("buyer cancels"), gradually finalize the
payment.

To move a decision from seller towards buyer where everyone who made the
decision leaves the payment ("seller finalizes"), gradually cancel the
payment.

To move a decision towards seller where everyone who made decision stays in
the payment ("seal payment"), gradually cancel the amount in on buyer side
and finalize on seller side.

To compensate victims of "stuck payment attack", add fees on top of the
payment that goes to all users in proportion to how long the payment was
stuck (also deters attack where buyer and seller are both attacker). Note,
the buyer is still compensated during attack (if they are not the
attacker...) as fees are less than the penalty the attacker takes on
(seller still gets paid - unless they are the attacker - and attacker ends
up paying for this instead of buyer).

This is very very very very very easy to implement. I already did. It is
easier than it sounds. Only when a decision is made (cancel, seal,
finalize, cleanup) do the penalties get applied, until then the machine
clock tracks them naturally.

The updated article <https://ripple.archi/multi_hop_payment_game_theory.pdf>
also has illustrations of all this.

Den fre 18 apr. 2025 kl 15:36 skrev Johan Nygren <johanngrn@gmail.com>:

> A correction: the fees have to be agreed beforehand (otherwise "fake node
> attack" is possible) so the "distributed fee collection" described in my
> whitepaper does not work, but other than that the game theory can be the
> same. "Commit" state has gradual finalization, so that "seal" state with
> gradual cancellation puts the cost on the intermediary (avoiding
> "stop-propagation attack"), and since the "seal" state had gradual
> cancellation (though the part that is fees is still collected) the
> "finalize" signal is enforced ("stop-propagation attack" puts the cost on
> the intermediary not propagating it). The only difference from what I
> described before is that the fees have to be calculated prior to the
> payment (just like how interest rates have always worked in systems such as
> Interledger/Ripple etc). To explain it simply: the fees deter the buyer
> from "reserve credit attack", the continous finalization and cancellation
> deter intermediaries. The system actually gets easier with fees calculated
> beforehand. Johan
>
> Den ons 9 apr. 2025 kl 18:48 skrev Johan Nygren <johanngrn@gmail.com>:
>
>> Hi Melvin, as we discussed on Ripple Google group, they are
>> person-to-person. That I mentioned there that a central register could be
>> used for the "seal payment" if propagation failed was just a moment of
>> doubt from my side. The fees can enforce it person-to-person.
>>
>> Since the fees also work for "inter ledger" type system I thought I would
>> share it here too so that there can be more eyes on it. It is a win-win.
>> Plus I also like to have a functional Interledger "universal mode" but my
>> interest is definitely mostly Ripple since my Resilience system requires
>> person-to-person money. And the codebase is already finished as you know,
>> https://ripple.archi/code (or http://resilience.me/code for Resilience
>> added also but there I have not yet added the asymmetric fee for "seal
>> payment").
>>
>> The thing is, Interledger "universal mode" has more people interested in
>> it than Ripple (person-to-person money) and since they could also benefit
>> from my fee system invention (as far as I can see), it is better for
>> everyone.
>>
>> If you (or anyone else here) would like to have a video conference some
>> day on the fee system and go through if it seems to work or not I would be
>> happy to, or if you want to correspond over email or maybe this thread or
>> the one in the Ripple Google group or try and create some chat group around
>> it or meet and discuss it in real life somewhere.
>>
>> Peace, Johan
>>
>> Den ons 9 apr. 2025 kl 18:23 skrev Melvin Carvalho <
>> melvincarvalho@gmail.com>:
>>
>>>
>>>
>>> út 8. 4. 2025 v 17:02 odesílatel Johan Nygren <johanngrn@gmail.com>
>>> napsal:
>>>
>>>> Interledger "universal mode" is based on Ryan Fugger's idea to commit
>>>> the payment from the seller and towards the buyer (with "staggered
>>>> timeouts"), enforced with a penalty where the full payment is the penalty.
>>>> There is a race condition as the penalty is the full payment. This race
>>>> condition can be removed by reducing the size of the penalty, by making it
>>>> continuous once the payment has timed out (rather than an "all or nothing"
>>>> penalty).
>>>>
>>>> To set up a continuous small penalty instead of the full payment
>>>> penalty, two extra steps are needed. Here, what Ryan Fugger called "commit"
>>>> is instead called "finalize". The initial "commit" step is instead what
>>>> sets up the penalty. The "commit" signal moves from the buyer towards the
>>>> seller. If the commit step does not succeed, the buyer has an incentive to
>>>> cancel the payment. The incentive comes from that the buyer is the one
>>>> paying the fees. If "commit" reaches the seller, they inform the buyer of
>>>> this, and the buyer will formally revoke their right to cancel (leading to
>>>> the second added step, "seal payment").
>>>>
>>>> For "seal payment", the penalty rate is reduced once a user has
>>>> propagated the signal. This means that penalty is collected faster on the
>>>> buyer side of an intermediary who has not yet propagated "seal payment"
>>>> than on the seller side. Thus, the intermediary is left paying for the fees
>>>> (the buyer also has to pay some fees but this can be balanced to be much
>>>> lower than the intermediary attacker).
>>>>
>>>> Then once "seal payment" reaches the seller, they issue "finalize" (and
>>>> the same game theory as Interledger "universal mode" already uses comes
>>>> into play, albeit *without a race condition*).
>>>>
>>>> This is all formally defined with illustrations in my multi-server
>>>> Ripple whitepaper <https://ripple.archi/ripple-multi-server.pdf>.
>>>>
>>>> With this the dream of Interledger becomes possible as "universal mode"
>>>> no longer has the detrimental race condition. And, the dream of Ripple,
>>>> person-to-person IOU based payments via person-to-person trustlines, also
>>>> becomes possible (such platform I already built, see my website
>>>> <https://ripple.archi/>), and on top of Ripple also my redistribution
>>>> system Resilience (also built, see my website <https://ripple.archi/>).
>>>>
>>>
>>> commit, seal, finalize to where?
>>>
>>>
>>>>
>>>> Peace, Johan
>>>>
>>>