attempt to build true P2P Ripple

[Johan Nygren]

I suggest an architecture for Ripple Inter Server Protocol:
https://bitbucket.org/bipedaljoe/ripple

Single-hop consensus is needed for true Ripple Inter Server Protocol.

With it, secure multi-hop consensus can be done person-to-person, without central coordination. I think.

Single-hop consensus is easily done by the two users (vertices) of an account (edge) taking turns to "validate" every new decision. I call this mechanism "Lockstep".

[Johan Nygren]

payments now finished, still have to do credit clearing

8 user simulation available

summary available on https://ripple.archi/

[Johan Nygren]

neither RipplePay nor ripple.com seemed to do active credit clearing, as it happens indirectly anyway

so with payments done, my system has all main components finished

[cjen...@googlemail.com]

Evgeni Pandurski made a "Circular Multilateral Barter" fork before they tokenised Ripple & killed it

 https://the-eye.eu/public/Site-Dumps/campdivision.com/camp/Text%20Files/PDF/Computers%20General/Papers:%20Biotech-Programming/Circular%20multilateral%20barter.pdf

[Melvin Carvalho]

čt 27. 2. 2025 v 1:22 odesílatel 'cjen...@googlemail.com' via Ripple Project <rippl...@googlegroups.com> napsal:

Evgeni Pandurski made a "Circular Multilateral Barter" fork before they tokenised Ripple & killed it

 https://the-eye.eu/public/Site-Dumps/campdivision.com/camp/Text%20Files/PDF/Computers%20General/Papers:%20Biotech-Programming/Circular%20multilateral%20barter.pdf

I was not able to load that page, but it might be described here:

https://wiki.p2pfoundation.net/Circular_Multilateral_Barter

This was all before we had modern tooling and AI.  I do think we can build the true vision now.

I'd suggest using nostr, or something like nostr, for this, as it has realtime signatures.

Also a non-proprietary non-centralized version is needed, might like the orginal ripple.

 

On Wednesday, February 26, 2025 at 9:56:30 AM UTC Johan Nygren wrote:

neither RipplePay nor ripple.com seemed to do active credit clearing, as it happens indirectly anyway

so with payments done, my system has all main components finished

tisdag 25 februari 2025 kl. 21:28:47 UTC+7 skrev Johan Nygren:

payments now finished, still have to do credit clearing

8 user simulation available

summary available on https://ripple.archi/

fredag 21 februari 2025 kl. 23:06:08 UTC+7 skrev Johan Nygren:

I suggest an architecture for Ripple Inter Server Protocol:
https://bitbucket.org/bipedaljoe/ripple

Single-hop consensus is needed for true Ripple Inter Server Protocol.

With it, secure multi-hop consensus can be done person-to-person, without central coordination. I think.

Single-hop consensus is easily done by the two users (vertices) of an account (edge) taking turns to "validate" every new decision. I call this mechanism "Lockstep".

--
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/d72de0af-2dea-4593-9677-afc9d111ea7an%40googlegroups.com.

[Evgeni Pandurski]

https://swaptacular.github.io/

--

[Johan Nygren]

The premise of my design is that you have all missed the foundation of how to do Ripple Inter Server Protocol: that single-hop consensus is required.

And that you have tried to get it to work without it. But, then you never have certainty, so you end up with a mess.

Ryan Fugger is a genius and Ripple is a genius idea. RipplePay is well built. But it never managed to make the "leap" to Ripple Inter Server Protocol. Why? Ryan had no problem building RipplePay, but he had problem with Ripple Inter Server Protocol. Engineering-wise the latter is not harder, and Ryan is (I think) a skilled engineer. But, the latter required something that was not yet realized. Without it, you end up with a mess, as you can never have certainty. Ryan started to look more at Nakamoto consensus (as it solves the problem at a large scale), and suggested in later designs of Ripple Inter Server Protocols to use commit registers that ran Nakamoto consensus (i.e., "blockchains". ) From there, it was logical to move the whole thing to a central ledger - as that did solve the certainty problem and did make an improvement over just RipplePay, but it was not Ripple Inter Server Protocol. What was needed was just to take Nakamoto consensus (i.e., take turns being "general") down to the smallest scale, which is what Lockstep is.

Evgeni Pandurski: does your design solve single-hop consensus or not? I assume not. I can dissect your codebase with generative AI to know for sure, or you can tell me.

cjenscook: why do you choose to completely ignore what I shared. Is it because it is meaningless. If it is, could you point out why. You do not have to, if it is meaningless then ignoring is valid. I disagree it is though, and I suggest people, probably you included, have for 15-20 years or so missed fundamental piece for how to build true Ripple

Melvin Carvalho:  nostr does not solve single-hop consensus so you are missing the fundamentals. Sure you can use asymmetric signatures instead of symmetric like I use. This is not a hard part, it is a problem anyone could solve for 15-20 years. But none of you seem to have built a functional Ripple Inter Server Protocol. Why is that, is a more interesting conversation. And I suggest it is because you all have a web mentality mindset and you acknowledge important things like good signature frameworks but you miss the most important thing: trust, how to agree, and be certain.

I could be wrong, this is my best judgement, the codebase I have produced works, it is well written, it does everything. And it is very simple. Ripple Inter Server Protocol is very simple as long as you have the single-hop consensus.

[Johan Nygren]

cjenscook/Evgeni Pandurski: swaptacular does not seem to even be multi-hop, does not seem to be Ryan Fugger's Ripple.

"CMB" seems to be conceptually the "community bank" concept, and this is reflected in your attempts to implement the computer infrastructure for it

in your "swaptacular" your "account authority" seems to be the lowest level of "consensus", and it seems to conceptually be a "bank" that can have many creditors and also debtors. thus it is a "vertice" in the graph with many "edges" rather than as in Ripple a single edge. and sure, if you do one per relationship you get something similar to Ripple but your implementation is not based on that, as far as I can see. thus mentioning it for Ripple Inter Server Protocol designs is not right.

your "banks" can clear things in circles, but so can any bank in history no? do they not all do that? the idea with Ripple is to take that process down to the person level in terms of trust. this is what makes it possible to implement the computer infrastructure in a truly decentralized way. and how to do that, I have shown.

