Multi-server Ripple is easy, I already built it, you all got it wrong
196 views
Skip to first unread message
Johan Nygren
Mar 23, 2025, 4:38:52 AMMar 23
to Ripple Project
I will do one last attempt to reach this community here (managed to reach a few already). A complete implementation based on what I write here has been built, available via https://ripple.archi. It also has my Resilience system built in already (that I know at least one other person here saw as the next step for Ripple).
Where things went wrong
After Bitcoin had released in 2009, Ryan Fugger decided in 2011 to fall back entirely on global consensus (inspired by Jorge Timón here).
Where things went wrong
After Bitcoin had released in 2009, Ryan Fugger decided in 2011 to fall back entirely on global consensus (inspired by Jorge Timón here).
This was most likely a result of failing to solve the two-general problem (i.e., the potential for misunderstanding in decision making, see my whitepaper) at the account level, and therefore falling back on global consensus to solve the same type of problem. Ryan had experience with RipplyPay that was "global consensus" so to speak, but he apparently failed when it came to taking the next step to a distributed version. Ryan did acknowledge account-level consensus as early as 2006, but this type of thinking then seems to disappear.
To be able to fall back on global consensus, there had to be a mechanism that bridged the two. Hash locks are ideal way to enforce actions on public ledgers. They are also "non-reversible" in many ways, and the favored multi-hop payment design thus became: everyone reserves credit temporarily, and the seller then sends a "commit/finalize" signal in a "race against time" (a race condition) where everyone is forced to propagate it as they end up with a net negative balance.
Note, this design is a result of wanting to combine Ripple with global consensus. It is inherently not secure without global consensus mechanism. And the "lock-credit-attack" was used as part of the rationale for it but such attack was never a problem (more on that below).
Note, this design is a result of wanting to combine Ripple with global consensus. It is inherently not secure without global consensus mechanism. And the "lock-credit-attack" was used as part of the rationale for it but such attack was never a problem (more on that below).
Ripple with one global transaction per Ripple payment is nonsensical, as you do not benefit from the trustlines, there is already global trust.
The two-general problem
To build multi-server Ripple, you simply need to solve the general problem at the user-to-user level. You do this by simply letting the users take turns to be the "validator" who stamps a transaction as valid. Similar in many ways to the idea Ryan suggested in 2006.
Then, for the coordination at the multi-hop level, you make the buyer the authority or "general". The buyer has the final say. With this, they also have a position of control that could be exploited, but since they are the only one with a net negative balance they are not in a position to try and attack the payment chain. If the buyer attempts a "lock credit attack", the payment chain intermediaries as well as the seller can just start to collect fees from the payment. Thus, the "attack" simply becomes an act of giving money away. It was never a good attack vector.
And besides those two things, you also need to authenticate the "buyer cancels" command. Note, you also still need to authenticate the "seller-has-received-all-commits-and-tells-the-buyer-to-finalize" (to prevent "fake recipient attack" just like in Ryans design) but you do not need to then combine it with hash locks on global public ledgers... What Ryan did in 2011 was he co-opted a mechanism that is needed for Ripple (for fake recipient attack...), and he piggybacked on it to combine Ripple with Bitcoin more or less, and I suggest this was done mainly to avoid actually solving the two-general problem (as it was a type of expertise that was not as common back in the early 2000s, it is more common today I think).
For some context on how you need to focus on authority when building a distributed system (or any system), see https://ripple.archi/authority.pdf.
Thank you Ryan for inventing Ripple. I try and explain to you all in this community here that you were all wrong and that a truly distributed Ripple was actually pretty easy but you needed to get the user-to-user consensus right first. Anyone interested in what I say, I encourage you to respond here, to get some focus on this topic. The more people talk about it, the easier it becomes to talk about it. It is the elephant in the room and instead of being stuck in a rut of a nonsensical idea to do one global transaction per Ripple money system payment, why not just make multi-server Ripple a reality. As a community.
Johan
The two-general problem
To build multi-server Ripple, you simply need to solve the general problem at the user-to-user level. You do this by simply letting the users take turns to be the "validator" who stamps a transaction as valid. Similar in many ways to the idea Ryan suggested in 2006.
Then, for the coordination at the multi-hop level, you make the buyer the authority or "general". The buyer has the final say. With this, they also have a position of control that could be exploited, but since they are the only one with a net negative balance they are not in a position to try and attack the payment chain. If the buyer attempts a "lock credit attack", the payment chain intermediaries as well as the seller can just start to collect fees from the payment. Thus, the "attack" simply becomes an act of giving money away. It was never a good attack vector.
And besides those two things, you also need to authenticate the "buyer cancels" command. Note, you also still need to authenticate the "seller-has-received-all-commits-and-tells-the-buyer-to-finalize" (to prevent "fake recipient attack" just like in Ryans design) but you do not need to then combine it with hash locks on global public ledgers... What Ryan did in 2011 was he co-opted a mechanism that is needed for Ripple (for fake recipient attack...), and he piggybacked on it to combine Ripple with Bitcoin more or less, and I suggest this was done mainly to avoid actually solving the two-general problem (as it was a type of expertise that was not as common back in the early 2000s, it is more common today I think).
For some context on how you need to focus on authority when building a distributed system (or any system), see https://ripple.archi/authority.pdf.
Thank you Ryan for inventing Ripple. I try and explain to you all in this community here that you were all wrong and that a truly distributed Ripple was actually pretty easy but you needed to get the user-to-user consensus right first. Anyone interested in what I say, I encourage you to respond here, to get some focus on this topic. The more people talk about it, the easier it becomes to talk about it. It is the elephant in the room and instead of being stuck in a rut of a nonsensical idea to do one global transaction per Ripple money system payment, why not just make multi-server Ripple a reality. As a community.
Johan
Melvin Carvalho
Mar 23, 2025, 4:52:11 AMMar 23
to rippl...@googlegroups.com
While I sympathize with your critique, I'm still trying to take all of this in. There is alot to understand.
A simpler question: will your system use identity, signatures and user-to-user communication?
Giovanni, a long-time member of this group, helped make a simple system to do that:
It signs notes from and transmits them from one user to another user using "Relays"
Do you think this could be a piece of the implementation for ripple archi? If so we could probably make something that works, quite quickly.
--
Johan
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/b63b62c7-d5a6-4c48-8de6-6912b45c8c03n%40googlegroups.com.
Melvin Carvalho
Mar 23, 2025, 5:09:22 AMMar 23
to rippl...@googlegroups.com
How Nostr Could Facilitate RISP
Nostr (Notes and Other Stuff Transmitted by Relays) is a decentralized, censorship-resistant protocol for real-time communication and data exchange.
It could be used to enhance the RISP architecture in the following ways:
1. Decentralized Communication
Nostr’s relay-based architecture allows users to communicate directly without relying on centralized servers.
This aligns with RISP’s goal of person-to-person (P2P) consensus, enabling secure and direct communication between buyers, sellers, and intermediaries.
Nostr’s relay-based architecture allows users to communicate directly without relying on centralized servers.
This aligns with RISP’s goal of person-to-person (P2P) consensus, enabling secure and direct communication between buyers, sellers, and intermediaries.
2. Real-Time Transaction Signing
Nostr supports real-time signing of messages using cryptographic keys.
This could be used to facilitate validator alternation in the Lockstep protocol, ensuring that transactions are signed and validated in real-time by the involved parties.
Nostr supports real-time signing of messages using cryptographic keys.
This could be used to facilitate validator alternation in the Lockstep protocol, ensuring that transactions are signed and validated in real-time by the involved parties.
3. Immutable Transaction Records
Nostr’s event-based system can be used to create immutable records of transactions.
Each transaction step (e.g., commit, finalize) can be published as a Nostr event, providing a transparent and tamper-proof audit trail.
Nostr’s event-based system can be used to create immutable records of transactions.
Each transaction step (e.g., commit, finalize) can be published as a Nostr event, providing a transparent and tamper-proof audit trail.
4. Pathfinding and Routing
Nostr’s decentralized relays can be used to broadcast payment routing requests and discover paths between users.
This complements RISP’s bidirectional pathfinding (“ping pong”) by leveraging Nostr’s global network of relays for efficient route discovery.
Nostr’s decentralized relays can be used to broadcast payment routing requests and discover paths between users.
This complements RISP’s bidirectional pathfinding (“ping pong”) by leveraging Nostr’s global network of relays for efficient route discovery.
5. Resilience Against Censorship
Nostr’s censorship-resistant design ensures that RISP transactions can be conducted even in restrictive environments.
This is particularly useful for maintaining the integrity of the payment network in the face of external interference.
Nostr’s censorship-resistant design ensures that RISP transactions can be conducted even in restrictive environments.
This is particularly useful for maintaining the integrity of the payment network in the face of external interference.
Johan Nygren
Mar 23, 2025, 6:54:34 AMMar 23
to Ripple Project
Hi Melvin, thank you for responding to the discussion. Yes I can understand it is a lot to take in and "sift through". You need to also need to be able to independently verify if I have come up with anything of value.
One way to look at what I suggest is needed for distributed Ripple is to compare with what others have suggested for 15 years and that I say is the completely wrong approach. I.e., doing consensus at the global level instead of the user-to-user level (it needs to be done at some level and I suggest that falling back on global was done mostly because of lack of expertise in consensus mechanisms).
One good start could be to verify: was the lock-credit-attack really a problem? Since Ryan since 15 years maybe uses it as the rationale for the global consensus. If it was never a problem, that rationale was always false. I suggest the simple solution is a fee system (and I have implemented this already). The buyer is the "authority" in the payment, but if they try to lock credit indefinitely, every intermediary and the seller as well start to just take fees from the payment. Anyone could easily verify whether this is a reasonable design or not. If it is, then one of basic premises for Ryans idea seems clearly false. This is a good start to see if I am onto something or not (I already built everything but you would have to audit my work step by step and this is a good first step).
I would very much appreciate others chiming in on the fee model for lock-credit-attack. Does it solve it, and if so, do you agree the attack was never a motivation for global consensus? The more people chime in, the more it can be agreed on whether lock-credit-attack actually was a system-breaking problem or not (I of course believe it was not, but this is a community forum and Ryan is the authority in it and therefore others need to engage on this topic if Ryan will not). If it was system breaking and my fees do not work, then I am making false claims. But if it was always manageable person-to-person, then Ryan was making false claims.
About Giovanni T. Parra
Giovanni T. Parra (fiatjaf) has been stuck in the same rut Ryan was stuck in. He posted some design suggestions for "solution to the old-ripple decentralized protocol" on Reddit here in 2018 but they are the same wrong direction Ryan went down in 2011. Giovanni also called me crazy in 2015 btw, here. Giovanni did get the idea of user-to-user consensus right in his 2018 design (see my response here), but he is still clinging to the global consensus idea that Ryan put out in 2011 and "hash locks".
What Giovanni and Ryan both miss is that the two-general problem can be solved at user-to-user level. There is no need to solve it globally (as RipplePay did by being single-server and Ripple.com did by having global consensus central blockchain). So there is no need to solve "hash locks to interface the global ledger" and there is no need to co-opt the solution to "fake recipient attack" to also serve as "hash lock condition" for a central blockchain.
So Giovanni is also missing the elephant in the room, and overthinking. Nostr might be a great protocol, a guy I work with on https://bitpeople.org really likes it. And Ripple the money system from Ryan Fugger is brilliant. But both Ryan and Giovanni seem to not understand distributed consensus in Ripple. And as I have emphasized, the expertise they miss was consensus systems, while Giovanni is probably great at messages as Nostr does that, and Ryan was probably great at messages as all people in IT working with the internet were.
I am trying to emphasize that both Ryan and Giovanni took the common sense model, and turned it upside down so that it could be integrated with global consensus. That Ripple can be built by centralizing authority to the buyer, keeping the buyer in check with a fee system (if they attempt the lock credit attack).
Nostr
Whether or not some framework like Nostr could be used, has to be separated as a topic from Giovanni's wrong ideas about how to build multi-server Ripple. First and foremost, frameworks automate work but they are not necessary. My implementation works very well. The problem multi-server Ripple has had is not lack of frameworks, it is lack of basic understanding of the problem domain at hand (account-level consensus) and what is needed to build multi-server Ripple. People who were very experienced in IT and internet but just not at consensus. I think.
A simpler question: will your system use identity, signatures and user-to-user communication?
Any user-to-user exchange can use any identify, signature, and user-to-user communication protocol. What needs to be agreed on is mostly the multi-hop rules. For these rules though, the user-to-user exchanges need to be secure so they need a consensus mechanism. Ryan seems to have over-focused on the multi-hop and made the user-to-user part too much of an "implementation detail" (word used a lot on Sourceforge forum) and therefore lacked certainty in two-general type problems and thus fell back on one way to solve them: RipplPay but in distributed form, i.e., a global consensus. This is my best explanation.
For the path finding and payments, a random number is used to find the path and coordinate the payment. No user information is used beyond single-hop, there is no need for it.
Many thanks to Ryan for inventing Ripple.
Peace Johan
One way to look at what I suggest is needed for distributed Ripple is to compare with what others have suggested for 15 years and that I say is the completely wrong approach. I.e., doing consensus at the global level instead of the user-to-user level (it needs to be done at some level and I suggest that falling back on global was done mostly because of lack of expertise in consensus mechanisms).
One good start could be to verify: was the lock-credit-attack really a problem? Since Ryan since 15 years maybe uses it as the rationale for the global consensus. If it was never a problem, that rationale was always false. I suggest the simple solution is a fee system (and I have implemented this already). The buyer is the "authority" in the payment, but if they try to lock credit indefinitely, every intermediary and the seller as well start to just take fees from the payment. Anyone could easily verify whether this is a reasonable design or not. If it is, then one of basic premises for Ryans idea seems clearly false. This is a good start to see if I am onto something or not (I already built everything but you would have to audit my work step by step and this is a good first step).
I would very much appreciate others chiming in on the fee model for lock-credit-attack. Does it solve it, and if so, do you agree the attack was never a motivation for global consensus? The more people chime in, the more it can be agreed on whether lock-credit-attack actually was a system-breaking problem or not (I of course believe it was not, but this is a community forum and Ryan is the authority in it and therefore others need to engage on this topic if Ryan will not). If it was system breaking and my fees do not work, then I am making false claims. But if it was always manageable person-to-person, then Ryan was making false claims.
About Giovanni T. Parra
Giovanni T. Parra (fiatjaf) has been stuck in the same rut Ryan was stuck in. He posted some design suggestions for "solution to the old-ripple decentralized protocol" on Reddit here in 2018 but they are the same wrong direction Ryan went down in 2011. Giovanni also called me crazy in 2015 btw, here. Giovanni did get the idea of user-to-user consensus right in his 2018 design (see my response here), but he is still clinging to the global consensus idea that Ryan put out in 2011 and "hash locks".
What Giovanni and Ryan both miss is that the two-general problem can be solved at user-to-user level. There is no need to solve it globally (as RipplePay did by being single-server and Ripple.com did by having global consensus central blockchain). So there is no need to solve "hash locks to interface the global ledger" and there is no need to co-opt the solution to "fake recipient attack" to also serve as "hash lock condition" for a central blockchain.
So Giovanni is also missing the elephant in the room, and overthinking. Nostr might be a great protocol, a guy I work with on https://bitpeople.org really likes it. And Ripple the money system from Ryan Fugger is brilliant. But both Ryan and Giovanni seem to not understand distributed consensus in Ripple. And as I have emphasized, the expertise they miss was consensus systems, while Giovanni is probably great at messages as Nostr does that, and Ryan was probably great at messages as all people in IT working with the internet were.
I am trying to emphasize that both Ryan and Giovanni took the common sense model, and turned it upside down so that it could be integrated with global consensus. That Ripple can be built by centralizing authority to the buyer, keeping the buyer in check with a fee system (if they attempt the lock credit attack).
Nostr
Whether or not some framework like Nostr could be used, has to be separated as a topic from Giovanni's wrong ideas about how to build multi-server Ripple. First and foremost, frameworks automate work but they are not necessary. My implementation works very well. The problem multi-server Ripple has had is not lack of frameworks, it is lack of basic understanding of the problem domain at hand (account-level consensus) and what is needed to build multi-server Ripple. People who were very experienced in IT and internet but just not at consensus. I think.
A simpler question: will your system use identity, signatures and user-to-user communication?
For the path finding and payments, a random number is used to find the path and coordinate the payment. No user information is used beyond single-hop, there is no need for it.
Many thanks to Ryan for inventing Ripple.
Peace Johan
Melvin Carvalho
Mar 23, 2025, 7:57:28 AMMar 23
to rippl...@googlegroups.com
Hi Melvin, thank you for responding to the discussion. Yes I can understand it is a lot to take in and "sift through". You need to also need to be able to independently verify if I have come up with anything of value.
One way to look at what I suggest is needed for distributed Ripple is to compare with what others have suggested for 15 years and that I say is the completely wrong approach. I.e., doing consensus at the global level instead of the user-to-user level (it needs to be done at some level and I suggest that falling back on global was done mostly because of lack of expertise in consensus mechanisms).
One good start could be to verify: was the lock-credit-attack really a problem? Since Ryan since 15 years maybe uses it as the rationale for the global consensus. If it was never a problem, that rationale was always false. I suggest the simple solution is a fee system (and I have implemented this already). The buyer is the "authority" in the payment, but if they try to lock credit indefinitely, every intermediary and the seller as well start to just take fees from the payment. Anyone could easily verify whether this is a reasonable design or not. If it is, then one of basic premises for Ryans idea seems clearly false. This is a good start to see if I am onto something or not (I already built everything but you would have to audit my work step by step and this is a good first step).
I would very much appreciate others chiming in on the fee model for lock-credit-attack. Does it solve it, and if so, do you agree the attack was never a motivation for global consensus? The more people chime in, the more it can be agreed on whether lock-credit-attack actually was a system-breaking problem or not (I of course believe it was not, but this is a community forum and Ryan is the authority in it and therefore others need to engage on this topic if Ryan will not). If it was system breaking and my fees do not work, then I am making false claims. But if it was always manageable person-to-person, then Ryan was making false claims.
About Giovanni T. Parra
Giovanni T. Parra (fiatjaf) has been stuck in the same rut Ryan was stuck in. He posted some design suggestions for "solution to the old-ripple decentralized protocol" on Reddit here in 2018 but they are the same wrong direction Ryan went down in 2011. Giovanni also called me crazy in 2015 btw, here. Giovanni did get the idea of user-to-user consensus right in his 2018 design (see my response here), but he is still clinging to the global consensus idea that Ryan put out in 2011 and "hash locks".
Very sorry you had this experience. The very caustic behaviour of Giovanni is well known, and we have lost a lot of developers due to it. Nevertheless, it is a technology that has survived and still works, with many good devs and people in the ecosystem still, as well as many servers.
What Giovanni and Ryan both miss is that the two-general problem can be solved at user-to-user level. There is no need to solve it globally (as RipplePay did by being single-server and Ripple.com did by having global consensus central blockchain). So there is no need to solve "hash locks to interface the global ledger" and there is no need to co-opt the solution to "fake recipient attack" to also serve as "hash lock condition" for a central blockchain.
So Giovanni is also missing the elephant in the room, and overthinking. Nostr might be a great protocol, a guy I work with on https://bitpeople.org really likes it. And Ripple the money system from Ryan Fugger is brilliant. But both Ryan and Giovanni seem to not understand distributed consensus in Ripple. And as I have emphasized, the expertise they miss was consensus systems, while Giovanni is probably great at messages as Nostr does that, and Ryan was probably great at messages as all people in IT working with the internet were.
I am trying to emphasize that both Ryan and Giovanni took the common sense model, and turned it upside down so that it could be integrated with global consensus. That Ripple can be built by centralizing authority to the buyer, keeping the buyer in check with a fee system (if they attempt the lock credit attack).
I agree with this assessment. The centralized approach was the wrong one. Trying something, a friend of mine calls it "small data", I think is new and innovative and exciting.
What can we do to bootstrap the system, and get the network going?
To view this discussion visit https://groups.google.com/d/msgid/rippleusers/df7c8250-0eb3-4744-b727-fb648b67b0b8n%40googlegroups.com.
Johan Nygren
Mar 23, 2025, 12:02:09 PMMar 23
to Ripple Project
I don't mind that Giovanni called me crazy. My original motivation for Resilience (swarm redistribution) was originally during med. school where I noticed that a certain group (my group, not Giovanni's group) had monopoly on labeling the executive health of people as either sick or healthy. Giovanni has no such authority, I am much closer to him to having such authority as I am still doing progress towards exam as medical "doctor".
Rather I just want to emphasize (as you already know Melvin but emphasizing for anyone new here) that since 2011 Ryan, Giovanni, and many others, have for some reason formed a consensus that you need global consensus. One root for their idea is the "lock-credit-attack". If it could be proven such an attack is manageable with person-to-person consensus only, their rationale is provably wrong. And I suggest the extremely simple fee model. And I implement it as well. My codebase works very well. And I recommend anyone curious about my claims to first audit "is the lock-credit-attack really unmanageable person-to-person?" and if it is not then Ryan and Giovanni has a house of cards. Ryan is a genius who invented Ripple but he could still make mistakes when trying to build a truly distributed version of it, and once having made such mistake might be less interested in trying to achieve his original 2006-vision. Giovanni may have good ideas otherwise too I do not know who he is.
My system is complete. Ripple is simple. Reasonably it might be possible to implement it in a simple way too. And as I already did it seems to me it is. For anyone new to this: https://ripple.archi, and please chime in on if the lock-credit-attack requires global consensus or can be managed with fees in user-to-user consensus only as my codebase already does: https://ripple.archi.
My main point is: two-general problem needs to be solved. This can be done either user-to-user or globally. Many people are inexperienced with consensus systems, even more so 20 years ago (before "Bitcoin" and "web3". I suggest Ryan - although suggesting the solution as early as 2006 - was in fact inexperienced with "consensus engineering" and failed to build multi-server Ripple therefore. This is very reasonable claim as most people in 2006 were probably less experienced with "web3" as it is described as a revolutionary technology - thus not everyone IT expert could be expert in it before Bitcoin. This is my best guess.
Thank you Ryan for inventing Ripple. You are a genius. I think you and others got things wrong though on the road to multi-server Ripple. I did thinking by myself and I built a complete version on https://ripple.archi, that also includes swarm redistribution.
(This is communicated to everyone in this community although I am responding to Melvin's reply specifically)
Rather I just want to emphasize (as you already know Melvin but emphasizing for anyone new here) that since 2011 Ryan, Giovanni, and many others, have for some reason formed a consensus that you need global consensus. One root for their idea is the "lock-credit-attack". If it could be proven such an attack is manageable with person-to-person consensus only, their rationale is provably wrong. And I suggest the extremely simple fee model. And I implement it as well. My codebase works very well. And I recommend anyone curious about my claims to first audit "is the lock-credit-attack really unmanageable person-to-person?" and if it is not then Ryan and Giovanni has a house of cards. Ryan is a genius who invented Ripple but he could still make mistakes when trying to build a truly distributed version of it, and once having made such mistake might be less interested in trying to achieve his original 2006-vision. Giovanni may have good ideas otherwise too I do not know who he is.
My system is complete. Ripple is simple. Reasonably it might be possible to implement it in a simple way too. And as I already did it seems to me it is. For anyone new to this: https://ripple.archi, and please chime in on if the lock-credit-attack requires global consensus or can be managed with fees in user-to-user consensus only as my codebase already does: https://ripple.archi.
My main point is: two-general problem needs to be solved. This can be done either user-to-user or globally. Many people are inexperienced with consensus systems, even more so 20 years ago (before "Bitcoin" and "web3". I suggest Ryan - although suggesting the solution as early as 2006 - was in fact inexperienced with "consensus engineering" and failed to build multi-server Ripple therefore. This is very reasonable claim as most people in 2006 were probably less experienced with "web3" as it is described as a revolutionary technology - thus not everyone IT expert could be expert in it before Bitcoin. This is my best guess.
Thank you Ryan for inventing Ripple. You are a genius. I think you and others got things wrong though on the road to multi-server Ripple. I did thinking by myself and I built a complete version on https://ripple.archi, that also includes swarm redistribution.
(This is communicated to everyone in this community although I am responding to Melvin's reply specifically)
Melvin Carvalho
Mar 23, 2025, 12:21:04 PMMar 23
to rippl...@googlegroups.com
I don't mind that Giovanni called me crazy. My original motivation for Resilience (swarm redistribution) was originally during med. school where I noticed that a certain group (my group, not Giovanni's group) had monopoly on labeling the executive health of people as either sick or healthy. Giovanni has no such authority, I am much closer to him to having such authority as I am still doing progress towards exam as medical "doctor".
Rather I just want to emphasize (as you already know Melvin but emphasizing for anyone new here) that since 2011 Ryan, Giovanni, and many others, have for some reason formed a consensus that you need global consensus. One root for their idea is the "lock-credit-attack". If it could be proven such an attack is manageable with person-to-person consensus only, their rationale is provably wrong. And I suggest the extremely simple fee model. And I implement it as well. My codebase works very well. And I recommend anyone curious about my claims to first audit "is the lock-credit-attack really unmanageable person-to-person?" and if it is not then Ryan and Giovanni has a house of cards. Ryan is a genius who invented Ripple but he could still make mistakes when trying to build a truly distributed version of it, and once having made such mistake might be less interested in trying to achieve his original 2006-vision. Giovanni may have good ideas otherwise too I do not know who he is.
My system is complete. Ripple is simple. Reasonably it might be possible to implement it in a simple way too. And as I already did it seems to me it is. For anyone new to this: https://ripple.archi, and please chime in on if the lock-credit-attack requires global consensus or can be managed with fees in user-to-user consensus only as my codebase already does: https://ripple.archi.
My main point is: two-general problem needs to be solved. This can be done either user-to-user or globally. Many people are inexperienced with consensus systems, even more so 20 years ago (before "Bitcoin" and "web3". I suggest Ryan - although suggesting the solution as early as 2006 - was in fact inexperienced with "consensus engineering" and failed to build multi-server Ripple therefore. This is very reasonable claim as most people in 2006 were probably less experienced with "web3" as it is described as a revolutionary technology - thus not everyone IT expert could be expert in it before Bitcoin. This is my best guess.
+1 agree. Giovanni and Ryan were completely wrong on this point. But we can fix that now.
To view this discussion visit https://groups.google.com/d/msgid/rippleusers/51a22120-37ae-4330-9129-2f41ae001fefn%40googlegroups.com.
Johan Nygren
Mar 23, 2025, 12:24:42 PMMar 23
to Ripple Project
re: "What can we do to bootstrap the system, and get the network going? "
It is already complete. You can start your own private user on your own server right now.
My reference implementation is single-user. Multi-user servers are good next step, and different front ends like a web front end or Qt. But, before this, best is to form a consensus as a community: was the "lock-commit-attack" unmanageable person-to-person, or is the rationale for falling back on global consensus in 2011 based on a false claim. It is better to work as a community. I could dive into building a multi-user server right away, or, I could try and have a conversation with the thousands of other people who actually share the same goal (including Ryan). This is what I would prefer: that my reference implementation can be a lever to actually have a discussion about: was the claims made in 2011 true or where people a bit too hyped on Bitcoin? I really really like what Satoshi (Craig) started and Gavin Wood and Vitalik Buterin continued on with Ethereum, I I even already built the logical conclusion of it with https://bitpeople.org and https://panarkistiftelsen.se/kod/panarchy.go, but I think Ripple is the exact opposite and Satoshi (Craig) also acknowledged this in 2009. So Ryan is a genius in his own right, no need to imitate Craig. Both were genius ideas but exact opposites.
Peace, Johan
It is already complete. You can start your own private user on your own server right now.
My reference implementation is single-user. Multi-user servers are good next step, and different front ends like a web front end or Qt. But, before this, best is to form a consensus as a community: was the "lock-commit-attack" unmanageable person-to-person, or is the rationale for falling back on global consensus in 2011 based on a false claim. It is better to work as a community. I could dive into building a multi-user server right away, or, I could try and have a conversation with the thousands of other people who actually share the same goal (including Ryan). This is what I would prefer: that my reference implementation can be a lever to actually have a discussion about: was the claims made in 2011 true or where people a bit too hyped on Bitcoin? I really really like what Satoshi (Craig) started and Gavin Wood and Vitalik Buterin continued on with Ethereum, I I even already built the logical conclusion of it with https://bitpeople.org and https://panarkistiftelsen.se/kod/panarchy.go, but I think Ripple is the exact opposite and Satoshi (Craig) also acknowledged this in 2009. So Ryan is a genius in his own right, no need to imitate Craig. Both were genius ideas but exact opposites.
Peace, Johan
Johan Nygren
Mar 23, 2025, 12:33:04 PMMar 23
to rippl...@googlegroups.com
+1 agree too. And that we could all fix that now and build multi-server Ripple and the logical conclusion to the internet. A good "litmus test" (for anyone interested, Melvin and me already looked at it and the more people who independently audit this claim the better): can the lock-credit-attack be managed person-to-person or not. As I understand, Ryan's rationale since 15 years is that the lock-credit-attack is what motivates the pivot to global consensus. But if the lock-credit-attack is actually fully manageable person-to-person then Ryan's rationale 15 years ago was wrong. This is a simple verifiable experiment you can do. And then you can (who have now verified this) look at my suggestion for a true multi-server Ripple, where authority is centralized to the buyer, and a fee system manages the lock-credit-attack (forces the buyer to behave, and they were already in a position where they were forced to behave as they were the only on with a net negative balance). And at the user-to-user level, authority is alternated (just like in Satoshi's Bitcoin) so that two users validate every other decision, leaving no room for uncertainty/misunderstanding. And I provide some context on authority at https://ripple.archi/authority.pdf. Thank you Ryan for inventing Ripple. Peace, Johan
To view this discussion visit https://groups.google.com/d/msgid/rippleusers/CAKaEYhLR9CiY3cLrOO2sV-o5Xy4-hEjEEpwLoOmg%2BhfDybfFFg%40mail.gmail.com.
Johan Nygren
Mar 24, 2025, 3:41:10 AMMar 24
to Ripple Project
The fees do not work. They just introduce another attack vector (an intermediary can receive "finalize" from buyer then claim they never did, and abuse fee system to pay out less than they got in).
The "finalize-in-chunks" does work. I.e., if there is a delay, intermediaries (and seller) start to finalize the payment in chunks, eventually it is all finalized. But it does not deter lock-credit-attacks (when buyer and seller are both attacker). It does manage lock-credit-problem from network faults. If combined with a separate fee system paid on top of the payment, it might deter lock credit attack.
My original idea only had the finalize-in-chunks and did not plan for attacks. I was overly optimistic when also adding the fees in response to the feedback here about lock-credit-attack being very problematic.
Johan
The "finalize-in-chunks" does work. I.e., if there is a delay, intermediaries (and seller) start to finalize the payment in chunks, eventually it is all finalized. But it does not deter lock-credit-attacks (when buyer and seller are both attacker). It does manage lock-credit-problem from network faults. If combined with a separate fee system paid on top of the payment, it might deter lock credit attack.
My original idea only had the finalize-in-chunks and did not plan for attacks. I was overly optimistic when also adding the fees in response to the feedback here about lock-credit-attack being very problematic.
Johan
Johan Nygren
Mar 24, 2025, 6:33:10 AMMar 24
to Ripple Project
Now removed fees, keeping only the "partial finalize" part of it. That was what I planned to have before I shared my work here a few weeks ago (I started doubting my ideas because of response I got when I shared it here).
https://bitbucket.org/bipedaljoe/resilience/commits/d2e0fe4b448ceebb3cc9c30014d061a4b8df9080
This does not prevent lock-credit-attack. But it prevents locking for long periods of time (and therefore makes it easy to add other fees on top of payment that deter such attack, no?).
It also resolves if "finalize" signal gets stuck at intermediary (intermediary is attacker).
Think of it as a "distributed finalization" as a failsafe if normal finalize signal does not work. It is slower (much slower) but always finishes (i.e., payment either finalizes or cancels).
The "buyer cancel" signal propagation has exact same incentives as the "commit/finalize" propagation in Ryan's reverse model: those who do not propagate it further get stuck with a net negative balance. This ensures it will propagate. But same is not true for "buyer finalizes". An intermediary could simply not forward it. The "distributed finalization" then kicks in. In it, the risk is distributed across all people in the payment chain. Like a bike helmet distributes force of impact. Normally, this mechanism would not be used. It is a failsafe. Much slower, but should be set to be fast enough to resolve the "intermediary does not propagate buyer finalize signal" attack.
With this, the race condition is "buyer cancels" vs "distributed finalization". Thus never the full payment amount... but, slower acting. In Ryan's model, the race condition is the full payment amount, but, faster acting. Right?
Johan
https://bitbucket.org/bipedaljoe/resilience/commits/d2e0fe4b448ceebb3cc9c30014d061a4b8df9080
This does not prevent lock-credit-attack. But it prevents locking for long periods of time (and therefore makes it easy to add other fees on top of payment that deter such attack, no?).
It also resolves if "finalize" signal gets stuck at intermediary (intermediary is attacker).
Think of it as a "distributed finalization" as a failsafe if normal finalize signal does not work. It is slower (much slower) but always finishes (i.e., payment either finalizes or cancels).
The "buyer cancel" signal propagation has exact same incentives as the "commit/finalize" propagation in Ryan's reverse model: those who do not propagate it further get stuck with a net negative balance. This ensures it will propagate. But same is not true for "buyer finalizes". An intermediary could simply not forward it. The "distributed finalization" then kicks in. In it, the risk is distributed across all people in the payment chain. Like a bike helmet distributes force of impact. Normally, this mechanism would not be used. It is a failsafe. Much slower, but should be set to be fast enough to resolve the "intermediary does not propagate buyer finalize signal" attack.
With this, the race condition is "buyer cancels" vs "distributed finalization". Thus never the full payment amount... but, slower acting. In Ryan's model, the race condition is the full payment amount, but, faster acting. Right?
Johan
Johan Nygren
Mar 24, 2025, 9:11:29 AMMar 24
to Ripple Project
My fee idea would work if done in the reverse, like Ryan's idea.
Ryan's idea is that the seller "finalizes" and every hop towards the buyer has a natural incentive to propagate. This is smart. But it is done in an "all-or-nothing" race condition.
But what if the race condition is removed, or slowed down. Instead of all-or-nothing timeouts, people who timeout start a "distributed cancellation" process. They gradually cancel tiny chunks of the payment (very similar code to my previous "fee" or "distributed finalization" mechanism). Thus the finalize signal is in a race condition but a very slow one, with a constant incentive to propagate it (as anyone who does not will carry the cost themselves...) but slow acting. Ideally as slow as possible whilst still enforcing the propagation of the finalize signal.
Johan
Ryan's idea is that the seller "finalizes" and every hop towards the buyer has a natural incentive to propagate. This is smart. But it is done in an "all-or-nothing" race condition.
But what if the race condition is removed, or slowed down. Instead of all-or-nothing timeouts, people who timeout start a "distributed cancellation" process. They gradually cancel tiny chunks of the payment (very similar code to my previous "fee" or "distributed finalization" mechanism). Thus the finalize signal is in a race condition but a very slow one, with a constant incentive to propagate it (as anyone who does not will carry the cost themselves...) but slow acting. Ideally as slow as possible whilst still enforcing the propagation of the finalize signal.
Johan
Johan Nygren
Mar 25, 2025, 6:10:16 AMMar 25
to Ripple Project
Ryan's idea with seller finalizes has the "race condition" that breaks it. Setting up that delaying propagation instead means you can finalize less, solves that. Still a penalty but not all-or-nothing. But how to coordinate that?
My idea that the buyer first does commit towards seller, and the buyer retains the right to cancel until the seller signals them the commit succeeded, and there is a fee system to prevent "lock credit attack", could be combined with Ryan's "seller finalizes" to set up the penalty for delaying in propagating.
On their own, Ryan's idea and my idea are pretty simple. But neither work (if perfect defense against lock-credit-attack is a requirement). Combined, it gets a bit complex. But not overly complex.
What is needed to glue the mechanisms together, is the same mechanism that has to act on Ryan's idea, a "continuous cancellation". This starts the moment the buyer-to-seller-commit succeeds and the buyer revokes their right to cancel. The cancellation has to happen faster than the fees, thus, an intermediary who does not propagate the signal ends up carrying the burden of the fees (this solves the attack vector fees had).
Just like with fees, the "bookkeeping" of the cancellation is done at the user-to-user level. Anyone who tries to cheat, will impact only their own relationships (as long as those relationships do not also cheat). So just like with fees, there is no "transitivity of trust" problem. My fee system I already implemented demonstrated this.
My goal with my multi-server implementation was simplicity, but the response I got made the lock-credit-attack out to be system-breaking and so I tried to address that attack vector. Ryan's original solution is not the solution (because the race condition is detrimental and this motivated global consensus shift originally), but my fee system was also not the solution. Ryan's idea would be fixed if the "race condition" was... slower acting, smaller penalties instead of full amount. My fee system would be fixed if... intermediaries had an incentive to propagate the "buyer-acknowledges-everyone-has-commited-and-revokes-the-right-to-cancel" signal. The mechanism that both of those things can be placed in between my idea and Ryan's idea.
I dislike this because it is pretty complex. But I am not aware of anyone having a good solution to multi-server Ripple that addresses lock-credit-attack in a way that people here seem to think is required. So I wanted to mention this here (as I already asked for space here by sharing my fee system, only to later say it did not work, and I already pointed out one way Ryan's idea could be fixed but not how to set up the condition required for it, and I here mention both those things might be possible to do with a single mechanism placed in between mine and Ryan's idea).
Of course this all also suggests my analysis of the problem with multi-server Ripple having been lack of understanding of two-general problem might be false but there also might be a sliver of truth to it as global consensus does solve that problem and running into a "wall" with Ripple you might feel less motivated to focus too much on consensus mechanisms as they add complexity and when inventing things you want to minimize the parts you work with so your brain can manage them.
I might be wrong on this idea, will need a few days to think about it and to implement it, but it did seem promising and since I set up for it already with my previous comment here I just mention it in full now.
Johan
My idea that the buyer first does commit towards seller, and the buyer retains the right to cancel until the seller signals them the commit succeeded, and there is a fee system to prevent "lock credit attack", could be combined with Ryan's "seller finalizes" to set up the penalty for delaying in propagating.
On their own, Ryan's idea and my idea are pretty simple. But neither work (if perfect defense against lock-credit-attack is a requirement). Combined, it gets a bit complex. But not overly complex.
What is needed to glue the mechanisms together, is the same mechanism that has to act on Ryan's idea, a "continuous cancellation". This starts the moment the buyer-to-seller-commit succeeds and the buyer revokes their right to cancel. The cancellation has to happen faster than the fees, thus, an intermediary who does not propagate the signal ends up carrying the burden of the fees (this solves the attack vector fees had).
Just like with fees, the "bookkeeping" of the cancellation is done at the user-to-user level. Anyone who tries to cheat, will impact only their own relationships (as long as those relationships do not also cheat). So just like with fees, there is no "transitivity of trust" problem. My fee system I already implemented demonstrated this.
My goal with my multi-server implementation was simplicity, but the response I got made the lock-credit-attack out to be system-breaking and so I tried to address that attack vector. Ryan's original solution is not the solution (because the race condition is detrimental and this motivated global consensus shift originally), but my fee system was also not the solution. Ryan's idea would be fixed if the "race condition" was... slower acting, smaller penalties instead of full amount. My fee system would be fixed if... intermediaries had an incentive to propagate the "buyer-acknowledges-everyone-has-commited-and-revokes-the-right-to-cancel" signal. The mechanism that both of those things can be placed in between my idea and Ryan's idea.
I dislike this because it is pretty complex. But I am not aware of anyone having a good solution to multi-server Ripple that addresses lock-credit-attack in a way that people here seem to think is required. So I wanted to mention this here (as I already asked for space here by sharing my fee system, only to later say it did not work, and I already pointed out one way Ryan's idea could be fixed but not how to set up the condition required for it, and I here mention both those things might be possible to do with a single mechanism placed in between mine and Ryan's idea).
Of course this all also suggests my analysis of the problem with multi-server Ripple having been lack of understanding of two-general problem might be false but there also might be a sliver of truth to it as global consensus does solve that problem and running into a "wall" with Ripple you might feel less motivated to focus too much on consensus mechanisms as they add complexity and when inventing things you want to minimize the parts you work with so your brain can manage them.
I might be wrong on this idea, will need a few days to think about it and to implement it, but it did seem promising and since I set up for it already with my previous comment here I just mention it in full now.
Johan
Johan Nygren
Mar 25, 2025, 1:00:14 PMMar 25
to Ripple Project
Have now implemented the combination of my idea and Ryan's idea,
https://bitbucket.org/bipedaljoe/ripple/commits/b8004ca78399a0b21228529e055e45ef23d6e516
My fee system is now being used to make Ryan's idea work without a race condition.
And, Ryan's idea allows my fee system to work (now anyone who has done SEAL_PAYMENT continues to do CollectFees() but they stop adding claimed amount to balance, thus only cancelling it, see code here)
The amount of code needed to change was just a few lines
Melvin what do you think? And/or anyone else have comments? This ended up different from the premise of my post here where I claimed "you all got it wrong", but this solution here still claims the idea to use global consensus and "hash locks" is all wrong, and comes from a failure to solve person-to-person coordination, not from that it is impossible to solve it. But since I realized (after opening this thread) that my fee system was not secure, and realized that it could be fixed if I simply combine it with Ryan's idea and use it to remove the race condition from Ryan's idea, it seems I might have been right, just a bit premature.
Johan
https://bitbucket.org/bipedaljoe/ripple/commits/b8004ca78399a0b21228529e055e45ef23d6e516
My fee system is now being used to make Ryan's idea work without a race condition.
And, Ryan's idea allows my fee system to work (now anyone who has done SEAL_PAYMENT continues to do CollectFees() but they stop adding claimed amount to balance, thus only cancelling it, see code here)
The amount of code needed to change was just a few lines
Melvin what do you think? And/or anyone else have comments? This ended up different from the premise of my post here where I claimed "you all got it wrong", but this solution here still claims the idea to use global consensus and "hash locks" is all wrong, and comes from a failure to solve person-to-person coordination, not from that it is impossible to solve it. But since I realized (after opening this thread) that my fee system was not secure, and realized that it could be fixed if I simply combine it with Ryan's idea and use it to remove the race condition from Ryan's idea, it seems I might have been right, just a bit premature.
Johan
Johan Nygren
Mar 26, 2025, 5:40:01 AMMar 26
to Ripple Project
Now simplified to that fees are used both in "seal" and "commit" phase. This ensures any intermediary stuck in reserve credit attack always gets paid, as they always collect fees if they have reserved credit and the payment timed out. (The previous idea where "seal" only cancelled allowed buyer+intermediary combined attack where they succeeded with the payment but from the intermediary, and then simply let the segment between buyer and intermediary slowly cancel, locking credit that entire time. This is no longer possible, as any intermediary affected by attack now is guaranteed to be paid).
No transitivity of trust problem. A cheater only impacts their own relationships. Thus, people who are affected by cheaters have trusted a cheater. And can simply revoke that trustline. Transitivity of trust problem is when someone far away can affect you, here it has to be your own friend cheating.
Added the rule change to codebase (i.e., simplified to using my original fee system only and not the "alternative" one in "seal" phase...), https://bitbucket.org/bipedaljoe/ripple/commits/48dc67f47bc9ab28d42c88c172b41527de3e11b1
So my rationale for how to solve reserve-credit-attack is very simple: Any intermediary affected simply collects fees. The victim resolves the attack they suffer by themselves and becomes the winner. Very simple idea. But it requires Ryan's original finalization idea (seller finalizes) and co-incidentally it also makes Ryan's original idea work since it reduces the penalty and thereby removes the race condition - the same race condition that motivated the shift to "global consensus" in 2011 soon after Satoshi - Craig - had launched Bitcoin.
Johan
No transitivity of trust problem. A cheater only impacts their own relationships. Thus, people who are affected by cheaters have trusted a cheater. And can simply revoke that trustline. Transitivity of trust problem is when someone far away can affect you, here it has to be your own friend cheating.
Added the rule change to codebase (i.e., simplified to using my original fee system only and not the "alternative" one in "seal" phase...), https://bitbucket.org/bipedaljoe/ripple/commits/48dc67f47bc9ab28d42c88c172b41527de3e11b1
So my rationale for how to solve reserve-credit-attack is very simple: Any intermediary affected simply collects fees. The victim resolves the attack they suffer by themselves and becomes the winner. Very simple idea. But it requires Ryan's original finalization idea (seller finalizes) and co-incidentally it also makes Ryan's original idea work since it reduces the penalty and thereby removes the race condition - the same race condition that motivated the shift to "global consensus" in 2011 soon after Satoshi - Craig - had launched Bitcoin.
Johan
Johan Nygren
Mar 26, 2025, 8:56:01 AMMar 26
to Ripple Project
To communicate this is clearly as possible. Ryan's original idea was to use fees to apply a force on whoever had the net negative balance. This is possible when finalizing from the seller, since each "hop" ends up with the net negative balance. But Ryan used a very crude fee: the full payment. His idea thus had a race condition that made the idea practically not usable. If you reduce the penalty, you still have the exact same enforcement mechanism but in a way that is practically usable. But you need to set up this agreement to start with. For this, you can make use of the same rationale as Ryan had for the seller finalizes idea: that fees apply a force on whoever had the net negative balance. Just like seller-finalizes, the buyer cancels signal causes each "hop" to end up with the net negative balance. With that, you have what you need to set up the agreement to apply a reduced penalty Ryan's on seller-finalizes. You can have a "commit" step that prepares for the improved seller-finalizes step, by applying the reduced penalty. And you can be absolutely certain that this step either succeeds or cancels, because the buyer is forced to cancel if it does not succeed (with exact same type of enforcement mechanism as the force in Ryan's seller-finalizes: a penalty fee). Thus you there almost everything you need. And it is all very simple. Very reasonable. Then you also need one more step. A step that explicitly revokes the buyers right to cancel (otherwise, the buyer could issue cancel and the seller could issue finalize...) This "SEAL_PAYMENT" command can also be enforced, as you can apply the fee mechanism on either side of an intermediary who does not propagate the signal. This is slightly harder to conceptually understand than the enforcement of buyer cancels or seller finalizes, but it is not that hard.
The reason I came up with this is because I thought for myself. Instead of buying Ryan's idea that the seller finalizes was the solution, I did thinking by myself. I did so because clearly, it has been 15 years and no one has built multi--server Ripple. If Ryan was right, where is the actual platform? So I came up with a design on my own, built the platform over a year (12 hours of work on many days) and then posted here in this group. Based on the feedback I got here (very negative) I looked more at Ryan's original idea and I noticed that the exact same logic as in Ryan's idea - but in an exact opposite way - applied to the design I came up with. My "buyer cancels" mechanism could be enforced with a penalty fee just like Ryan´s "seller finalizes" could. And co-incidentally but also pretty predictably, I noticed you could combine the two. This is predictable because both buyer cancels and seller finalizes are the primary signals that can be enforced by penalty fees. And so it is very reasonable a design might end up including both, it is two of the main "buttons" you can push when trying to manipulate the coordination process.
Anyone interested very welcome to correspond. Thank you Melvin so far for engaging in the discussion. Hopefully what I write here is easy for anyone to comprehend and would seem pretty reasonable. I already implemented the exact system I describe and it is on https://bitbucket.org/bipedaljoe/ripple/.
The reason I came up with this is because I thought for myself. Instead of buying Ryan's idea that the seller finalizes was the solution, I did thinking by myself. I did so because clearly, it has been 15 years and no one has built multi--server Ripple. If Ryan was right, where is the actual platform? So I came up with a design on my own, built the platform over a year (12 hours of work on many days) and then posted here in this group. Based on the feedback I got here (very negative) I looked more at Ryan's original idea and I noticed that the exact same logic as in Ryan's idea - but in an exact opposite way - applied to the design I came up with. My "buyer cancels" mechanism could be enforced with a penalty fee just like Ryan´s "seller finalizes" could. And co-incidentally but also pretty predictably, I noticed you could combine the two. This is predictable because both buyer cancels and seller finalizes are the primary signals that can be enforced by penalty fees. And so it is very reasonable a design might end up including both, it is two of the main "buttons" you can push when trying to manipulate the coordination process.
Anyone interested very welcome to correspond. Thank you Melvin so far for engaging in the discussion. Hopefully what I write here is easy for anyone to comprehend and would seem pretty reasonable. I already implemented the exact system I describe and it is on https://bitbucket.org/bipedaljoe/ripple/.
Johan
David Watson
Mar 26, 2025, 11:10:58 AMMar 26
to Ripple Project
Johan,
I’ve been following your posts a bit over the past couple of weeks. However, I’m still confused by the semantics—and honestly, I’m not even aware of the "account-level consensus" problem in the way you’re describing it. It sounds more like a technical implementation issue related to multi-server deployment, rather than a core reason this idea hasn’t “taken off.”
I’m curious what you see as the breakthrough. Can you describe it in plain language? It sounds like you're tying it to this “fee” system as a counter-strategy to what you're calling the “reserve credit attack,” and that this, in your view, makes the system "theoretically implementable." But people actually using and adopting it is tied up with a whole other host of problems (e.g., education, marketing, investment, adoption, etc.).
I'm asking because—even though the semantics are completely different—I also had a breakthrough years ago while working with Ripple. Hearing you talk about your fee-based solution reminds me of my own "reserve distribution algorithm"-centered breakthrough, which I called Metric Reserve. I formalized the idea around 2015 but didn’t build a working prototype until April 2017 (there’s a post about it in this thread).
I never struggled with server-to-server issues, because to me, the distributed implementation was less important than understanding the user side: “Why would I want to use this?” My issue with Ripple stemmed from its one-sided view of "extending credit" without addressing how to collect debt. First, most people who adopt a system like this aren’t going to extend credit—they’re just going to buy credits in some currency. Second, I wanted a system that wasn't necessarily debt-based. While you can extend credit, most of the people I know (outside this Ripple group) want a money system that’s reserve-based, so we aren’t beholden to always-on servers just to use money.
So, there will be some people who use the system for its utility, and others—reserve nodes—who are interested in the system continuing to operate as a whole.
But... like you, I’ve always loved the idea that everyone is “their own bank,” and the nature of the graph makes it possible to reconcile a payment through a network of credit/reserve connections.
Let me explain my concept as simply as I can:
1. What is Ripple (to me):
Ripple is a mathematical graph of user accounts where each vertex is a user, and each edge represents a credit/payment relationship. Between any two nodes, there can be zero or more edges, where each one represents a credit extension in some currency. The protocol doesn’t enforce the terms of credit—participants define those. Assuming the network is ubiquitous, Ripple allows me to pay or be paid in the currency of my choice with anyone, while only managing credit arrangements with my chosen peers.
2. Changing the Semantics of Credit:
The first thing I did was stop thinking of Ripple strictly in terms of credit. If you don’t trust me enough to lend but you do trust me enough to be connected, I can give you $10 to hold, and then you extend me $10 credit. Now I can spend that $10. If the expenditure ends up coming back to you, then you already hold the reserve—it’s like a bank cashing a check.
If I later choose to exit the system, I just ask for my $10 back. Simple.
The way Ripple treats everything as “credit” is just a semantic layer—Ripple could just as easily represent a 100% gold-backed reserve system, as long as we normalize “adding reserves” and “paying debt” appropriately.
3. The Core Payment Problem:
Changing semantics doesn’t fix the real issue: Even if I have $10 in balance, I can't spend it with everyone in the network—even if there’s a payment route—because of dynamic conditions. Someone between me and the payee might disconnect or spend the intermediary balance before I get there.
4. My Solution / Breakthrough:
Connectedness can be solved. You can run a connectedness algorithm frequently on even large graphs. But there's no guarantee that “credit” exists when needed. So if I’m paying $10 in reserves to my neighbor (not his money—just collateral), he could pass that along to the payee. This is basically Hawala.
Now imagine others doing the same: their $10 flows along paths in the network. But the recipients are also Ripple users—they don’t want the reserve; they just need their intermediaries to feel secure enough to complete the trade.
So what happens with all this floating reserve? It’s only relevant when someone is adding or withdrawing money. Otherwise, it’s the mirror image of the payment routing problem. Reserves move around, balances fluctuate—but once everyone “gets it,” the system normalizes:
💡 Each non-leaf node should hold a reserve balance equal to the total positive system balance divided across reserve nodes.
To “buy” a balance, you pay reserves to your neighbors. To “cash out,” you withdraw reserves. This triggers backflows that re-balance the graph.
As long as you're connected, you can always pay your full balance to any node. The receiver only cashes out if they choose to, and reserves flow backward from their neighbors.
In short, my breakthrough was realizing that reserve-based flow removes the need for full balance routing. By standardizing the way edges are created (deposit-based instead of credit-based), and by agreeing on how reserves are paid back, you get a functional, decentralized money system.
5. Technical Implementation:
When I built Metric Reserve in Python (https://github.com/wizardwatson/metricreserve), the novel part was an algorithm that evenly distributed reserves in a Ripple-like graph. It generated instructions like:
"At next rendezvous, transfer $75 in reserves to peer 375902345 (Steve Smith)."
It automated the “boring” part of reserve balancing.
Okay—maybe not so short, but that’s the gist.
I go through the trouble of writing this because you seem passionate, and when you talk about your fee-based solution, it reminds me of the kind of graph-level thinking I had during my own breakthrough.
For what it’s worth: I don’t think what I built is all that remarkable anymore. I didn't even think it was when I got around to coding it in 2017. It's just not as earth-shattering of a revalation as it was when I first got into Ripple in 2007–2008. Could it be amazing if adopted at scale? Sure. But the problem of adoption is not a technical one. There are many human obstacles—culture, behavior, motivation—that hold these ideas back more than code ever will.
So when you say, “I’ve already solved it!”—just remember: many others have solved various technical problems too. My solution sidesteps most of what you're discussing, and in my opinion, it still fully implements the “be your own bank” ethos.
Hope this helps.
—David W.
Johan Nygren
Mar 26, 2025, 11:52:54 AMMar 26
to Ripple Project
David, from your post history you see Ripple as "basically lightning network" so seems to suggest you think there should be a global consensus to fall back on.
Many here like the idea of person-to-person-only Ripple, and it is unrelated to "lightning is basically Ripple". Could you clarify if your model is actually person-to-person-only or if it is similar to your previous ideas? As I was not able to see that at first glance or see what it was.
re: "I’m not even aware of the "account-level consensus" problem in the way you’re describing it. It sounds more like a technical implementation issue related to multi-server deployment, rather than a core reason this idea hasn’t “taken off.” "
Yes I exaggerated that. But, since Ryan did fall back on global consensus (and it does solve the two-general problem) and RipplePay also did not have a two-general problem, it is possible that also focusing on a good consensus mechanism was overburdening. So I think I had a point but since my design now continues on Ryan's seller finalizes idea (combines it exactly with the idea I had up to the point I combined them), the account consensus issue was not the main issue. I also think people could have been running a less secure multi-server Ripple for the past years if "reserve credit attack" had been tolerated btw, and what I had finished before I even posted here was secure enough for something like that but I wanted to meet the response I got half way, and so I did.
re: "I go through the trouble of writing this because you seem passionate, and when you talk about your fee-based solution, it reminds me of the kind of graph-level thinking I had during my own breakthrough."
I shared my work for those interested, not for anyone to go through the trouble of responding because they feel sympathy because they are reminded of their own work, but if they are interested in what I suggest as a solution. Melvin has said he was interested. Douglas reached out over email. Daniel has said years ago he saw Resilience (swarm redistribution) as next step for Ripple. And Michiel has said here he is interested, and we have corresponded, and he has inspired the fee system actually.
re: "It sounds like you're tying it to this “fee” system as a counter-strategy to what you're calling the “reserve credit attack,” and that this, in your view, makes the system "theoretically implementable." "
The reserve credit attack is what motivated Ryan Fugger to use the staggered timeouts and the seller finalizes. It is part of it, so the type of attack is well known among people interested in Ripple. The other part of Ryan's "seller finalizes" idea (that Interledger ended up using) was you also get an incentive as you have a penalty and that type of penalty can only act on users with a net negative balance. The problem with Ryan's idea is the penalty is too large. This creates what Ryan has historically referred to as "a distributed race condition" and it makes his idea not work. If you reduce the size of the penalty, you remove that race condition. To do this, you need to make gradually cancel chunks of the payment while the finalize wave happens. This is all very reasonable and easy to understand ideas, that tie into the main discourse around multi-server Ripple for 20 years.
re: " I’m curious what you see as the breakthrough. Can you describe it in plain language?"
I think Ripple can be done person-to-person only. Whereas some want to fall back on global consensus. Assuming that goal, I came up with a pretty good multi-hop coordination system, but the critique from Ryan was that it was not secure against the reserve-credit-attack. Curiously, my solution was the exact opposite of the one Ryan had for 15 years. Both exploit the same incentive: a penalty that can act only on those with net negative balance. This incentive can naturally be used for: "seller finalizes" (as Ryan has done for 15+ years) but also for "buyer cancels" (as I used in my version). In Ryan's idea, his penalty was too big (whole payment) whereas in my idea, the fee system could not deal with finalize signal. Simply placing Ryan's idea after my idea makes it work. Curiously. I already implemented the code for it.
Besides that, taking turns for account consensus could be innovative too, have had feedback from people who think it is. But yes, not groundbreaking. Ryan described similar ideas back in 2006 more or less (although in simpler / less good form).
Anyone interested in my suggestion for how Ryan's seller finalizes can be fixed by removing the race condition, and how my ideas up until a few days ago actually can achieve that, very welcome to correspond here, or email or something like Telegram.
Johan
Many here like the idea of person-to-person-only Ripple, and it is unrelated to "lightning is basically Ripple". Could you clarify if your model is actually person-to-person-only or if it is similar to your previous ideas? As I was not able to see that at first glance or see what it was.
re: "I’m not even aware of the "account-level consensus" problem in the way you’re describing it. It sounds more like a technical implementation issue related to multi-server deployment, rather than a core reason this idea hasn’t “taken off.” "
Yes I exaggerated that. But, since Ryan did fall back on global consensus (and it does solve the two-general problem) and RipplePay also did not have a two-general problem, it is possible that also focusing on a good consensus mechanism was overburdening. So I think I had a point but since my design now continues on Ryan's seller finalizes idea (combines it exactly with the idea I had up to the point I combined them), the account consensus issue was not the main issue. I also think people could have been running a less secure multi-server Ripple for the past years if "reserve credit attack" had been tolerated btw, and what I had finished before I even posted here was secure enough for something like that but I wanted to meet the response I got half way, and so I did.
re: "I go through the trouble of writing this because you seem passionate, and when you talk about your fee-based solution, it reminds me of the kind of graph-level thinking I had during my own breakthrough."
I shared my work for those interested, not for anyone to go through the trouble of responding because they feel sympathy because they are reminded of their own work, but if they are interested in what I suggest as a solution. Melvin has said he was interested. Douglas reached out over email. Daniel has said years ago he saw Resilience (swarm redistribution) as next step for Ripple. And Michiel has said here he is interested, and we have corresponded, and he has inspired the fee system actually.
re: "It sounds like you're tying it to this “fee” system as a counter-strategy to what you're calling the “reserve credit attack,” and that this, in your view, makes the system "theoretically implementable." "
The reserve credit attack is what motivated Ryan Fugger to use the staggered timeouts and the seller finalizes. It is part of it, so the type of attack is well known among people interested in Ripple. The other part of Ryan's "seller finalizes" idea (that Interledger ended up using) was you also get an incentive as you have a penalty and that type of penalty can only act on users with a net negative balance. The problem with Ryan's idea is the penalty is too large. This creates what Ryan has historically referred to as "a distributed race condition" and it makes his idea not work. If you reduce the size of the penalty, you remove that race condition. To do this, you need to make gradually cancel chunks of the payment while the finalize wave happens. This is all very reasonable and easy to understand ideas, that tie into the main discourse around multi-server Ripple for 20 years.
re: " I’m curious what you see as the breakthrough. Can you describe it in plain language?"
I think Ripple can be done person-to-person only. Whereas some want to fall back on global consensus. Assuming that goal, I came up with a pretty good multi-hop coordination system, but the critique from Ryan was that it was not secure against the reserve-credit-attack. Curiously, my solution was the exact opposite of the one Ryan had for 15 years. Both exploit the same incentive: a penalty that can act only on those with net negative balance. This incentive can naturally be used for: "seller finalizes" (as Ryan has done for 15+ years) but also for "buyer cancels" (as I used in my version). In Ryan's idea, his penalty was too big (whole payment) whereas in my idea, the fee system could not deal with finalize signal. Simply placing Ryan's idea after my idea makes it work. Curiously. I already implemented the code for it.
Besides that, taking turns for account consensus could be innovative too, have had feedback from people who think it is. But yes, not groundbreaking. Ryan described similar ideas back in 2006 more or less (although in simpler / less good form).
Anyone interested in my suggestion for how Ryan's seller finalizes can be fixed by removing the race condition, and how my ideas up until a few days ago actually can achieve that, very welcome to correspond here, or email or something like Telegram.
Johan
Johan Nygren
Mar 26, 2025, 11:56:05 AMMar 26
to Ripple Project
re: " I’m curious what you see as the breakthrough. Can you describe it in plain language?"
My whitepaper is updated and is very plain language, https://ripple.archi/ripple-multi-server.pdf (but so was my post here)Johan
David Watson
Mar 26, 2025, 4:09:48 PMMar 26
to Ripple Project
Johan,
I think I understand the general idea.
I do think that penalizing intermediaries for failing to propagate payment requests, by paying the victims in the same currency they are unable to transact with in the first place, is next level confusing. If this is all intended to happen in seconds, then obviously, for such a system to work, there would be up front agreement about fee rates and availability, SLA's, etc. This is all happening at server level, not user level. You're going to require consensus either operationally through general agreements and protocol (i.e. like any private bank) or technically (e.g. Bitcoin). Wherever you move this "Ripple problem" around to, you're doing one or the other.
I'm all for figuring these things out operationally at first. We could start a banking system with a network of pawn shops (operational example). You could also start a banking system by bolting RipplePay onto a blockchain using Metric Reserve concept with no modification. However, you still need some operational agreements (e.g. "what's the withdrawal rate limit?", "How do we deal with non-reserve propagating nodes). System stability, usability, and integrity will require refinement beyond the technical level. You could even combine your fee system with Metric Reserve concept, for instance, requiring all participants on the network level (your server to server idea) maintain a redeemable reserve currency (bitcoin maybe) to pay those fees. Similar to Ethereum "gas" concept.
Anyway, never said I was sympathetic, just curious and being generous with my time.
You are bogged down in the esoteric world of P2P message consensus as applies to Ripple scenarios. I understand your proposed solution to this esoteric problem enough to know that there are other solutions to this problem that could work. I also think it's not a core issue with adoption.
David W.
I think I understand the general idea.
I do think that penalizing intermediaries for failing to propagate payment requests, by paying the victims in the same currency they are unable to transact with in the first place, is next level confusing. If this is all intended to happen in seconds, then obviously, for such a system to work, there would be up front agreement about fee rates and availability, SLA's, etc. This is all happening at server level, not user level. You're going to require consensus either operationally through general agreements and protocol (i.e. like any private bank) or technically (e.g. Bitcoin). Wherever you move this "Ripple problem" around to, you're doing one or the other.
I'm all for figuring these things out operationally at first. We could start a banking system with a network of pawn shops (operational example). You could also start a banking system by bolting RipplePay onto a blockchain using Metric Reserve concept with no modification. However, you still need some operational agreements (e.g. "what's the withdrawal rate limit?", "How do we deal with non-reserve propagating nodes). System stability, usability, and integrity will require refinement beyond the technical level. You could even combine your fee system with Metric Reserve concept, for instance, requiring all participants on the network level (your server to server idea) maintain a redeemable reserve currency (bitcoin maybe) to pay those fees. Similar to Ethereum "gas" concept.
Anyway, never said I was sympathetic, just curious and being generous with my time.
You are bogged down in the esoteric world of P2P message consensus as applies to Ripple scenarios. I understand your proposed solution to this esoteric problem enough to know that there are other solutions to this problem that could work. I also think it's not a core issue with adoption.
David W.
Melvin Carvalho
Mar 26, 2025, 5:24:22 PMMar 26
to rippl...@googlegroups.com
Johan,
I think I understand the general idea.
I do think that penalizing intermediaries for failing to propagate payment requests, by paying the victims in the same currency they are unable to transact with in the first place, is next level confusing. If this is all intended to happen in seconds, then obviously, for such a system to work, there would be up front agreement about fee rates and availability, SLA's, etc. This is all happening at server level, not user level. You're going to require consensus either operationally through general agreements and protocol (i.e. like any private bank) or technically (e.g. Bitcoin). Wherever you move this "Ripple problem" around to, you're doing one or the other.
I'm all for figuring these things out operationally at first. We could start a banking system with a network of pawn shops (operational example). You could also start a banking system by bolting RipplePay onto a blockchain using Metric Reserve concept with no modification. However, you still need some operational agreements (e.g. "what's the withdrawal rate limit?", "How do we deal with non-reserve propagating nodes). System stability, usability, and integrity will require refinement beyond the technical level. You could even combine your fee system with Metric Reserve concept, for instance, requiring all participants on the network level (your server to server idea) maintain a redeemable reserve currency (bitcoin maybe) to pay those fees. Similar to Ethereum "gas" concept.
Anyway, never said I was sympathetic, just curious and being generous with my time.
You are bogged down in the esoteric world of P2P message consensus as applies to Ripple scenarios. I understand your proposed solution to this esoteric problem enough to know that there are other solutions to this problem that could work. I also think it's not a core issue with adoption.
The way I see it is lots of little trust lines working together. Bit short on time right now, but I'm inspired to run or build some code. I find it great food for thought, even if I admit I dont understand 100% of everything *right now*...
To view this discussion visit https://groups.google.com/d/msgid/rippleusers/86d74cd9-e74e-49ca-a067-a0d6399c5aafn%40googlegroups.com.
Johan Nygren
Mar 27, 2025, 5:32:47 AMMar 27
to Ripple Project
David as I said, you have publicly here had a stance that "lightning network is basically Ripple". I do not agree and many others here might not agree.
re: "You are bogged down in the esoteric world of P2P message consensus as applies to Ripple scenarios."
I think Ripple can be done entirely person-to-person. Many others here are interested in doing so as well. You have publicly shown here for years (a decade? maybe more?) you instead see Ripple as "just lightning network". That is known already by people here.
re: " I do think that penalizing intermediaries for failing to propagate payment requests, by paying the victims in the same currency they are unable to transact with in the first place, is next level confusing. "
You reject person-to-person-only implementation of Ripple to start with. Of course you lack focus on the idea to start with. It would be confusing to even try and think about it as you have cognitive dissonance from believing Ripple is "just lightning network". It never was.
I think what I describe is very easy to understand and explained very clearly. My whitepaper is very well articulated: https://ripple.archi/ripple-multi-server.pdf. I simply formally define (game theoretically) the same mechanisms Ryan Fugger was working with 15 years ago. I show there mechanism can be applied not just at "seller finalizes" but also at the opposite scenario, "buyer cancels", and for same reasons. I show the penalty can be made more sophisticated by regulating the size of the penalty (rather than all or nothing). This is very easily understood concepts.
re: " If this is all intended to happen in seconds, then obviously, for such a system to work, there would be up front agreement about fee rates and availability, SLA's, etc. This is all happening at server level, not user level. "
The fee come into use as "failsafe" if payment fails because of an attack (or also when there is network failure but the point of fees is attacks). Without attack the payment happens in seconds and the fees never come into use. Fee rates are agreed on in a "swarm" mechanism, every person sets their own FEE_RATE and if people do not similar values you only impact your own friends. No need to have up front agreement. Server level is similar to user level in multi-server Ripple, in my implementation server is single-user only, but even on multi-user server agreement is exact same: each user sets FEE_RATE themselves.
re: " Anyway, never said I was sympathetic, just curious and being generous with my time. "
I am not writing into a void, there are people here interested like Melvin and Michiel and there are people interested in Resilience too (my 2012 invention) that is already implemented together with the multihop coordination I defined in past week. It already works. My interest was always Resilience system (swarm redistribution) but no one else built multi-server Ripple so I had to do so.
Anyone interested is very welcome to correspond. I spent a year building a multi-server Ripple implementation. The feedback from Ryan was (as I understand) the "lock credit attack" made it unusable. I attempted to fix that attack, came up with a good solution but it was only good up until the last step in it. It was more or less the exact opposite approach to what Ryan had 15 years ago. Co-incidentally, just adding Ryan's idea after my idea seems to make it work. It has all been implemented already, https://bitbucket.org/bipedaljoe/ripple (and see https://ripple.archi for more info).
Johan
re: "You are bogged down in the esoteric world of P2P message consensus as applies to Ripple scenarios."
I think Ripple can be done entirely person-to-person. Many others here are interested in doing so as well. You have publicly shown here for years (a decade? maybe more?) you instead see Ripple as "just lightning network". That is known already by people here.
re: " I do think that penalizing intermediaries for failing to propagate payment requests, by paying the victims in the same currency they are unable to transact with in the first place, is next level confusing. "
You reject person-to-person-only implementation of Ripple to start with. Of course you lack focus on the idea to start with. It would be confusing to even try and think about it as you have cognitive dissonance from believing Ripple is "just lightning network". It never was.
I think what I describe is very easy to understand and explained very clearly. My whitepaper is very well articulated: https://ripple.archi/ripple-multi-server.pdf. I simply formally define (game theoretically) the same mechanisms Ryan Fugger was working with 15 years ago. I show there mechanism can be applied not just at "seller finalizes" but also at the opposite scenario, "buyer cancels", and for same reasons. I show the penalty can be made more sophisticated by regulating the size of the penalty (rather than all or nothing). This is very easily understood concepts.
re: " If this is all intended to happen in seconds, then obviously, for such a system to work, there would be up front agreement about fee rates and availability, SLA's, etc. This is all happening at server level, not user level. "
The fee come into use as "failsafe" if payment fails because of an attack (or also when there is network failure but the point of fees is attacks). Without attack the payment happens in seconds and the fees never come into use. Fee rates are agreed on in a "swarm" mechanism, every person sets their own FEE_RATE and if people do not similar values you only impact your own friends. No need to have up front agreement. Server level is similar to user level in multi-server Ripple, in my implementation server is single-user only, but even on multi-user server agreement is exact same: each user sets FEE_RATE themselves.
re: " Anyway, never said I was sympathetic, just curious and being generous with my time. "
I am not writing into a void, there are people here interested like Melvin and Michiel and there are people interested in Resilience too (my 2012 invention) that is already implemented together with the multihop coordination I defined in past week. It already works. My interest was always Resilience system (swarm redistribution) but no one else built multi-server Ripple so I had to do so.
Anyone interested is very welcome to correspond. I spent a year building a multi-server Ripple implementation. The feedback from Ryan was (as I understand) the "lock credit attack" made it unusable. I attempted to fix that attack, came up with a good solution but it was only good up until the last step in it. It was more or less the exact opposite approach to what Ryan had 15 years ago. Co-incidentally, just adding Ryan's idea after my idea seems to make it work. It has all been implemented already, https://bitbucket.org/bipedaljoe/ripple (and see https://ripple.archi for more info).
Johan
Johan Nygren
Mar 27, 2025, 7:42:45 AMMar 27
to Ripple Project
re: "The way I see it is lots of little trust lines working together. Bit short on time right now, but I'm inspired to run or build some code. I find it great food for thought, even if I admit I dont understand 100% of everything *right now*... "
Thank you Melvin for engaging in the discussion. Your interest in person-to-person-only Ripple and you joining the thread originally has contributed to me discovering that my idea could simply be combined with Ryan's. Yes if my ideas are any good anyone should be able to independently verify them (such as disproving my idea before I added Ryan's idea after it...) And maybe not instantly but over enough time.
To anyone new to the thread: the thread took a strange twist since the proof I suggested of Ryan being wrong (the reserve-credit-attack actually being solvable person-to-person-only) actually proved my initial idea wrong: my fees did not prevent the attack, they only changed who could do the attack. But by a strange co-incidence, my system could be simply combined with Ryan's 15 year old "seller finalizes", with no other modifications. And the reserve-credit-attack was actually prevented. This might seem strange but my idea and Ryan's idea had exact opposite priorities or starting points. They both exploit the exact same game theoretical mechanism (that I have now formalized in my whitepaper) but in exact opposite parts of the payment. So it is actually quite reasonable that Ryan had half a solution, and I was very motivated so I tried to find a solution and I found half a solution as well. And combined you have a complete defense against reserve credit attack.
Anyone can clearly see Ryan did not have a full solution. The "seller finalizes" has a race condition. Ryan has been clear about this race condition since he first suggested seller finalizes.
Anyone could also see that my "buyer cancels" approach is pretty clever too, once you add the fees (and I always suggested buyer was not in position to attack as they were in net negative balance and the users in the payment could easily exert force on them), but that it was also half a solution as it failed once "commit" was done. And anyone could see I had built a complete system with it that worked, had good simulations to prove it, and had a very well designed consensus mechanism too (plus good path finding etc...)
So you have two halves of a solution. These can be simply combined with nothing more added.
Already in my codebase on https://bitbucket.org/bipedaljoe/ripple/. It works.
The game theory is easily described in my whitpaper: https://ripple.archi/ripple-multi-server.pdf.
Also when verifying the fee idea, possible to first consider it in a central server context similar to RipplePay before verifying my decentralized coordination of it (the FEE_RATE...) although the fees would be meaningless on RipplePay as there is no reserve-credit-attack vector there...
Johan
Thank you Melvin for engaging in the discussion. Your interest in person-to-person-only Ripple and you joining the thread originally has contributed to me discovering that my idea could simply be combined with Ryan's. Yes if my ideas are any good anyone should be able to independently verify them (such as disproving my idea before I added Ryan's idea after it...) And maybe not instantly but over enough time.
To anyone new to the thread: the thread took a strange twist since the proof I suggested of Ryan being wrong (the reserve-credit-attack actually being solvable person-to-person-only) actually proved my initial idea wrong: my fees did not prevent the attack, they only changed who could do the attack. But by a strange co-incidence, my system could be simply combined with Ryan's 15 year old "seller finalizes", with no other modifications. And the reserve-credit-attack was actually prevented. This might seem strange but my idea and Ryan's idea had exact opposite priorities or starting points. They both exploit the exact same game theoretical mechanism (that I have now formalized in my whitepaper) but in exact opposite parts of the payment. So it is actually quite reasonable that Ryan had half a solution, and I was very motivated so I tried to find a solution and I found half a solution as well. And combined you have a complete defense against reserve credit attack.
Anyone can clearly see Ryan did not have a full solution. The "seller finalizes" has a race condition. Ryan has been clear about this race condition since he first suggested seller finalizes.
Anyone could also see that my "buyer cancels" approach is pretty clever too, once you add the fees (and I always suggested buyer was not in position to attack as they were in net negative balance and the users in the payment could easily exert force on them), but that it was also half a solution as it failed once "commit" was done. And anyone could see I had built a complete system with it that worked, had good simulations to prove it, and had a very well designed consensus mechanism too (plus good path finding etc...)
So you have two halves of a solution. These can be simply combined with nothing more added.
Already in my codebase on https://bitbucket.org/bipedaljoe/ripple/. It works.
The game theory is easily described in my whitpaper: https://ripple.archi/ripple-multi-server.pdf.
Also when verifying the fee idea, possible to first consider it in a central server context similar to RipplePay before verifying my decentralized coordination of it (the FEE_RATE...) although the fees would be meaningless on RipplePay as there is no reserve-credit-attack vector there...
Johan
Johan Nygren
Apr 5, 2025, 1:27:31 PMApr 5
to Ripple Project
Melvin and anyone else interested.
Fee system now illustrated in fee_system_game_theory.pdf. Illustrations of how it enforces the signals used, "buyer cancels", "seller finalizes", and "seal payment".
"Buyer cancels" and "seller finalizes" both act on edge nodes (the previous hop simply leaves the payment), and the game theory is very simple and straightforward there.
When the fee system acts on an intermediary in "seal payment" it gets a bit convoluted. Fees have to be balanced so they are higher on the seller side than the buyer side. This is relatively straight forward, but also always incurs some penalty on the buyer (although it can be balanced to be much smaller than the one for the intermediary who does the "stop-propagation" attack).
The "asymmetric fee" in "seal payment" is now also added to the codebase on ripple.archi/code.
I also apologize publicly for assuming that account-level consensus was why Ryan Fugger got stuck. If my fee system works it requires many steps and I was only able to come up with half of it, and then had to add the other half, the "seller finalize" idea Ryan Fugger had. Co-incidentally they fit perfectly together and the fees fixed the issue Ryan's idea had: the penalty was the full payment. Account-level consensus is needed though but Ryan Fugger mentioned this as early as 2006 here on Sourceforge mailing list so it was never ignored and it was not "the missing puzzle piece".
Peace, Johan
Fee system now illustrated in fee_system_game_theory.pdf. Illustrations of how it enforces the signals used, "buyer cancels", "seller finalizes", and "seal payment".
"Buyer cancels" and "seller finalizes" both act on edge nodes (the previous hop simply leaves the payment), and the game theory is very simple and straightforward there.
When the fee system acts on an intermediary in "seal payment" it gets a bit convoluted. Fees have to be balanced so they are higher on the seller side than the buyer side. This is relatively straight forward, but also always incurs some penalty on the buyer (although it can be balanced to be much smaller than the one for the intermediary who does the "stop-propagation" attack).
The "asymmetric fee" in "seal payment" is now also added to the codebase on ripple.archi/code.
I also apologize publicly for assuming that account-level consensus was why Ryan Fugger got stuck. If my fee system works it requires many steps and I was only able to come up with half of it, and then had to add the other half, the "seller finalize" idea Ryan Fugger had. Co-incidentally they fit perfectly together and the fees fixed the issue Ryan's idea had: the penalty was the full payment. Account-level consensus is needed though but Ryan Fugger mentioned this as early as 2006 here on Sourceforge mailing list so it was never ignored and it was not "the missing puzzle piece".
Peace, Johan
Johan Nygren
Apr 6, 2025, 6:32:19 AMApr 6
to Ripple Project
Also may interest some:
The fee system solution I have suggested works well to enforce signals that propagate at "edge nodes", such as "seller finalizes" (that Ryan suggested originally 15 years ago, but with fee system the race condition is removed from it) and also "buyer cancels" (used to set up the fee system so it can act on "seller finalizes"). It does not fit in a straightforward way for the step between those. It can be made to work (as described in pdf in previous mail) but it is not straightforward.
An alternative for the in-between step, is similar to Ryan's idea of a "commit register", except the global transaction is only used in case of a problem. Thus it is instead a "failsafe register". In Ryan's as I understand, there was one global transaction per Ripple payment. This makes Ripple very meaningless. But a "failsafe register" that only needs a global transaction in case something went wrong, is another thing.
In Ryan's design, the "commit register" was needed every payment since it compensated for the "race condition" at "seller finalizes" (where full payment was the penalty...). In my design, the "failsafe register" would compensate for a signal that informs people that the buyer has revoked the right to cancel (the "seal payment" signal I have called it). It thus defends against an attack where buyer and seller would issue both "buyer cancels" and "seller finalizes" at the same time.
If normal "seal payment" propagation fails (because of a "stop-propagation" attack by an intermediary), the buyer instead revokes their right to cancel with a global transaction. Once "seal" has been published on the "failsafe register", assuming the mechanism is designed well, everyone could be certain that the buyer will not issue "buyer cancels".
What mechanisms does the "seal failsafe register" need to work? Probably some kind of deposit, that is burnt in case the buyer also issues "buyer cancels". The deposit should be sized proportionally to the payment size. Timeout mechanisms for deposit and such, have to be considered. Ability to do multiple attacks with similar identifiers and thus only have to spend one deposit to do the attack, could be considered.
With this type of mechanism, it becomes more like what David Watson emphasized, "Ripple is just like lightning network", i.e., if a global failsafe is required then Ripple is to some extent "just like lightning network" although as anyone hopefully sees this global failsafe would be used very rarely.
I prefer a truly distributed design, but I think the "asymmetric fees" for "seal payment" that I came up with feel very convoluted (they might still work, but they are not straightforward) so I wanted to mention this alternative, and show that my game theory of the fee system and how it removes Ryan's race condition from "seller finalizes" might have value even in such a design.
Hopefully someone finds this interesting. I am overall very interested in meeting half way about how to get Ripple Inter Server Protocol up and running. I am not against failsafe at global consensus level, but the solution cannot be to use a global payment for every Ripple payment as seems to have been the design in Ryan's 15 year old "commit registers".
This pdf summarizes these ideas a bit, payment_game_theory.pdf, with the same illustrations as in the previously shared one.
Peace, Johan
The fee system solution I have suggested works well to enforce signals that propagate at "edge nodes", such as "seller finalizes" (that Ryan suggested originally 15 years ago, but with fee system the race condition is removed from it) and also "buyer cancels" (used to set up the fee system so it can act on "seller finalizes"). It does not fit in a straightforward way for the step between those. It can be made to work (as described in pdf in previous mail) but it is not straightforward.
An alternative for the in-between step, is similar to Ryan's idea of a "commit register", except the global transaction is only used in case of a problem. Thus it is instead a "failsafe register". In Ryan's as I understand, there was one global transaction per Ripple payment. This makes Ripple very meaningless. But a "failsafe register" that only needs a global transaction in case something went wrong, is another thing.
In Ryan's design, the "commit register" was needed every payment since it compensated for the "race condition" at "seller finalizes" (where full payment was the penalty...). In my design, the "failsafe register" would compensate for a signal that informs people that the buyer has revoked the right to cancel (the "seal payment" signal I have called it). It thus defends against an attack where buyer and seller would issue both "buyer cancels" and "seller finalizes" at the same time.
If normal "seal payment" propagation fails (because of a "stop-propagation" attack by an intermediary), the buyer instead revokes their right to cancel with a global transaction. Once "seal" has been published on the "failsafe register", assuming the mechanism is designed well, everyone could be certain that the buyer will not issue "buyer cancels".
What mechanisms does the "seal failsafe register" need to work? Probably some kind of deposit, that is burnt in case the buyer also issues "buyer cancels". The deposit should be sized proportionally to the payment size. Timeout mechanisms for deposit and such, have to be considered. Ability to do multiple attacks with similar identifiers and thus only have to spend one deposit to do the attack, could be considered.
With this type of mechanism, it becomes more like what David Watson emphasized, "Ripple is just like lightning network", i.e., if a global failsafe is required then Ripple is to some extent "just like lightning network" although as anyone hopefully sees this global failsafe would be used very rarely.
I prefer a truly distributed design, but I think the "asymmetric fees" for "seal payment" that I came up with feel very convoluted (they might still work, but they are not straightforward) so I wanted to mention this alternative, and show that my game theory of the fee system and how it removes Ryan's race condition from "seller finalizes" might have value even in such a design.
Hopefully someone finds this interesting. I am overall very interested in meeting half way about how to get Ripple Inter Server Protocol up and running. I am not against failsafe at global consensus level, but the solution cannot be to use a global payment for every Ripple payment as seems to have been the design in Ryan's 15 year old "commit registers".
This pdf summarizes these ideas a bit, payment_game_theory.pdf, with the same illustrations as in the previously shared one.
Peace, Johan
Johan Nygren
Apr 6, 2025, 1:35:03 PMApr 6
to Ripple Project
Correction, the fee system likely works even when not propagating at "edge nodes" (thus when it has to be asymmetric at buyer and seller side of intermediary), but if any problem is found, I suggest "failsafe register" as alternative: fee_system_game_theory2.pdf. But only if the "asymmetric fee" part is found to have problems. The fee system is implemented in full on ripple.archi/code. Johan
Johan Nygren
Apr 17, 2025, 2:35:08 PMApr 17
to Ripple Project
Correction,
the "distributed fee collection" is easily attackable by "fake node attack", so fees have to be agreed on beforehand
this works analogous to interest rate ideas back in Sourceforge Ripple mail list or similar
the "continuous finalization" in "commit" state and "continuous cancellation" in "seal" state are still used though
thus, the fees deter "reserve credit attack" by buyer, the "continuous finalization" and "continuous cancellation" enforce "seal payment" propagation by intermediaries, and the "continuous cancellation" in "seal" state enforces "finalize" signal (same incentive as in Ryan Fugger's "seller finalizes" but with smaller race condition, and STREAM payments in Interledger seem to also use same incentive but with reduced race condition because the payment is in chunks but my solution is probably better)
the rate of continuous finalization/cancellation can also be agreed on beforehand (when setting up payment) rather than "global variable" set by each user
Johan
the "distributed fee collection" is easily attackable by "fake node attack", so fees have to be agreed on beforehand
this works analogous to interest rate ideas back in Sourceforge Ripple mail list or similar
the "continuous finalization" in "commit" state and "continuous cancellation" in "seal" state are still used though
thus, the fees deter "reserve credit attack" by buyer, the "continuous finalization" and "continuous cancellation" enforce "seal payment" propagation by intermediaries, and the "continuous cancellation" in "seal" state enforces "finalize" signal (same incentive as in Ryan Fugger's "seller finalizes" but with smaller race condition, and STREAM payments in Interledger seem to also use same incentive but with reduced race condition because the payment is in chunks but my solution is probably better)
the rate of continuous finalization/cancellation can also be agreed on beforehand (when setting up payment) rather than "global variable" set by each user
Johan
Johan Nygren
Apr 20, 2025, 3:50:12 AMApr 20
to Ripple Project
To explain more easily:
The idea to limit lock-credit-attacks or DoS or spam or such with that buyer has to pay fees for each hop has been part of Ripple mailing lists from the Sourceforge mailing list 15-20 years ago.
I use such a mechanism, as one component. I combine it with 2-3 other components so that every step of the payment coordination gets enforced.
For the "buyer fees" I add that they are paid out gradually. This is an innovation. Thus, they are only paid out in full in case of an attack (or network failure, i.e., they are paid out if the payment does not finish).
This mechanism to do something gradually does three things in my system. The buyer fees, and then two other things: in one "state" the payment is gradually finalized and in another it is gradually cancelled.
These other two "gradual things", continuous finalization and continuous cancellation, are building blocks that can be used to enforce nodes to propagate a signal - thus preventing "stuck payment" issues.
The "continuous cancellation" can be applied at the same step Ryan Fugger used in his design 15 years ago, where the payment is completed from the seller towards the buyer. In Ryan's design, the full payment was the penalty (an intermediary that failed to propagate prior to timeout was stuck with the full payment, "staggered timeouts" were used to try and avoid this happening). With "continuous cancellation" done by every node, the race is instead against tiny chunks of the payment.
The "continuous finalization" can be applied in the mechanism I used originally in my ripple.archi (before I shared my work here 2 months ago which led to that I decided to fully solve the "stuck payment" problem): that the buyer is made the last person with the right to cancel. As the payment starts to be finalized, the buyer has an incentive to cancel it unless every node agrees to it. And every node has an incentive to propagate this cancel signal, as they end up having to pay the payment that is gradually being finalized.
A combination of "continuous cancellation" and "continuous finalization" can be applied to force an intermediary to propagate a signal (in the other two cases, the signal was propagated by an "edge node" as the previous hop left the payment). Here you simply finalize gradually on the seller side and cancel gradually on the buyer side, thus leaving the intermediary with a penalty.
All of this is achieved with two "states", "commit" and "seal". In "seal" there is "gradual cancellation", thus Ryan Fugger's "seller finalizes" mechanism acts against a reduced race condition. In "commit" there is "gradual finalization", thus enforcing the propagation of "seal" as well as the propagation of "buyer cancels".
The "buyer fees" are always paid in proportion to how much of the payment was gradually cancelled/finalized. I.e., the same "ticker" for all of those things (seconds basically). 50% of payment was "cleaned up" (cancelled or finalized), 50% of the "buyer fees" were paid out.
Implementation of all this is extremely simple. No extra transactions are needed, people simply keep track of time (and computers do this naturally) and then account for the chunk cancelled/finalized when they issue the next decision ("seal", "finalize", etc). I already coded most of it here, https://ripple.archi/code, although it will take a few days to finish it (that code does for example not compile yet, it is in process of being finished).
The "buyer fees" are agreed on before the payment much like any such fees are conceived to be organized (I prefer my variant where nodes have a minimum fee they accept, the buyer suggests a fee, and everyone uses the same fee thus the shortest path is selected rather than selecting paths by fees, and this also avoids a "race to the bottom" for the fees, but any approach including traditional "select cheapest path" works, I just prefer to simplify the path finding). The "cleanup rate" (how fast the "ticker" is) is agreed on before payment as well (here too, people have an upper and lower limit of what they accept and the buyer says what their payment will use, and paths are found accordingly, extremely simple). Thus, there is an "up front agreement" as David Watson assumed and such agreement is very simple (I use the same selection system in "swarm redistribution", buyer says what they use, nodes have an upper and lower bound of what they accept to participate in). Previously my design instead used "global parameter" in that node set their parameters and were assumed to set similar to neighbors, this was mostly a first draft as it was good enough to work with at the moment, the "up front agreement" is much better, simpler.
To me this seems like a significant innovation. The design should also work for Interledger as far as I see, as it only accounts for things when a decision happens (no extra transactions). It solves what has been unsolved in Ripple for 15 years. Or, I am missing something fundamental and I am an idiot. But to me, it seems solid. Any major holes, would be very much appreciated if anyone points them out, or if it seems solid, would also be appreciated if anyone mentions that, so that multi-server Ripple can move forward and we can get the world the internet makes possible.
Peace Johan
The idea to limit lock-credit-attacks or DoS or spam or such with that buyer has to pay fees for each hop has been part of Ripple mailing lists from the Sourceforge mailing list 15-20 years ago.
I use such a mechanism, as one component. I combine it with 2-3 other components so that every step of the payment coordination gets enforced.
For the "buyer fees" I add that they are paid out gradually. This is an innovation. Thus, they are only paid out in full in case of an attack (or network failure, i.e., they are paid out if the payment does not finish).
This mechanism to do something gradually does three things in my system. The buyer fees, and then two other things: in one "state" the payment is gradually finalized and in another it is gradually cancelled.
These other two "gradual things", continuous finalization and continuous cancellation, are building blocks that can be used to enforce nodes to propagate a signal - thus preventing "stuck payment" issues.
The "continuous cancellation" can be applied at the same step Ryan Fugger used in his design 15 years ago, where the payment is completed from the seller towards the buyer. In Ryan's design, the full payment was the penalty (an intermediary that failed to propagate prior to timeout was stuck with the full payment, "staggered timeouts" were used to try and avoid this happening). With "continuous cancellation" done by every node, the race is instead against tiny chunks of the payment.
The "continuous finalization" can be applied in the mechanism I used originally in my ripple.archi (before I shared my work here 2 months ago which led to that I decided to fully solve the "stuck payment" problem): that the buyer is made the last person with the right to cancel. As the payment starts to be finalized, the buyer has an incentive to cancel it unless every node agrees to it. And every node has an incentive to propagate this cancel signal, as they end up having to pay the payment that is gradually being finalized.
A combination of "continuous cancellation" and "continuous finalization" can be applied to force an intermediary to propagate a signal (in the other two cases, the signal was propagated by an "edge node" as the previous hop left the payment). Here you simply finalize gradually on the seller side and cancel gradually on the buyer side, thus leaving the intermediary with a penalty.
All of this is achieved with two "states", "commit" and "seal". In "seal" there is "gradual cancellation", thus Ryan Fugger's "seller finalizes" mechanism acts against a reduced race condition. In "commit" there is "gradual finalization", thus enforcing the propagation of "seal" as well as the propagation of "buyer cancels".
The "buyer fees" are always paid in proportion to how much of the payment was gradually cancelled/finalized. I.e., the same "ticker" for all of those things (seconds basically). 50% of payment was "cleaned up" (cancelled or finalized), 50% of the "buyer fees" were paid out.
Implementation of all this is extremely simple. No extra transactions are needed, people simply keep track of time (and computers do this naturally) and then account for the chunk cancelled/finalized when they issue the next decision ("seal", "finalize", etc). I already coded most of it here, https://ripple.archi/code, although it will take a few days to finish it (that code does for example not compile yet, it is in process of being finished).
The "buyer fees" are agreed on before the payment much like any such fees are conceived to be organized (I prefer my variant where nodes have a minimum fee they accept, the buyer suggests a fee, and everyone uses the same fee thus the shortest path is selected rather than selecting paths by fees, and this also avoids a "race to the bottom" for the fees, but any approach including traditional "select cheapest path" works, I just prefer to simplify the path finding). The "cleanup rate" (how fast the "ticker" is) is agreed on before payment as well (here too, people have an upper and lower limit of what they accept and the buyer says what their payment will use, and paths are found accordingly, extremely simple). Thus, there is an "up front agreement" as David Watson assumed and such agreement is very simple (I use the same selection system in "swarm redistribution", buyer says what they use, nodes have an upper and lower bound of what they accept to participate in). Previously my design instead used "global parameter" in that node set their parameters and were assumed to set similar to neighbors, this was mostly a first draft as it was good enough to work with at the moment, the "up front agreement" is much better, simpler.
To me this seems like a significant innovation. The design should also work for Interledger as far as I see, as it only accounts for things when a decision happens (no extra transactions). It solves what has been unsolved in Ripple for 15 years. Or, I am missing something fundamental and I am an idiot. But to me, it seems solid. Any major holes, would be very much appreciated if anyone points them out, or if it seems solid, would also be appreciated if anyone mentions that, so that multi-server Ripple can move forward and we can get the world the internet makes possible.
Peace Johan
Reply all
Reply to author
Forward
0 new messages