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

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