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

I have now built an interactive and animated simulation of the penalty
system: https://multihop.xyz/sim/.

With it you can try to attack at any step and with any node. It shows how
the penalty enforces a resolution of the attack. Built with generative AI.

For a very simple overview of the very simple rules that solve the "stuck
payment attack" in the ideal way and thus makes Interledger practically
possible, see https://multihop.xyz. Note it is somewhat the inverse of the
STREAM payment idea, I also reduce the size of the penalty at Ryan Fugger's
"finish from seller" (that Interledger and STREAM payments rely on) but I
do so in the opposite way, only if an attack occurs (rather than always)
and without requiring any extra transactions (whereas STREAM payments
requires a crazy amount of transactions).

The whole system is implemented for Ripple here:
https://bitbucket.org/bipedaljoe/ripple/, but can easily be used for
multi-hop payments regardless of what a "node" is, thus also for
Interledger with hash locks...

Peace Johan

Den tis 22 apr. 2025 kl 00:28 skrev Johan Nygren <johanngrn@gmail.com>:

> *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
>>>>>
>>>>