History of Ripple from 2003 to the decentralized multihop payment coordination was solved in 2025

[Johan Nygren]

Ryan's invention in 2003/2004 was the idea to do accounting in edge only rather than both edge and vertice.


https://i.ibb.co/pjrjFD6B/ripple-graph.png

After RipplePay, the next step was Ripple Inter Server Protocol, and by 2006 the decentralized multihop payment coordination was a cancel-on-timeout 2-phase commit, with the goal of doing the timeout in "chunks" such that the penalty the timeout introduces would serve as an incentive but not detrimental. The problem with that 2-phase commit is that it only had a penalty on one of the phases (the 2nd phase), and when the penalty was made gradual the cumulative timeout got very long (Ryan referred to "daily penalty rate" in the old Source Forge mailing list) which undermines the timeout as the solution to "stuck payments" in the first phase - where there was no penalty. So Ryan hit a road block, and it was not possible to move past it.

Thus progress stopped in 2006. An attempt at a "hack" was done in 2008 with "staggered timeouts" but it did not fix the problem (and this is why Lightning Network today uses 7 hour delta timeouts...) Thus anything after 2006 was just running in circles, role playing that the problem was solved when it was in fact not. The problem had hit a road block, in 2006.

Fast forward to 2024. I then decided no one had finished Ripple, and I gave it a try myself (without having studied the cancel-on-timeout 2-phase commit from Ryan). I came up with a finish-on-timeout 2-phase commit, the other of the two possible ways to do a 2-phase commit. This approach seemed to work well, I realized it had a penalty on the first phase that should be done gradually (thus the timeout in "chunks"), but then I ran into the problem that there was no penalty on the second phase (i.e., the same problem Ryan ran into, but, from the opposite direction). I started to study Ryan's solution, and co-incidentally, I noticed that if you placed his solution after mine, with an extra phase in between to switch the timeout behviour from finish to cancel, you got a penalty on each phase and thus the "chunked penalty" could work.


https://i.ibb.co/SgdBxkf/example.png

With the decentralized multihop payment coordination finally solved after 20 years, it was easy to build Ripple Inter Server Protocol.

I decided to write a somewhat low-level and self-sufficient codebase in C, with more or less zero dependencies. It is less than 3000 lines of code, and works great. It prioritized simple, dumb solutions. It limits your trustlines to 16. It uses symmetric cryptography only, and only as "message authentication code". The rationale was: sometimes the dumber solutions are easier to agree on, since they are dumber. It is easy to build versions with elliptic curve asymmetric cryptography or anything else, but to start with, there has to be a proven reference implementation, and that is what I built.

The source code is on https://pastebin.com/C6qQPdph as one single file. Anyone can feed it into any AI to get things explained, and it is fairly easy to get overview of it all yourself since it is just 3000 lines of code. It is nothing.

For the multi-user version, see https://resilience.me/ for the code, it's a proxy with a web UI that runs the resilience.c binaries for each user. Works great. Anyone who wants a more sophisticated version can easily build it, my priority was dumb, robust reference implementation that can stand the test of time and preferences on what public key cryptography to use or anything else.

Ripple Inter Server Protocol has been finished since this summer (with an anti-spam feature added this fall) and works great. If anyone is interested in networking, I am available for correspondence. Or if anyone wants to grow the network on your own given the solution to decentralized payments now exists and has been formally presented and proven with implementation, also great.

Hope to see Ripple succeed, and possibly with my "path-based redistribution" (which is fully decentralized, no central agreement on how much you "donate", or pay in tax) as well.

Also note, the reason Ryan solved decentralized multihop, is specifically because all accounting was moved to the edges and vertices made "null". In such a system, it is entirely meaningless without solving the multihop part well (whereas a traditional system like SWIFT can still do the vertice-banking well, and the edge-multihop becomes more of an afterthought). So Ripple uniquely had no choice: solve it, or, be an entirely meaningless system. And Ryan solved half of it by 2006, and I added the other half in 2025. Why I solved it? I also had no choice. I had invented Resilience in 2012, and it required Ripple to work. Emergence by emergency...

Peace, Johan

[Jorge Timón]

I don't know it this is funny or sad.

You can keep telling yourself that lightning doesn't solve multi-op payments, you can keep lying to yourself and telling yourself you have aolved something that wasn't solved before. Bu, sorry, that doesn't make it true. I'm afraid you're just using LLMs to lie to yourself. Great tools, but can be dangerous too.

I hope your lack of humility combined with LLMs tendency to be extremely accomodating don't become a pronlem to you. I really do. Good luck, you're going to need it.

--
You received this message because you are subscribed to the Google Groups "Ripple Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rippleusers...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rippleusers/687bbee2-5f05-4ec4-b064-5fd4d73b5e16n%40googlegroups.com.

[Johan Nygren]

Jorge you requested I would not mention you, i.e., you did not want to be part of a public discussion. I presented the combination of "cancel-on-timeout" 2-phase commit and "finish-on-timeout" 2-phase commit (which causes a penalty to happen on every phase, and thus Ryan's 2006 idea of a "gradual penalty" becomes possible - the problem Ryan ran into was that the "gradual penalty" tended to lengthen the cumulative timeout duration, which undermined the timeout as a solution against "reserve payment attack"). I presented this at Stephen DeMeulenaere conference this summer in Austria, the presentation is public, https://www.youtube.com/watch?v=DVjMis02AE8, it was a joint presentation with Michiel De Jong (who solved a similar coordination problem for multi-lateral clearing using "chunked clearing". That coordination problem is simpler, but it is still a good discovery. Interledger who Michiel worked with while he also worked with RippleLabs also attempted the same approach (their "STREAM payments") but it does not work for multi-hop whereas it does work for multi-lateral clearing). Chris Cook also attended the conference, and I have corresponded with Chris occasionally since.

Ryan did incredible work. His invention is revolutionary. He got stuck in 2006. The idea to add "collateral" to the "payment channels" in Ripple, like Bitcoin or Ether, was also a revolutionary idea, but the fundamental game theory problem of how to coordinate a decentralized multihop payment was only half solved. Ryan had exactly half the solution in 2006, including the gradual penalty, but could not get it to work because there was only a penalty on one of the phases.

I am open to collaboration and correspondence with anyone interested, and as the formal protocol for the 3-phase commit is well defined and published and public, for example on https://resilience.me/3phase.pdf, anyone can also now build secure decentralized multihop including with "collateral" on their own (and anyone can also ignore me solving it, and solve it de novo, parallel evolution happens all the time).

You can either request to not be treated as part of a public mailing list and request "do not mention me", or you can engage in it. If you do both, you undermine your request to not be part of a public mailing list. It is nonsensical. Perhaps reflect on what motivates the nonsense. Is it that I am "pulling a trick" on you and the two logical ways to do a 2-phase commit with a timeout (cancel, and finish), if combined, adds a penalty on every phase and therefore makes it possible to use cumulative "chunked" timeouts (as Ryan wanted in 2006... see the Source Forge mailing archive...) without undermining the timeout on the phase that had no penalty? Or, did you simply overestimate how far along the technology was when you burnt out trying to (or hoping that ) Lightning Network had everything solved?

Is Michiel, Stephan, Chris perhaps and Daniel Levy in on the trick? Or, were you a bit quick to judge me based on your prejudice about me? Who knows. Maybe both are possible in theory but one seems a bit far fetched?

Peace, Johan