however you do "consensus" in the clearing between many banks, it seems to have separate limits. a separate system. trust managed in a separate way ("reputation" rather than person-to-person maybe). this is what Ripple solved, it unified it, but you instead need bank-to-bank which already exists in the banking system since millennia.

I could be wrong, but this is what it seems like to me

[Evgeni Pandurski]

You are right. Swaptacular is very different from Ripple. I believe it takes a much more practical approach. And, yes, most of the principles it is based on are known for a very long time, and are proven to work.

I would say that Swaptacular is "Open central banking for the masses", without any high-tech crypto nonsense.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/bd03a450-4477-4f09-93f6-84ec4dad4db3n%40googlegroups.com.

[Johan Nygren]

Evgeni Pandurski:  re: "without any high-tech crypto nonsense."

person-to-person money (Ripple) actually has the least needs for "high tech crypto". any system where you delegate trust there is benefit from oversight (asymmetric signatures, data trails such as "chain") and distribution of control (validator alternation by some election such as cpu-vote or people-vote). but in Ripple you do not delegate trust, you are your own bank. for real. uniquely, in history, a true innovation.

[Evgeni Pandurski]

I believe money is a social tool based on trust, not a lone-soldier thing.

There are two ways trust can go wrong: too much trust, and no trust.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/4f66f93b-1ec1-4b64-b266-da3922d5ed59n%40googlegroups.com.

[Johan Nygren]

Evgeni Pandurski: re: "I believe money is a social tool based on trust, not a lone-soldier thing. "

I believe this is the Ripple group founded around the ideas Ryan Fugger developed. So it could be a lowest common denominator in it. Ripple is not "no trust" it is trust at person-to-person level. And if your comment is a critique on "crypto" (because of ripple.com implementation for computer infrastructure to run the Ripple money system, with XRP as "GAS" used similar to Ethereum, anti-spam) - Ripple has absolute lowest needs for verifiable public proof, your ideas (that seem to be the traditional way to do banking, which is a social system based on trust in communities such as countries rather than person-to-person) have much higher needs for it. And "crypto" (Nakamoto consensus type systems) is not "no trust", this is just a myth. It is a majority ruled system, where you trust the majority stakeholder, that with cpu-vote is compute power, coin-vote is plutocracy and people-vote is traditional democracy.

[Evgeni Pandurski]

You are right. This is the Ripple group, and I do not want to troll.

Here are my observations about trust:

1. Person to person trust is not enough to maintain complex societies.

2. Social trust is a dynamic fragile thing, which must be constantly created and destroyed.

3. Neither Ripple, nor Bitcoin and the likes, provide a good framework for constantly creating and destroying *social trust*.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/0d9ca936-9a8f-4f8a-a783-081e7079d227n%40googlegroups.com.

[Johan Nygren]

Evgeni Pandurski: re: "Here are my observations about trust:"

in Ripple, uniquely, "consensus" can be at the "edge". whenever the bank is not person-to-person, consensus needs to be at the bank. like in your swaptacular, where you computationally cannot decentralize below your "bank".

historically, person-to-person money was not been practical to maintain a complex society.

Ripple is unique, historically.

since it is unique, people miss that only the "edge" needs consensus. also Ryan Fugger missed this when trying to design Ripple Inter Server Protocol, I think. I here demonstrate that "edge" is only level that needs consensus, and publish it on https://ripple.archi

and I welcome this Ripple group to a conversation about consensus-mechanism-only-at-edge-level as what has been missing for RISP

[Evgeni Pandurski]

The problem I have with the original Ripple concept (and the crypto currencies for that matter) is the method new money gets created.

With Ripple we can have a completely dis functional society of "trusted friends" which will issue trust/money to each other like there is no tomorrow.

With crypto currencies the issuing of new trust/money is determined by other factors, completely independent of real processes in the society.

Say what you want about the banking system, I am no fan of them, but at least the issuing of money there is governed by more or less real social and economic processes.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/f3da2f12-6fd7-45ee-a0a5-f1ecbd960daen%40googlegroups.com.

[Johan Nygren]

Evgeni Pandurski: re: " The problem I have with the original Ripple concept "

I like Ripple, I disagree with you. I open this forum post to invite the Ripple group - where reasonably Ripple is a lowest common denominator - to a conversation about "edge-level-consensus-mechanism-only". Assuming my ideas about it might be a bit innovative or at least not widely known about (others probably had same ideas but maybe not spread them). The codebase I built is complete (has all main mechanisms), just 4000 lines of code, good simulations anyone can run to prove it. Can be used already today. It is simple since Ripple is a very simple system. Beautiful in that way.

Ripple Inter Server Protocol built on a single-hop synchronization mechanism: https://ripple.archi/

[Michiel de Jong]

Hi Johan (and bringing this sub-thread back to the list as you requested),

Thanks for your explanation!

First of all, please note that RipplePay was renamed to RumplePay in 2020.

You might similarly consider renaming https://bitbucket.org/bipedaljoe/ripple to something else. I welcome your intention for subscribers of mailing lists like this one to build a single project together, instead of your project being an alternative to other similar projects, but I think naming that common goal "Ripple" is confusing.

In the blog posts I mentioned, you will hopefully already have found links to Interledger, SNAP, LedgerLoops, and also terms I tried to coin at the time for our common goal, like "Network Ledger Technologies" and "Network Money".

More recently, a movement has started that is called "Collaborative Finance". It brings together projects like Cycles Money, MyCHIPs, my own project LedgerLoops, and many others.

I will not try to convince you that LedgerLoops can do all the things your project can do, but let's instead try to make our projects interoperable with each other!

For this, I think there are 3 important chunks to consider:

Routing

How does the network find a payment route or detect a circular netting opportunity? There can be multiple competing mechanisms working on the same network without problem, independently suggesting loops and routes to users, just like the world-wide web has multiple competing search engines, independently suggesting hyperlinks to web users.

Bilateral ledgers

