A blueprint for Ripple with account-level consensus and payment-chain level consensus
24 views
Skip to first unread message
Johan Nygren
Mar 13, 2025, 3:47:07 AMMar 13
to Ripple Project
With account-level consensus (like what Ryan Fugger suggested be used in 2006) you get half of the payment process. It allows a commit (permanent commit, no timeout) signal to propagate through the payment chain and either have 100% agreement (reach end point) or not (fail to reach end point).
This component provides 100% consensus for the payment chain (and, perfect consensus per account as well...) It is trivial to implement, I already did in my account-level-only consensus version https://ripple.archi.
Then, to avoid the "reserve credit attack" or similar things, a payment-chain-wide consensus is needed. For this, Paxos can be used. It agrees with majority consensus - not 100%. It is used only to make a single binary decision: finalize, or cancel. Anyone can submit cancel (thus there is no timeout on the commit, it is permanent, but can be manually cancelled), only the end point can submit finalize.
Johan
This component provides 100% consensus for the payment chain (and, perfect consensus per account as well...) It is trivial to implement, I already did in my account-level-only consensus version https://ripple.archi.
Then, to avoid the "reserve credit attack" or similar things, a payment-chain-wide consensus is needed. For this, Paxos can be used. It agrees with majority consensus - not 100%. It is used only to make a single binary decision: finalize, or cancel. Anyone can submit cancel (thus there is no timeout on the commit, it is permanent, but can be manually cancelled), only the end point can submit finalize.
Johan
Johan Nygren
Mar 14, 2025, 3:38:10 AMMar 14
to Ripple Project
OK majority vote does not work, attacker can pretend to be any number of nodes.
This is probably why this community never used it, and decided to use "distributed race condition". And as such solution was not secure, it then decided to use "global commit mechanism" (global as in the whole world, similar to Bitcoin/Ethereum, and not global as in payment-chain-wide as I assumed above). With that type of global majority vote, fake nodes is resolvable. But with global trust already there, there is no need for local trust-lines. So that approach has to be wrong or Ripple is somewhat meaningless. Not entirely meaningless - the trustlines still allow for swarm redistribution, but on a global coin you can also do redistribution with just equivalent of demurrage and it would probably be easier. So, this community's approach has to be wrong. No?
The critique against person-to-person-only exchanges is mostly the "reserve credit attack". But this is not a very good attack. The attacker is not in a good position to attack. And as that, there are quite easy ways to deal with it. I mentioned this in my thread on my https://ripple.archi system, but given the feedback (ignored by 3 responses, acknowledged by 1 and thank you for that, and Ryan also saying in email it was not a good system) I had to assume that maybe this community, having had almost 20 years to think about it, was ahead of me. But, what I said seems right. Since the attacker is actually the one who has also put something at stake (the buyer), you can simply use penalty fee to disincentivize the attack. I.e., X amount of IOU is finalized every Y units of time. If the attacker waits long enough, their entire "reserved credit attack" just transforms into... well, giving away money... and up until everything has been finalized, cancelling will impose the fee of everything "finalized" up until that point. The base line is: the attacker is not in a good position to try and coerce the network. And such fees were part of the Ripple Inter Server Protocol discussion so I am not sure why the attack was seen as severe enough that the "distributed race condition" idea had to be pursued - which ultimately ended in global consensus... ripple.com...
This is me writing here despite no responses (am I then spamming?) but ultimately, it has been my attempting to respect this community and taking a position where I would not assume myself to be right automatically. Trying to meet half way. Even apologizing as I assumed I might have made a bit too far reaching claims. And I am now back to where I was before those attempts at conversation, except with possibly adding penalty fees to my architecture (but, since "reserve credit attack" is not a good attack position, I had considered similar things, just not seen it as the priority right now. That someone had built a working Ripple Inter Server Protocol that could already be used seemed more like a priority to communicate... an attack vector that could be resolved by a simple protocol addition is also deterred to start with, even if that code was not even in the codebase... as long as it is compatible with existing codebase...)
Thank you Ryan for inventing Ripple, incredible work, it has incredible potential, and if I am wrong on my analysis here I would be happy to realize it. If I am not wrong, then maybe this community could start to acknowledge that "global commit mechanism" cannot be the solution as it makes Ripple money system redundant, thus solution has to be something else. Or am I wrong? And I am saying I already built a working version: https://ripple.archi.
Johan
This is probably why this community never used it, and decided to use "distributed race condition". And as such solution was not secure, it then decided to use "global commit mechanism" (global as in the whole world, similar to Bitcoin/Ethereum, and not global as in payment-chain-wide as I assumed above). With that type of global majority vote, fake nodes is resolvable. But with global trust already there, there is no need for local trust-lines. So that approach has to be wrong or Ripple is somewhat meaningless. Not entirely meaningless - the trustlines still allow for swarm redistribution, but on a global coin you can also do redistribution with just equivalent of demurrage and it would probably be easier. So, this community's approach has to be wrong. No?
The critique against person-to-person-only exchanges is mostly the "reserve credit attack". But this is not a very good attack. The attacker is not in a good position to attack. And as that, there are quite easy ways to deal with it. I mentioned this in my thread on my https://ripple.archi system, but given the feedback (ignored by 3 responses, acknowledged by 1 and thank you for that, and Ryan also saying in email it was not a good system) I had to assume that maybe this community, having had almost 20 years to think about it, was ahead of me. But, what I said seems right. Since the attacker is actually the one who has also put something at stake (the buyer), you can simply use penalty fee to disincentivize the attack. I.e., X amount of IOU is finalized every Y units of time. If the attacker waits long enough, their entire "reserved credit attack" just transforms into... well, giving away money... and up until everything has been finalized, cancelling will impose the fee of everything "finalized" up until that point. The base line is: the attacker is not in a good position to try and coerce the network. And such fees were part of the Ripple Inter Server Protocol discussion so I am not sure why the attack was seen as severe enough that the "distributed race condition" idea had to be pursued - which ultimately ended in global consensus... ripple.com...
This is me writing here despite no responses (am I then spamming?) but ultimately, it has been my attempting to respect this community and taking a position where I would not assume myself to be right automatically. Trying to meet half way. Even apologizing as I assumed I might have made a bit too far reaching claims. And I am now back to where I was before those attempts at conversation, except with possibly adding penalty fees to my architecture (but, since "reserve credit attack" is not a good attack position, I had considered similar things, just not seen it as the priority right now. That someone had built a working Ripple Inter Server Protocol that could already be used seemed more like a priority to communicate... an attack vector that could be resolved by a simple protocol addition is also deterred to start with, even if that code was not even in the codebase... as long as it is compatible with existing codebase...)
Thank you Ryan for inventing Ripple, incredible work, it has incredible potential, and if I am wrong on my analysis here I would be happy to realize it. If I am not wrong, then maybe this community could start to acknowledge that "global commit mechanism" cannot be the solution as it makes Ripple money system redundant, thus solution has to be something else. Or am I wrong? And I am saying I already built a working version: https://ripple.archi.
Johan
Johan Nygren
Mar 14, 2025, 9:14:37 AMMar 14
to Ripple Project
The fees described above only work if buyer is attacker alone, not if both buyer and seller attack.
If both attack, simplest seems to be: each account involved after a certain amount of time start to trigger "reserve credit fees", a tiny fragment of the IOU. I.e., they say "I now finalize X amount of IOU and I keep it for myself". The previous hop (their account with previous hop) has to enter this into their account bookkeeping. Likewise, they have to propagate this to the previous hop - or be left accountable for the X amount themselves if the previous hops cancel before that. And, their next hop, has to enter that X less IOU is being propagated, or be accountable for the full output payment themselves.
This is very simple. It is very loosely defined. It is only needed to the extent "reserve credit attack" is a problem. The trigger time can probably be automatically decided based on how much credit has been locked for how long. I would assume there is not much reward from such attack and thus that they are not that big a problem, and accounts just "nibbling" tiny tiny fractions, and very rarely, would be enough. Like, more at the day/month/year timescale, than seconds or minutes... But I might miss severity of it.
I write here assuming that no one here has a complete idea for a good Ripple Inter Server Protocol, and that there is room for one. If a complete idea already exists, someone could maybe point me to it. I assume majority vote at payment-chain level is a rejected possibility by the community here, and I also suggest global commit at every payment makes Ripple money system redundant, only if the global "fallback" was required only when a payment failed (or at least not 100% of all payments) would it make sense to me.
To add this "nibbling" to https://ripple.archi is probably pretty easy. And, again, it is only needed to the extent the "reserve credit attack" is actually a problem.
Johan
If both attack, simplest seems to be: each account involved after a certain amount of time start to trigger "reserve credit fees", a tiny fragment of the IOU. I.e., they say "I now finalize X amount of IOU and I keep it for myself". The previous hop (their account with previous hop) has to enter this into their account bookkeeping. Likewise, they have to propagate this to the previous hop - or be left accountable for the X amount themselves if the previous hops cancel before that. And, their next hop, has to enter that X less IOU is being propagated, or be accountable for the full output payment themselves.
This is very simple. It is very loosely defined. It is only needed to the extent "reserve credit attack" is a problem. The trigger time can probably be automatically decided based on how much credit has been locked for how long. I would assume there is not much reward from such attack and thus that they are not that big a problem, and accounts just "nibbling" tiny tiny fractions, and very rarely, would be enough. Like, more at the day/month/year timescale, than seconds or minutes... But I might miss severity of it.
I write here assuming that no one here has a complete idea for a good Ripple Inter Server Protocol, and that there is room for one. If a complete idea already exists, someone could maybe point me to it. I assume majority vote at payment-chain level is a rejected possibility by the community here, and I also suggest global commit at every payment makes Ripple money system redundant, only if the global "fallback" was required only when a payment failed (or at least not 100% of all payments) would it make sense to me.
To add this "nibbling" to https://ripple.archi is probably pretty easy. And, again, it is only needed to the extent the "reserve credit attack" is actually a problem.
Johan
Reply all
Reply to author
Forward
0 new messages