Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
Multi-server Ripple with account-consensus only now built
37 views
Skip to first unread message
Johan Nygren
Mar 12, 2025, 5:41:42 AMMar 12
to Network Money
Hi everyone. Thanks Michiel for the invite 3 years ago in response to my initial ideas for what I have now built.
I have designed and built a multi-server Ripple: https://ripple.archi. It has account-consensus only. Ideally, Ripple would do payment-routing-level consensus. As my version is not ideal, it has theoretical vulnerabilities such as the "reserve credit attack" that may or may not be manageable socially. My platform is as far as I know the first multi-server Ripple to be built.
Implementations of Ripple:
My version is extremely simple. It is 4000 lines of code, with almost no dependencies. Any computer engineer could recreate it from scratch easily (sha256 maybe only hard part to recreate from scratch). It uses symmetric cryptography only (impossible to do on payment routing consensus architecture). It uses an extremely simple and perfectly secure two-person consensus mechanism. It uses UDP+Retransmission that is efficient. I think it is very interesting and a step-up from previous Ripple versions (single-server or global consensus) in that it is actually multi-server. I am sharing my work here in case there is anyone else who thinks like I do (in the Ripple group people seem to disregard the account-consensus approach as meaningless and only focus on the payment routing consensus version, and maybe they are right, but, it does not exist, and I am not sure my version is more vulnerable to attacks than RipplePay so to me that seems like an improvement). I am also interested in a more ideal version and in contributing to it, but I started with the simplest one and whether or not it is meaningless or not is up to anyone to judge for themselves.
Also, I should mention here that I am to some extent a Ripple money system maximalist, since I invented swarm redistribution in 2012 (2019 whitepaper) and it cannot be built on any other money system than Ripple. You need each person to be a bank otherwise the "tax" cannot propagate (it jumps via IOU lines until it reaches a person who currently has no incoming IOU... i.e., "no income", they thus receive "guaranteed basic income"). I also like global consensus systems like Ethereum/Bitcoin/the nation-state, but Ripple has a special place in my heart partly since my invention from 2012 requires it and also since I think it is ingenious in itself, generalizing everyone to be a bank, beautiful in its simplicity. Good engineering.
Johan
I have designed and built a multi-server Ripple: https://ripple.archi. It has account-consensus only. Ideally, Ripple would do payment-routing-level consensus. As my version is not ideal, it has theoretical vulnerabilities such as the "reserve credit attack" that may or may not be manageable socially. My platform is as far as I know the first multi-server Ripple to be built.
Implementations of Ripple:
Single-server (RipplyPay)
Global consensus (Ripple.com)
Account-consensus (My version)
Account-consensus (My version)
Payment-routing-consensus (Ryan Fugger's envisioned Ripple Inter Server Protocol)
My version is extremely simple. It is 4000 lines of code, with almost no dependencies. Any computer engineer could recreate it from scratch easily (sha256 maybe only hard part to recreate from scratch). It uses symmetric cryptography only (impossible to do on payment routing consensus architecture). It uses an extremely simple and perfectly secure two-person consensus mechanism. It uses UDP+Retransmission that is efficient. I think it is very interesting and a step-up from previous Ripple versions (single-server or global consensus) in that it is actually multi-server. I am sharing my work here in case there is anyone else who thinks like I do (in the Ripple group people seem to disregard the account-consensus approach as meaningless and only focus on the payment routing consensus version, and maybe they are right, but, it does not exist, and I am not sure my version is more vulnerable to attacks than RipplePay so to me that seems like an improvement). I am also interested in a more ideal version and in contributing to it, but I started with the simplest one and whether or not it is meaningless or not is up to anyone to judge for themselves.
Also, I should mention here that I am to some extent a Ripple money system maximalist, since I invented swarm redistribution in 2012 (2019 whitepaper) and it cannot be built on any other money system than Ripple. You need each person to be a bank otherwise the "tax" cannot propagate (it jumps via IOU lines until it reaches a person who currently has no incoming IOU... i.e., "no income", they thus receive "guaranteed basic income"). I also like global consensus systems like Ethereum/Bitcoin/the nation-state, but Ripple has a special place in my heart partly since my invention from 2012 requires it and also since I think it is ingenious in itself, generalizing everyone to be a bank, beautiful in its simplicity. Good engineering.
Johan
Johan Nygren
Mar 16, 2025, 6:41:47 AMMar 16
to Network Money
Update: wrong statement from me above.
Having built Ripple.archi over a year, with what I saw as a good design, I was told by most "Ripple-interested people" that person-to-person-level consensus could not work.
Out of respect, I had to assume they claimed that an intermediary level of consensus was needed, i.e., payment-chain level. So, despite having a complete platform built, I tried to consider what they must mean. But, the thing with consensus is fake nodes breaks it. This is what Satoshi (Craig) solved with proof-of-work, and what the nation-state solves with people-vote (and some also solve with coin-vote). And, Ripple solves with person-to-person trust. To try and do an intermediary level of consensus in Ripple is hard (and maybe illogical and not even possible?), so apparently what the "Ripple community" seemed to claim is needed is global consensus. But with one global transaction per Ripple payment, Ripple is meaningless.
I instead suggest Ripple can work with person-to-person-level-consensus. The critique has been "reserve credit attack breaks it" but this attack is easily solved with fees. Mechanisms I had already considered for technical (or attack) issues of stuck reserve credit the whole time I worked on designing and building my platform. But those mechanisms being easy to design and build seemed to not be enough of an argument, so I now added them to my codebase. Even though they really are not what ought to be the first priority since they are easy to do, but that attack vector seems to have caused progress towards multi-Ripple to cease 10+ years ago and so that might make it a priority... just to demonstrate that "hey this problem may have been exaggerated all those years?".
For summary of the "reserve credit attack" and how to easily prevent it with account-consensus only, see https://ripple.archi/attackvector.pdf (a mechanism already in my codebase on https://ripple.archi).
Anyone interested feel free to correspond. Blatant false claims from me, feel free to call out and shut them down. I am interested in seeing multi-server Ripple take over the world, I do not need to be the one to create it, but apparently no one else has and time kept ticking so I went and built it myself.
Peace, Johan
Having built Ripple.archi over a year, with what I saw as a good design, I was told by most "Ripple-interested people" that person-to-person-level consensus could not work.
Out of respect, I had to assume they claimed that an intermediary level of consensus was needed, i.e., payment-chain level. So, despite having a complete platform built, I tried to consider what they must mean. But, the thing with consensus is fake nodes breaks it. This is what Satoshi (Craig) solved with proof-of-work, and what the nation-state solves with people-vote (and some also solve with coin-vote). And, Ripple solves with person-to-person trust. To try and do an intermediary level of consensus in Ripple is hard (and maybe illogical and not even possible?), so apparently what the "Ripple community" seemed to claim is needed is global consensus. But with one global transaction per Ripple payment, Ripple is meaningless.
I instead suggest Ripple can work with person-to-person-level-consensus. The critique has been "reserve credit attack breaks it" but this attack is easily solved with fees. Mechanisms I had already considered for technical (or attack) issues of stuck reserve credit the whole time I worked on designing and building my platform. But those mechanisms being easy to design and build seemed to not be enough of an argument, so I now added them to my codebase. Even though they really are not what ought to be the first priority since they are easy to do, but that attack vector seems to have caused progress towards multi-Ripple to cease 10+ years ago and so that might make it a priority... just to demonstrate that "hey this problem may have been exaggerated all those years?".
For summary of the "reserve credit attack" and how to easily prevent it with account-consensus only, see https://ripple.archi/attackvector.pdf (a mechanism already in my codebase on https://ripple.archi).
Anyone interested feel free to correspond. Blatant false claims from me, feel free to call out and shut them down. I am interested in seeing multi-server Ripple take over the world, I do not need to be the one to create it, but apparently no one else has and time kept ticking so I went and built it myself.
Peace, Johan
Johan Nygren
Mar 25, 2025, 2:16:31 PMMar 25
to Network Money
Update: Wrong claim from me above, but, it was half of the solution.
The fee system can be attacked. But, if you combine it with Ryan Fugger's original "seller finalizes" idea, and use it to remove the race condition from Ryan's idea, it works.
So co-incidentally, if you combine what I came up with and what Ryan decided 15 years ago was best, it seems like you have a complete system.
This has been implemented in my codebase, https://bitbucket.org/bipedaljoe/ripple/commits/b8004ca78399a0b21228529e055e45ef23d6e516
It uses a single fee system, that behaves differently for the two states it can operate in, "commit" or "seal" state.
It provides a penalty that behaves differently for these two states.
In "commit" state the penalty is on the buyer (and seller, as both might be the attacker) and it forces the buyer to either cancel or "seal" the payment.
In "seal" state, the penalty is on the intermediary to propagate "seal" and also to later propagate "finalize".
Ryan's idea had a race condition where not propagating "finalize" meant you had to pay the full payment. My version reduces this penalty to just fractions of the payment.
I actually think this is pretty interesting. If anyone also thinks it is interesting feel free to correspond, here, email, or Telegram maybe in Michiel' s group.
Peace, Johan
The fee system can be attacked. But, if you combine it with Ryan Fugger's original "seller finalizes" idea, and use it to remove the race condition from Ryan's idea, it works.
So co-incidentally, if you combine what I came up with and what Ryan decided 15 years ago was best, it seems like you have a complete system.
This has been implemented in my codebase, https://bitbucket.org/bipedaljoe/ripple/commits/b8004ca78399a0b21228529e055e45ef23d6e516
It uses a single fee system, that behaves differently for the two states it can operate in, "commit" or "seal" state.
It provides a penalty that behaves differently for these two states.
In "commit" state the penalty is on the buyer (and seller, as both might be the attacker) and it forces the buyer to either cancel or "seal" the payment.
In "seal" state, the penalty is on the intermediary to propagate "seal" and also to later propagate "finalize".
Ryan's idea had a race condition where not propagating "finalize" meant you had to pay the full payment. My version reduces this penalty to just fractions of the payment.
I actually think this is pretty interesting. If anyone also thinks it is interesting feel free to correspond, here, email, or Telegram maybe in Michiel' s group.
Peace, Johan
Michiel de Jong
Mar 26, 2025, 4:25:43 AMMar 26
to Johan Nygren, Network Money
Thanks for posting this here, Johan!
Cheers,
Michiel
--
You received this message because you are subscribed to the Google Groups "Network Money" group.
To unsubscribe from this group and stop receiving emails from it, send an email to network-mone...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/network-money/b7c26fca-b97f-488c-b3c5-e84303813021n%40googlegroups.com.
Johan Nygren
Mar 26, 2025, 5:19:52 AMMar 26
to Network Money
Thanks. One more rule changed. In "seal" phase people now collect fees just like in "commit" phase (do not just cancel chunks).
So this simplifies things. One rule, instead of one for either of two states...
Why the change? Attacker could be buyer and an intermediary, they could succeed with payment but lock credit for any intermediary between them. With fees also in seal, any intermediary who has reserved credit will always get paid if attack is attempted.
To highlight that: the fees ensure an intermediary who is affected by "reserve credit attack" always get paid. Simple idea. The victims of the attack simply resolve it themselves by becoming winners (being paid). Any intermediary affected by reserve credit attack is guaranteed to be paid as they are themselves the one collecting the fees.
Johan
So this simplifies things. One rule, instead of one for either of two states...
Why the change? Attacker could be buyer and an intermediary, they could succeed with payment but lock credit for any intermediary between them. With fees also in seal, any intermediary who has reserved credit will always get paid if attack is attempted.
To highlight that: the fees ensure an intermediary who is affected by "reserve credit attack" always get paid. Simple idea. The victims of the attack simply resolve it themselves by becoming winners (being paid). Any intermediary affected by reserve credit attack is guaranteed to be paid as they are themselves the one collecting the fees.
Johan
Johan Nygren
Apr 6, 2025, 1:52:31 PMApr 6
to Network Money
Update: Fee system now described with "asymmetric fee" at "seal payment" step, see https://ripple.archi/fee_system_game_theory2.pdf, and implemented in full on https://ripple.archi/code.
Fee system is good fit when propagation is by "edge node" and this is two of the three signals in my design. The third signal propagation is by intermediary. There fees have to be balanced so they are higher on the seller side of the intermediary than the buyer side (so that the intermediary becomes the one paying the fees).
If by any chance a problem is found with my asymmetric fee design I also suggest an alternative solution: a global "failsafe register" where buyer could publish seal payment (in case of a "stop-propagation" attack by an intermediary) and thereby prove they will not issue "buyer cancels" (the purpose of "seal payment" is to avoid buyer and seller doing "buyer cancels" and "seller finalizes" at the same time...) Note this is only in case my asymmetric fee idea turns out to have some problems. I think the fees will work.
Johan
Fee system is good fit when propagation is by "edge node" and this is two of the three signals in my design. The third signal propagation is by intermediary. There fees have to be balanced so they are higher on the seller side of the intermediary than the buyer side (so that the intermediary becomes the one paying the fees).
If by any chance a problem is found with my asymmetric fee design I also suggest an alternative solution: a global "failsafe register" where buyer could publish seal payment (in case of a "stop-propagation" attack by an intermediary) and thereby prove they will not issue "buyer cancels" (the purpose of "seal payment" is to avoid buyer and seller doing "buyer cancels" and "seller finalizes" at the same time...) Note this is only in case my asymmetric fee idea turns out to have some problems. I think the fees will work.
Johan
Johan Nygren
Apr 18, 2025, 7:47:20 AMApr 18
to Network Money
Correction:
The "buyer fees" have to be agreed on beforehand - the "decentralized fee collection" I suggested earlier is easily attackable by "fake nodes" attack. This actually makes the whole game theory simpler, so it is not a bad thing (I just had an aversion to agreeing on fees beforehand as it makes path finding more complex, but most people accept such a thing already anyway).
Now with the "buyer fees" (what deters the buyer from "reserve credit attack"), the "intermediary penalties" are same as before but without the auto-collected fees thing. Thus, during "seal", just a "continuous finalization" at the seller side (where nodes are in "commit" state) and a "continuous cancellation" at the buyer side (where nodes are in "seal" state). Likewise during "finalize" it is just "continuous cancellation". And during "commit", it is mostly the "buyer fees". The buyer fees are continuously finalized regardless of state (think of a ticker that goes from 0% to 100% and anyone in "seal" state will gradually cancel payment during that ticker, anyone in "commit" will gradually finalize, and everyone will also gradually finalize the "buyer fees" such that at 100% they will have received 100% of the "buyer fees"). If the payment finishes before timing out, no "buyer fees" are paid out.
To me it seems this works. It also seems this is a significant innovation. Anyone feel free to correspond. Peace Johan
The "buyer fees" have to be agreed on beforehand - the "decentralized fee collection" I suggested earlier is easily attackable by "fake nodes" attack. This actually makes the whole game theory simpler, so it is not a bad thing (I just had an aversion to agreeing on fees beforehand as it makes path finding more complex, but most people accept such a thing already anyway).
Now with the "buyer fees" (what deters the buyer from "reserve credit attack"), the "intermediary penalties" are same as before but without the auto-collected fees thing. Thus, during "seal", just a "continuous finalization" at the seller side (where nodes are in "commit" state) and a "continuous cancellation" at the buyer side (where nodes are in "seal" state). Likewise during "finalize" it is just "continuous cancellation". And during "commit", it is mostly the "buyer fees". The buyer fees are continuously finalized regardless of state (think of a ticker that goes from 0% to 100% and anyone in "seal" state will gradually cancel payment during that ticker, anyone in "commit" will gradually finalize, and everyone will also gradually finalize the "buyer fees" such that at 100% they will have received 100% of the "buyer fees"). If the payment finishes before timing out, no "buyer fees" are paid out.
To me it seems this works. It also seems this is a significant innovation. Anyone feel free to correspond. Peace Johan
Reply all
Reply to author
Forward
0 new messages