As I said, I like your Lockstep protocol in which the two parties take turns at being general. It feels similar to the SNAP protocol which Bob Way and I developed in 2018. So you're not the only one who thinks that single-hop consensus should be solved before multi-hop can work! :) In SNAP, it is always the Payer (the party whose balance goes down) who is "the General", in your terms. They decide what their next outgoing transaction is, and will keep repeating it until the payee has ACKed it. See the 'messaging' chapter of https://michielbdejong.com/blog/20.html. I think this has some advantages when dealing with balance limits, so I will personally prefer SNAP over Lockstep when setting up a trustline with someone, but if someone sends me a connection request of some sort to set up a Lockstep trustline, then I will be totally fine with using Lockstep on the trustline with that particular friend. As is shown with Interledger's plugin system, where one trustline in the network might be implemented using Bilateral Transfer Protocol (BTP), another with Lockstep, and another using a blockchain-backed payment channel between two parties, and under the right conditions, a multihop Interledger payments would still work across those hops, despite the differences in implementation of the single-hop trustlines.

So instead of picking your Lockstep protocol as "the" protocol for everyone to use in all p2p credit network transactions, I suggest we work together to maintain the list of available single-hop protocols and links to their implementations.

Two-phase commit

This is the part I previously didn't understand from your whitepaper, so thank you for clarifying.

I have been reading your docs and code. One thing I don't understand is:

* It seems the result of the "Set trust: C->D=400000 (asym)" step is not visible in this diagram. Is that because its result is overwritten by the "Set trust: C->D= (lowest fallback) 10000" step?

* I don't understand whether your implementation of multi-hop offers any protection against malicious or malfunctioning actors. Suppose node F in https://ripple.archi/web.png truthfully cooperates in the discovery of the route G -> H -> D -> C -> F -> E -> A -> B, but then when it's time to forward the money, it cooperates with C to receive the 2500 units from C, but it doesn't cooperate with E to send 2500 units to E. In other words, how do G and B get a guarantee from the network as a whole that the money that G pump in, actually comes out (within some reasonable time limit) on B's end? Nowadays, most message-based Network Ledger Technology systems, like Interledger, MyCHIPs, LedgerLoops, Bitcoin Lightning, and others,  use SHA256 hashlocks to implement the two-phase commit: the promise specifies the SHA256 hash of a secret string. The commit message coming back carries that secret as the delivery receipt. See the 'multihop' chapter of https://michielbdejong.com/blog/21.html. Does your system use conditional transfers as well? I couldn't find that in your code base.

There are some differences in how different multi-hop protocols achieve finality; Interledger uses timeouts, MyCHIPs uses referees, etc. Most multi-hop systems require each trustline to support SHA256-based conditional transfers with timed rollback. Some routing algorithms also take into account liquidity and exchange rates, while some others require a single pegged currency. So we still have some way to go before we can truly federate all our systems at that level, but I think it's a worthy goal. I will try to add Lockstep as one of the supported protocols in my system and it would be fun to do some federation tests that way.

 

Again, happy to jump on a video call to dig into this more with you! And it would be great if you could make it to the upcoming CoFi conference in Austria in June - we could chat much more in-depth about your system there!

Cheers,

Michiel de Jong

On Thu, 27 Feb 2025 at 09:27, Johan Nygren <joha...@gmail.com> wrote:

Hi Michiel, I am happy to correspond over video or text, but maybe we could take the conversation to Ryans forum first.

I suggest that single-hop consensus has been "missing piece".

If I am right, it explains why Ripple did great progress in 2003/2004 when Ryan Fugger invented it, and he easily built RipplePay.

But, why it then kind of just went around in a circle for years with attempts to come up with architecture for Ripple Inter Server Protocol.

Why the ideas for RISP always changed.

It is simply impossible to design it if you do not have single-hop consensus guaranteed, is my premise.

If I am right, it adds some certainty to the problem of "how do we get the real Ripple... "

Also, I already built it, the codebase is complete. It already works. You and I can already have our own Ripple servers and interact in a true RISP way.

What do you think - try and have conversation as "community" (Ryans Ripple group community) first and maybe later on we can correspond over video or something.

Chime in in the forum thread if you want to try and steer conversation towards some kind of certainty.

As for the payment steps, I derive them from the "fundamentals" I describe in the whitepaper.

Once path has been agreed on "lightly", the lockstep steps are:

Buyer -> Intermediaries ->  Sender: LOCKSTEP_COMMIT_PAYMENT
Sender  ->  Buyer: COUNTERPART_FINALIZE_PAYMENT
Buyer -> Intermediaries ->  Sender: LOCKSTEP  _FINALIZE_PAYMENT

And that is it. With single-hop consensus you have guarantees that make it simple.

Peace /Johan
also invented https://bitpeople.org and Resilience...

Den ons 26 feb. 2025 kl 19:07 skrev Michiel de Jong <mic...@unhosted.org>:

Hi Johan,

Great that you're working on this! Looks like you're making some good progress with the code. I must admit I understand your single-hop protocol "Lockstep", and I like it! I don't fully understand how you do multi-hop, would you be available for a video call so we can talk through it? I would love to learn more about your work.

I have been involved in several similar projects, including LedgerLoops, Interledger, and Credit Commons. Here are some of my older blogposts about the topic:

https://michielbdejong.com/blog/20.html

https://michielbdejong.com/blog/21.html

Cheers,

Michiel de Jong

--

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/f22fdd96-9cd4-44d8-8110-0d8a91ed9b66n%40googlegroups.com.

[Johan Nygren]

Michiel de Jong: re: "I think naming that common goal "Ripple" is confusing."

Ripple is a money system invented by Ryan Fugger in 2003/2004. This is the Ripple group based around that.

I was hoping you would be interesting correspondence since you reached out to me, but you start off with bullshit. The lowest common denominator here should be that Ryan Fugger invented a money system in 2003 and 2004 that is well defined and easy to understand. He did so as a genius. It was a genius idea. So far, no one has - as far as I know - managed to realize his vision of a Ripple Inter Server Protocol. People - with less vision - instead cause a lot of noise and pretend to know what they are talking about. I think what he was missing in was that every "vertice" (user) can run on their own server (if they want to), and their "edges" (account) to other "vertices" can operate as if it was on a single machine, by using validator alternation. This is analogous to what Satoshi came up with at the mass-scale, just taken down to the smallest possible level, as what Ryan did was take money and banking down to the smallest possible level.

Some answers to your correspondence:

re: " How does the network find a payment route or detect a circular netting opportunity?"

it founds a route by searching from two directions, sqrt(single_direction) queries. it does "ping pong" and increments of one depth at a time. it uses random identifier for a search. when it collides in the middle, path is found. it then runs command handlers as you see in the simulation. very simple.

it does not detect circular netting since RipplePay did not either, you get "circular clearing" indirectly. i was not aware of that actually until a few days ago, for 13 years now I assumed RipplePay or ripple.com did "circular clearing" periodically.

re: " In SNAP, it is always the Payer "

Agreeing that one side is always "general" also works but alternating is better. But, that it is "always payer" does not work since account work both ways. it has to be always one for everything if you use that approach.

re: " They decide what their next outgoing transaction is, and will keep repeating it until the payee has ACKed it."

does not sound at all like my validator alternation approach. Validator alternation is also what Satoshi (Craig) used to manage consensus, it is the logical way to do it.

re: " . I think this has some advantages when dealing with balance limits, so I will personally prefer SNAP over Lockstep when setting up a trustline with someone"

you are missing the point that they need consensus on the account. you cannot just switch ways to do that all the time, then you do not get consensus.

re: "blockchain-backed payment channel "

this is unrelated to Ripple, this is the Ripple group

re: "It seems the result of the "Set trust: C->D=400000 (asym)" step is not visible in this diagram. Is that because its result is overwritten by the "Set trust: C->D= (lowest fallback) 10000" step?"

yes. meaningless but the generative AI added that and seemed to think it was clever, I let it stay in

re: "I don't understand whether your implementation of multi-hop offers any protection against malicious or malfunctioning actors. Suppose node F in https://ripple.archi/web.png truthfully cooperates in the discovery of the route G -> H -> D -> C -> F -> E -> A -> B, but then when it's time to forward the money, it cooperates with C to receive the 2500 units from C, but it doesn't cooperate with E to send 2500 units to "

that is not an attack vector.  the commit phase is not final. if the commit "signal" fails to go from buyer to seller, the payment times out, and the buyer cancels. nothing happens.

re: " In other words, how do G and B get a guarantee from the network as a whole that the money that G pump in, actually comes out "

commit signal reaches from G to B

re: "most message-based Network Ledger Technology systems, "

those are not related to Ripple, this is the Ripple group. they use hash locks because those are public ledgers with completely different trust model. it is not comparable. you use the hash lock to do something on that public ledger, not just for some kind of "inter ledger" thing. the lock is for intra-ledger. only meaningful reason to have "commit-reveal" in true person to person Ripple is to avoid a very far fetched attack. such attack is not realistic, and defending against it has nothing in common with why you use hash locks when making agreements over two or more ledgers except they happen to be commit reveal.

Overall you seem to not really understand Ripple.

Message to anyone:

For anyone interested, since each account in Ripple is an edge between two vertices that are users, a true Ripple Inter Server Architecture can be built by using validator alternation between the users of an account. This lets everyone run their half an account on their own server. I built such an architecture already with https://ripple.archi, at "link layer" people can use whatever signatures and such they want, at "network layer" just need consensus on the multi-hop things, such as 

[Johan Nygren]

Michiel de Jong:

I'm happy you look at the simulations, but it is important that the Ripple group is able to agree that Ryan Fugger invented a money system in 2003/2004 named Ripple.

Fundamentals for Ripple Inter Server Protocol are: if users should be able to run their own server, accounts need validator alternation between two people - or, one account needs to be made the always-validator (this is very unnatural and makes things more complicated). Without this, it is not possible to securely do Ripple Inter Server Protocol. Validator alternation is extremely easy to do. The codebase for it is extremely small.

[Johan Nygren]

On the topic of hash locks that Michiel de Jong mentioned: I think hash locks are extremely useful in public ledger systems like Ethereum. I also think public ledger systems like Ethereum (that will evolve to people-vote rather than coin-vote or cpu-vote) can co-exist with decentralized systems like Ryan Fugger's money system Ripple. But for a true Ripple Inter Server Protocol, each user ("vertice") able to run their own server (if they wish) and an account ("edge") being distributed across two users by using validator alternation - analogous to how Satoshi (Craig) solved things with Nakamoto consensus - I see only need for commit-reveal if a "fake recipient attack" is possible. In my design, the buyer and seller have a direct communication channel (see code here), so the buyer knows that the recipient is being involved in the payment. Thus, "fake recipient attack" is prevented by the direct channel. If I did not use a direct channel, I would probably use commit-reveal instead, but for reasons very different from how hash locks are used in public ledgers. The direct channel between buyer and seller is fundamental to how I do path finding ("ping pong" that optimizes for minimal depth, see code here), and so it was already in the system. I want to respectfully address any questions or concerns, but I would also like there to be a signal in the noise. That the best ideas can get some focus here. If what I built for a year is that signal, it would be good to be able to have a conversation about it here in the Ripple group (and if my ideas are shit, it would likewise be good for them to be ignored). My long term interest in Ripple is "swarm redistribution" that I invented in 2012, and I also designed and built https://bitpeople.org and a people-vote consensus engine with my foundation, https://panarkistiftelsen.se/kod/panarchy.go (similar will be used by all countries in the world within a decade or two most likely, my long term interest is for a global "digital nation-state").

If I am wrong about need for commit-reveal in RISP I would be happy to be called out. Just trying to have a conversation so the best ideas can get focus, so that a true Ripple Inter Server Protocol can exist in the future, and the true potential of the internet can change the world forever.

[Johan Nygren]

An attempt to address the idea that person-to-person commit does not work and "commit registers" (therefore hash locks) are needed (mentioned here and here, and  Michiel de Jong also seemed to mention it). It seems to me this problem is exaggerated due to another problem (account consistency between two users on separate servers) being ignored.

In person-to-person commits you do permanent commits (my RISP does this). The damage that a "stuck commit" can cause, is a "garbage collection"-type issue. It can get stuck in two steps:  COMMIT_PAYMENT A->B->C->D->E (where it can be cancelled from either A or the front, thus, "stuck commit" requires both ends fail). Or  FINALIZE_PAYMENT A->B->C->D->E (where once A has issued the command, no one can cancel). In COMMIT_PAYMENT, anyone with a "stuck commit" will have a net neutral pending balance (same in as out), and just be stuck with a "garbage collection"-type problem (they cannot remove their pending payment object and write it to their balance). In FINALIZE_PAYMENT, only A has a net negative balance and A never gets "stuck" as they had the right to cancel until they executed FINALIZE_PAYMENT on their account with B. Thus for accounts  BC, CD, and DE, it is just a "garbage collection"-type problem.

I acknowledge that such a "garbage collection"-like problem is a problem. But it does not at all seem like a deal breaker. It seems to me that the bigger issue of account state consistency has been the main obstacle, but, not addressed and instead "stuck commits" got the attention for the past 10-15 years.

I could be wrong. My RISP works, it is built. A segment that gets cut off from two ends has ways to manage their "garbage collection" still. It just seems to me like a relevant technical problem that has to be addressed technically has been blown out of proportion to become an impassable obstacle, when in fact the true obstacle was lack of consensus at "edge" (account) and this obstacle is solved by same approach Satoshi (Craig) used in 2008: validator alternation, here between just two users.

[Johan Nygren]

Why this community seems to have dismissed person-to-person commits. Back in 2006 in the Sourceforge Ripple forum Ryan Fugger was emphasizing that you need a transaction chain per account with guaranteed consensus (link). This is after successfully building Ripple on a single server with RipplyPay with no problem.

"2006: Both parties to an account must be able to maintain a record of messages, signed by the other party, that can be used to establish the balance at any given time.  This leaves no room for disagreement." "Maybe there's a better approach to handling account changes than having a separate set of messages and interactions for each piece of data we can imagine ever being useful in an account (because inevitably, people will want to add more).  " "Any change to any account field must be agreed to by the nodes themselves and signed and dated messages to that effect made available to both. " "Does that appeal to anyone?  Any problems with this scheme?  (I had something like this in an early version of the protocol -- who knows why I took it out...) Ryan"

I am assuming this idea was then dismissed. Early on in the Sourceforge forum there is also discussion about that authority can be unilateral. It cannot, for balances in Ripple it has to be bilateral (both users of an account), but it is easy to get the idea it could be unilateral (i.e., that the person receiving IOU can be the single authority). It is attractive to try and resolve two-general problem by assuming that authority in Ripple is inherently unilateral. If it were, you would then need for the "final authority" in payments to be from the seller to the buyer. Because then each "hop" is that assumed "unilateral authority", the receiver of an IOU. But, the issue here is: authority in Ripple has to be bilateral.

So, the two-general problem can be ignored if it is assumed that an account in Ripple is inherently asymmetric in authority. Unilateral.

In Ripple you have consensus at two levels, multi-hop, and single-hop. It is attractive when trying to build it to rely only on the multi-hop principles, to achieve account consensus with the same mechanism as multi-hop consensus. For multi-hop "two phase commit" is enough. It is attractive to assume this same "consensus" can also resolve the single-hop issue. But it cannot since a balance in Ripple is singular in account, authority has to be bilateral, you need what Ryan Fugger mentioned in 2006, a transaction chain per account. "Lockstep" in my RISP is probably ideal way to do that, and from there it becomes easy to design reasonable multi-hop payments and these do not involve "seller finalizes", the buyer is the only one with a net negative balance and thus they are the last with the right to cancel and they are the one who finalizes.

So what about "Swaptacular"? Well it is not Ripple. It is not comparable. It is more of a "community currency". It has unilateral authority over balances, since it is not Ripple it is more like a bank system. Therefore it does not need to resolve the issue you need to resolve to build RISP. And this can be "attractive" too as resolving problems requires work and "shortcuts" can seem attractive.

I am trying to meet half way with the community here. And to address what I think you may have gotten wrong for 15 years, and how re-thinking it could make it very easy to build a RISP - I already did, it already works: https://ripple.archi.

If I am wrong at some fundamental level, and for some reason, skipping account consensus, reversing the way payment routing logically should be done, and relying on principles that can be rationalized by how they also allow "interledger" (hash lock based) interaction (although with the race condition issue that actually is serious if there are faults, in contrast to stuck permanent commits that are just "garbage collection"-type problem) is a good idea, then I would hopefully be able to see that eventually. If I am right, others may hopefully be able to see that eventually.

Michiel de Jong also emphasized the "upside down" approach to payment routing was needed and that the solution to problems was to instead stop using the term Ripple and call things "network money" but I think it is better to address the root problem.

Peace Johan

[Johan Nygren]

What went wrong with Ripple Inter Server Protocol from 2006 to now:

It was agreed maybe around 2010 (possibly earlier) a "distributed race condition" was needed for payment finalization, and since this was insecure, it was agreed that a "global commit mechanism" was needed. From there, the step to just place everything under global consensus (ripple.com) is very small (and note the "distributed race condition" design is fairly logical for non-trust systems like Interledger).

The problem that rationalized this, was the "reserve credit attack":

"The problem is that transactions must be allowed to time out, otherwise it is easy to attack the network by reserving credit and never releasing it. " (Ryan Fugger, 2012)

I suggest this attack vector was exaggerated because of other problems, mainly not solving the two-general problem (without solving two-general problem, certainty is impossible, and therefore ideally avoided...)

So what about the "reserve credit attack"?

It is an attack without leverage. The buyer would be the attacker, but the "pending payment objects" exist to protect the buyer as they are the only one with a negative balance. So it would be like placing your hand in front of a gun and then pointing to threaten someone who is standing behind bullet proof glass. There is no leverage and the attacker is the one in the line of fire (and identifiable...). It is a nuisance-type attack more than an actual position to coerce the network. It is not system-breaking. It is a valid discussion just like discussing "should people be allowed to carry scissors in public or not" but the existence of the "scissor attack vector" does not mean society is broken. It is a very small problem and a manageable problem, a relevant problem but not something that breaks society.

If I am wrong, I would be happy to be called out (or ignored). But, RISP never happened and it has been over 15 years. I built it now over a year. It works. It is very simple. And the foundation of what I built is a solution to the two-general problem, so there can be certainty, so it is possible to reason and come up with an architecture for RISP. I did and I built it: https://ripple.archi.

/Johan

[Johan Nygren]

Final Statement

My Ripple Inter Server Protocol version (https://ripple.archi) assumes the "reserve credit attack" is manageable. If it is then Ripple can be 100% person-to-person, computationally, I think.

If it is not manageable and breaks the system then that has been addressed by Ryan Fugger and this community for 15 years, and it motivates some kind of payment-chain wide consensus ("global commit mechanism").

[Johan Nygren]

I publicly apologize for my wrong analysis last week.

Since Ripple is not at person-to-person level agreement-wise but at payment routing level, payment routing level consensus mechanism ("global commit mechanism") is logical.

(I still like the person-to-person-only consensus approach. I think it is a step-up from single-server approach like RipplePay, and I am not aware of many multi-server Ripple implementations, or, I am not aware of any other, but maybe those exist and I just do not know about them. I like the extreme simplicity, and that it requires symmetric cryptography only. I think the "reserve credit attack" could be manageable, socially. My platform is already built and it already works and it is just 4000 lines of code with more or less zero dependencies. Any computer engineer could recreate it from scratch with minimal work - sha256 is the only part that would be hard to build from scratch. My platform does not need certificate authorities - all authentication is user-to-user, not globally per server. The bidirectional path finding is probably very efficient. The UDP+Retransmission is efficient. The consensus mechanism Lockstep is minimalistic and has perfect consensus. But I made grandiose and wrong statements, as the logical true version of a Ripple Inter Server Protocol probably does payment routing level consensus, as this community has recognized for 15 years. And I apologize for that here. And since I want to see a true Ripple Inter Server Protocol built, and this community has been on the right track, I want to apologize and I want to mention payment routing consensus mechanism as maybe being what has been missing.

Payment routing consensus mechanism

Multi-general problem requires a single general ("validator"), and can also use validator alternation. Same concepts as Nakamoto consensus. 51% majority rule.

Every node (account or user, probably ideally account) in the payment chain is a validator. Validators produce blocks, have "slots" with X units of time, the block chain with the most signed slots is canon (my people-vote consensus engine also uses that).

Everyone can commit, and until everyone has committed, anyone can cancel. There is a singular (one-time-use) block chain, everyone is in agreement.

Comparing with previous ideas for Ripple Inter Server Protocol

With payment routing consensus mechanism, there is no "distributed race condition". Historically this community saw a problem ("reserve credit attack"), created a solution ("distributed race condition"), the solution created a problem ("stuck commits"), that problem motivated another solution ("global commit mechanism"), and it seems to me that other solution meant the first solution ("distributed race condition") was then actually redundant.

Johan

[Melvin Carvalho]

út 11. 3. 2025 v 11:10 odesílatel Johan Nygren <joha...@gmail.com> napsal:

I publicly apologize for my wrong analysis last week.

Since Ripple is not at person-to-person level agreement-wise but at payment routing level, payment routing level consensus mechanism ("global commit mechanism") is logical.

(I still like the person-to-person-only consensus approach. I think it is a step-up from single-server approach like RipplePay, and I am not aware of many multi-server Ripple implementations, or, I am not aware of any other, but maybe those exist and I just do not know about them. I like the extreme simplicity, and that it requires symmetric cryptography only. I think the "reserve credit attack" could be manageable, socially. My platform is already built and it already works and it is just 4000 lines of code with more or less zero dependencies. Any computer engineer could recreate it from scratch with minimal work - sha256 is the only part that would be hard to build from scratch. My platform does not need certificate authorities - all authentication is user-to-user, not globally per server. The bidirectional path finding is probably very efficient. The UDP+Retransmission is efficient. The consensus mechanism Lockstep is minimalistic and has perfect consensus. But I made grandiose and wrong statements, as the logical true version of a Ripple Inter Server Protocol probably does payment routing level consensus, as this community has recognized for 15 years. And I apologize for that here. And since I want to see a true Ripple Inter Server Protocol built, and this community has been on the right track, I want to apologize and I want to mention payment routing consensus mechanism as maybe being what has been missing.

Payment routing consensus mechanism

Multi-general problem requires a single general ("validator"), and can also use validator alternation. Same concepts as Nakamoto consensus. 51% majority rule.

Every node (account or user, probably ideally account) in the payment chain is a validator. Validators produce blocks, have "slots" with X units of time, the block chain with the most signed slots is canon (my people-vote consensus engine also uses that).

Everyone can commit, and until everyone has committed, anyone can cancel. There is a singular (one-time-use) block chain, everyone is in agreement.

Comparing with previous ideas for Ripple Inter Server Protocol

With payment routing consensus mechanism, there is no "distributed race condition". Historically this community saw a problem ("reserve credit attack"), created a solution ("distributed race condition"), the solution created a problem ("stuck commits"), that problem motivated another solution ("global commit mechanism"), and it seems to me that other solution meant the first solution ("distributed race condition") was then actually redundant.

Johan, you've made a lot of very interesting posts to this list.  While fascinating, I personally am finding it hard to take in all of it.

Would you consider making a single high level summary of the different points.  I am interested in helping, if there is a high level plan and next steps.

 

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/9a310920-dece-4d05-8980-8555de76227en%40googlegroups.com.

[Johan Nygren]

Let’s all try and centralize the discussion to my last thread Multi-server Ripple is easy, I already built it, you all got it wrong where me and Melvin have continued the conversation. For the high level summary a good start is to audit Ryans claim that the lock-credit-attack is not manageable with person-to-person-consensus-only and thus is a rationale to pivot to global consensus. To me this claim seems false as you can easily manage it person-to-person with fees and this is implemented already in my https://ripple.archi. But easiest to centralize this discussion to one thread. Thank you Ryan for inventing Ripple. Peace, Johan, inventor of Resilience.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/CAKaEYhKvCu6o_nCjWFuz-o5r%2BX2hUeiyNObwnKrzf7VKiJMyjw%40mail.gmail.com.

[Jorge Timón]

Presumably by "crypto nonsense" you don't mean cryptography, but cryptocurrencies.

After all, I think you yourself are using cryptography in your project, through gunicorn, for ssl.

Certainly ripple doesn't need a blockchain, but trying to design a decentralized ripple without signatures would be a really bad idea, I think. You're basically relying on users cutting credit lines when one of their neighbors misbehave, but the with signatures you can eliminate the possibility of misbehavior altogether. And it's really not that hard, it's not like we need to implement our own cryptography. We could use a library that's already done, for example, libsecp256k1, but it doesn't have to be that one.

There's no need for a global "consensus" or anything like that. You just need atomicity within ripple's transitive transactions, which of course is trivial to achieve in a single server.

Regarding ripple "creating money the same way as cryptocurrency", I strongly disagree with that. ripple is based on credit, it's more of a generalization of LETS than anything, it is mutual credit. Whereas bitcoin is more like "digital cash", someone's asset is nobody else's liability. In that sense ripple is even closer to the way central banks create money than to how bitcoin does it (central planning, monetary monopoly privileges, etc aside, evidently).

Although I find circular barter cool, I kind of see as a specific use case for the more general ripple. You could implement that based on a decentralized ripple system too. Probably even on top of xrp (which is not really decentralized, sadly), even though in my opinion they took several bad design decisions, seemingly oriented to make the chain easier to monitor (ie to harm privacy).

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/CA%2BMLsgNA6nahu6jnAtXRVhj%3D8ajanoNNcPM%3DTKvKUPpASPfCng%40mail.gmail.com.

[Evgeni Pandurski]

On Wed, May 28, 2025, 15:34 Jorge Timón <jti...@jtimon.cc> wrote:

Presumably by "crypto nonsense" you don't mean cryptography, but cryptocurrencies.

After all, I think you yourself are using cryptography in your project, through gunicorn, for ssl.

Yes. Cryptography is fine.

Certainly ripple doesn't need a blockchain, but trying to design a decentralized ripple without signatures would be a really bad idea, I think. You're basically relying on users cutting credit lines when one of their neighbors misbehave, but the with signatures you can eliminate the possibility of misbehavior altogether. And it's really not that hard, it's not like we need to implement our own cryptography. We could use a library that's already done, for example, libsecp256k1, but it doesn't have to be that one.

There's no need for a global "consensus" or anything like that. You just need atomicity within ripple's transitive transactions, which of course is trivial to achieve in a single server.

Yes. I like the quotes around "consensus" :)

Regarding ripple "creating money the same way as cryptocurrency", I strongly disagree with that. ripple is based on credit, it's more of a generalization of LETS than anything, it is mutual credit. Whereas bitcoin is more like "digital cash", someone's asset is nobody else's liability. In that sense ripple is even closer to the way central banks create money than to how bitcoin does it (central planning, monetary monopoly privileges, etc aside, evidently).

Right. Ripple creates money differently. I was trying to say that the  way Ripple does it is also problematic. In Ripple, money creation is a complex emerging phenomena. Basically the whole Ripple network is the issuer, not a particular node. Because of that, when the Ripple network loses connectivity, the money suddenly disappear. This makes the system very unstable. I would compare it with the derivative securities that caused the 2007 financial crisis.

Although I find circular barter cool, I kind of see as a specific use case for the more general ripple. You could implement that based on a decentralized ripple system too. Probably even on top of xrp (which is not really decentralized, sadly), even though in my opinion they took several bad design decisions, seemingly oriented to make the chain easier to monitor (ie to harm privacy).

If you could create an infinitely flexible and scalable Ripple implementation, that can perform automatic exchanges between zillions of currencies, I would agree with you. Then you would be able to implement all kinds of trading platforms on top of it.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/CABm2gDrETZMMbJUGODZhUvJaQiyjdyAtROiYNVvawmjfn93bwQ%40mail.gmail.com.

[Jorge Timón]

Well, different people mean different things by "consensus" in this context. What I mean, specifically, is a system that has consensus rules that all nodes must validate like a blockchain. With a global state that all nodes must validate.

I disagree that money creation is a complex emerging phenomena in ripple. and that the whole network is the issuer. no, each user is the issuer of his own IOUs, in that sense, it's actually simpler than in LETS. There it is the whole LETS community that issues the money.

And the system is much more stable than a LETS or a

I do think I could create the system you described, in an earlier email I described the architecture I had in mind for that.

And I gave a link to a repository in which I was starting to draft an implementation. But it is actually a bunch of work.

I may come back to that one day, who knows. I ended up a little bit burned out of working on "fintech". I'm not going to work on that at the moment, currently I'm focused on creating my own programming language.

If other people are motivated to implement things, I still find it great, and I can offer design advice.

And best of lucks, of course.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/CA%2BMLsgMh1dmoKRnqjtF94CggoiiBvN4Cgr6R%2BLvQW1pn1d_PiA%40mail.gmail.com.

[Evgeni Pandurski]

On Wed, May 28, 2025, 21:05 Jorge Timón <jti...@jtimon.cc> wrote:

Well, different people mean different things by "consensus" in this context. What I mean, specifically, is a system that has consensus rules that all nodes must validate like a blockchain. With a global state that all nodes must validate.

I disagree that money creation is a complex emerging phenomena in ripple. and that the whole network is the issuer. no, each user is the issuer of his own IOUs, in that sense, it's actually simpler than in LETS. There it is the whole LETS community that issues the money.

And the system is much more stable than a LETS or a

In a sense, yes. Each Ripple node issues an one-hop currency, but to use it you have to be directly connected to that node. Multi-hop currencies, however, are emergent, unstable, and depend on the reliability of the trade-connections between nodes.

In the case when everybody is connected to everybody, then indeed, each Ripple node becomes an issuer of its own currency.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/CABm2gDo06oyM2P9sxLWOpCP%2BYXoxiOsQvhA49P2vQUa4-OchBg%40mail.gmail.com.

[Johan Nygren]

As Jorge has stated he will not read or acknowledge anything I write (the reasons given was I do not understand computer science, I do not listen, I believe I am a genius, and I lied about 2-phase commit not being atomic in the sense that every hop always succeeds, among other things), I will state here that I have solved the penalty-based payment coordination that Ryan (and Evgeni) were working on back in 2006. Back then, they used a parameter they called "late-receipt penalty rate"  (here on Sourceforge mailing list) and it solved a "stuck decision" problem when finishing the payment - but this parameter itself required a decision that could also get stuck (and there maybe people see what the problem was, it was like Whack-a-Mole, solve one problem and you cause another to pop up. In total you have to repeat that three times and then you have a full solution). I assume Ryan and Evgeni abandoned that approach because it became like Whack-a-Mole - and this is very understandable (Ryan and Evgeni could clarify if I am guessing right or not). What then happened around 2010 after Satoshi (Craig) had released Bitcoin was that Ryan pivoted to another solution to the "stuck decision problem", "commit registers". This was around the time Jorge Timón joined the Sourgeforge mailing list. And now 15 years later I finished the penalty system and now Ripple Inter Server Protocol could be built. Note also that Interledger has pursued a similar approach to Ryan's original "late-receipt penalty rate" (i.e., a "chunked penalty") but they achieved this by reducing the size of the payment itself with STREAM payments, but Ryan had the right approach already in 2006 it just requires two more steps.

I will say that anything I wrote about user-to-user consensus being the "missing puzzle piece" is entirely wrong. As no one had built Ripple Inter Server Protocol and it had been 20 years since Ryan started, I had to make a guess about what was missing. Then, by trial and error, I could find my way to what was actually missing. This is also why I might appear to "not listen", the point is, there is no one leading here. No one has the solution, if you did then where is Ripple Inter Server Protocol? So I decided to try and find what was missing myself, and although I initially made wrong assumptions and guesses I did manage to find the "missing puzzle piece" in the end.

The penalty system is described in full on multihop.xyz with an interactive simulation. The last step in the 3-step payment is the one Ryan described in 2006 (it should be familiar to most people here), then there is an intermediary step that bridges the first and the last, and then there is the first step which relies on that the penalty forces the buyer to cancel unless everyone in the payment agrees to start the payment. Each step is enforced with a penalty - this is the key.

I have implemented the penalty system in full on https://bitbucket.org/bipedaljoe/ripple-simple. It is trivial for anyone to add the penalty system to their implementations. Very simple, just like Ripple.

Peace, Johan

[Johan Nygren]

A version with the "strangeness" for sync replaced with more normal approach, http://bitbucket.org/bipedaljoe/ripple-normal.

Includes the full penalty system that continues on Ryan's "late-receipt penalty rate"  (here on Sourceforge mailing list). His idea requires a 3-step payment to work.

Very simple codebase. Easy to use for anyone as a reference implementation to build other Ripple Inter Server Protocol implementations.

Path finding is anonymous, just payment ID (hash of a random number, the random number is used as preimage to authenticate "cancel"/"finalize"). Thus any single-hop implementation ("link layer") can use any signature system / identifiers, it does not conflict with the multi-hop ("network layer"). Path finding is bidirectional, and each "counterpart" (buyer/seller) takes turn to increment the depth by 1, to minimize depth searched.

Very simple. As Ripple is as very simple system.

Peace, Johan

[Jorge Timón]

"To use it you have to be connected to that user".

What does it mean to use it and to be connected?

To "be connected" wimply means that you accept that currency.

A giving a credit line of up to 100 usd to B is rhe same as saying A accepts up to 100 Busd.

And for "multi-hop" currencies is the same, or even worse because you cannot stay with "negative balances", no?

I think you're unreasonably trying to find advantages on circular swap over general ripple that simply can't be there, because circular swap is simply a specific case of the more general ripple.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/CA%2BMLsgO-468UgvkBevsimPfx0CSLSdXMNAxkz-cGfDa0%2B9q5FQ%40mail.gmail.com.

[Evgeni Pandurski]

Jorge Timón <jti...@jtimon.cc> writes:

> "To use it you have to be connected to that user".
> What does it mean to use it and to be connected?
> To "be connected" wimply means that you accept that currency.
>
> A giving a credit line of up to 100 usd to B is rhe same as
> saying A accepts up to 100 Busd.

I presume that in Ripple, for two nodes to be connected involves
some setup. Probably some public-key encryption stuff, like
certificates, also setting up trading policies etc. For the
average user, setting this up is far from trivial.

>
> And for "multi-hop" currencies is the same, or even worse
> because you cannot stay with "negative balances", no?
> I think you're unreasonably trying to find advantages on
> circular swap over general ripple that simply can't be there,
> because circular swap is simply a specific
> case of the more general ripple.

With Swaptacular (https://swaptacular.github.io) I try to minimize
the connection setup cost. There are "creditors agent" and
"debtors agent" nodes that are responsible for managing the server
and connections setup ceremonials. The goal is to get as close as
possible to the "everybody is connected to everybody" ideal. Also,
I do not allow negative balances (debtors can not become
creditors).

--
Evgeni Pandurski
Github: https://github.com/epandurski | PGP public key:
https://raw.githubusercontent.com/epandurski/myfiles/master/public.asc

[Johan Nygren]

Now built a version with asymmetric cryptography (elliptic curve cryptography), TCP and JSON messages, https://bitbucket.org/bipedaljoe/ripple-ecc/. The user-to-user account synchronization is common sense approach and not my earlier over-complicated idea.

I am very interested in working with you all as a community.

I want to work with and listen to the best implementation ideas.

I suggest I have solved the "stuck payment" problem, by continuing on the idea Ryan had in 2006, the "late-receipt penalty rate" (sourceforge mailing list, 2006)

The problem Ryan (and Evgeni, and others who were around back then) faced was that they solved one "stuck decision" problem but caused another as their solution itself required a decision. I solved this by adding a similar penalty to enforce every step of the payment. This requires 3-step payments. I have an interactive simulation on multihop.xyz.

Ryan, Evgeni and others who were around in 2006 could verify if I guess right about why they abandoned the "late-receipt penalty rate".

As Ryan never managed to solve "stuck payment" issue in a truly decentralized way, he pivoted to "commit registers". In 2011 Jorge Timon referred to the "commit registers" as that "the issue registers solve is [...] the possible attack of locking intermediaries credit with fake transactions that never commit" (sourceforge mailing list, 2011) but originally the idea was to use incentives rather than a central third party. Ryan got stuck when designing the incentives, he designed half the solution.

re: "crypto nonsense"
I think Evgeni's comment may have been in response to my overcomplicated account consensus mechanism (that was Nakamoto consensus at two node scale...) And he was right. Synchronization between users can be done in normal simple way. I wrongly identified "what people had missed" as somehow being about the user-to-user consensus. This was wrong. But thanks to the feedback from Ryan, Michiel de Jong, and others, I was able to pin-point what everyone had missed (the complete penalty system). I was wrong, I have apologized, and I still apologize.

Jorge has publicly stated here he will ignore my solution to "stuck payment" problem. If you change your mind Jorge and want to look at it, you are welcome to do so. You are probably better at me on many things and I could probably learn from you too. Anyone else could also try and raise the discussion here about my solution (or about the "stuck payment" problem itself even, and potential solutions for it, but as I have found the ideal solution it could be convenient to give that some focus).

Overall I am happy to meet half way and work as a community to make Ripple Inter Server Protocol a reality.

Peace, Johan