rethinking ripple data model

[Melvin Carvalho]

I have been trying to model ripple, trust lines, IOUs and ledgers for approaching 2 decades

I have built at least half a dozen implementations, and eventually iterated onto a new one

One problem I always had was thinking about IOUs, trust lines, ledgers and balances.  They seem to be similar data structures but slightly different and hard to model.

I realized something that might simplify alot.

Distributed Ledgers generally operate on the principle that no balance can go below zero.

So I realized that a trust line is a balance that can go below zero.

So every user has a balance, and a minimum balance that could be negative, for a set of trusted users.

Then the negative and positive balances can rebalance over time.

A system like nostr could be used to create a ledger of identities and then identify routing payments through various trust lines, and be compatible with other implementations

I might have a go at implementing this, which might be the solution to a decentralized version of ripple that brings it back to first principles.

[Johan Nygren]

Melvin, what about https://ripple.archi that I built over past year, is not a decentralized version of Ripple that brings it back to first principles?

It met "half way" with the main issues Ryan and this community seemed to see, the "stuck payment" attack ("the possible attack of locking intermediaries credit with fake transactions that never commit" as Jorge Timon put it in 2011 in the Sourceforge Ripple mailing list here) and advanced on the idea Ryan Fugger had developed by that time 15 years ago (enforce propagation with a penalty), and solved the issue of the full payment as penalty (Ryan's idea 15 years ago) in a similar way to what Interledger did with STREAM payments (shrink the size of the penalty during finishing of payment) but in the opposite way. I.e., there are two ways to shrink the size of penalty in Ryan's 15 year old mechanism. Either reduce size of payment and do the payment in "chunks" (as Interledger did) or reduce size of penalty by doing it in "chunks" (as my solution did).

This seems to be a direct continuity on the first principles of Ripple. The main thing lacking is people from this community saying something about it here. It is mostly silent treatment on the idea. But, it is probably the solution. And fully implemented. The innovation is: advance on the penalty idea Ryan Fugger used 15 years ago, and solve it in ideal way. And, probably, that I solve Two Generals' Problem. Ryan Fugger mentioned user-to-user consensus in 2006 (here in Sourceforge mailing list) but only to the point that "each state-changing decision must be agreed on", not how that would be achieved. I think the fact that Ripple fell back on "blockchain" around 2010 ("commit registers") after Craig Wright (Satoshi) had created Bitcoin in 2008 suggests that Ryan Fugger and this community had a limited understanding of consensus mechanism (if I am wrong, then my innovation would only be the advances on penalty mechanism), and from that, also failed to solve the "stuck payment attack" in the ideal way (I managed to solve it as I already had everything else implemented and could iterate very fast).

Peace, Johan

[Melvin Carvalho]

ne 11. 5. 2025 v 13:59 odesílatel Johan Nygren <joha...@gmail.com> napsal:

Melvin, what about https://ripple.archi that I built over past year, is not a decentralized version of Ripple that brings it back to first principles?

It met "half way" with the main issues Ryan and this community seemed to see, the "stuck payment" attack ("the possible attack of locking intermediaries credit with fake transactions that never commit" as Jorge Timon put it in 2011 in the Sourceforge Ripple mailing list here) and advanced on the idea Ryan Fugger had developed by that time 15 years ago (enforce propagation with a penalty), and solved the issue of the full payment as penalty (Ryan's idea 15 years ago) in a similar way to what Interledger did with STREAM payments (shrink the size of the penalty during finishing of payment) but in the opposite way. I.e., there are two ways to shrink the size of penalty in Ryan's 15 year old mechanism. Either reduce size of payment and do the payment in "chunks" (as Interledger did) or reduce size of penalty by doing it in "chunks" (as my solution did).

This seems to be a direct continuity on the first principles of Ripple. The main thing lacking is people from this community saying something about it here. It is mostly silent treatment on the idea. But, it is probably the solution. And fully implemented. The innovation is: advance on the penalty idea Ryan Fugger used 15 years ago, and solve it in ideal way. And, probably, that I solve Two Generals' Problem. Ryan Fugger mentioned user-to-user consensus in 2006 (here in Sourceforge mailing list) but only to the point that "each state-changing decision must be agreed on", not how that would be achieved. I think the fact that Ripple fell back on "blockchain" around 2010 ("commit registers") after Craig Wright (Satoshi) had created Bitcoin in 2008 suggests that Ryan Fugger and this community had a limited understanding of consensus mechanism (if I am wrong, then my innovation would only be the advances on penalty mechanism), and from that, also failed to solve the "stuck payment attack" in the ideal way (I managed to solve it as I already had everything else implemented and could iterate very fast).

I'm interested in one particular principle.

The range of a balance.

My mental model is that balance above zero is like coins that you own.

And IOUs and trust lines are like a negative version of that.

Does this make sense?  And does it align with ripple archi?

 

Peace, Johan

söndag 11 maj 2025 kl. 17:36:08 UTC+7 skrev Melvin Carvalho:

I have been trying to model ripple, trust lines, IOUs and ledgers for approaching 2 decades

I have built at least half a dozen implementations, and eventually iterated onto a new one

One problem I always had was thinking about IOUs, trust lines, ledgers and balances.  They seem to be similar data structures but slightly different and hard to model.

I realized something that might simplify alot.

Distributed Ledgers generally operate on the principle that no balance can go below zero.

So I realized that a trust line is a balance that can go below zero.

So every user has a balance, and a minimum balance that could be negative, for a set of trusted users.

Then the negative and positive balances can rebalance over time.

A system like nostr could be used to create a ledger of identities and then identify routing payments through various trust lines, and be compatible with other implementations

I might have a go at implementing this, which might be the solution to a decentralized version of ripple that brings it back to first principles.

--
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/addfdfc5-9d7d-494e-b142-89d184483df0n%40googlegroups.com.

[Johan Nygren]

Hi Melvin. I agree with you, in "mutual credit" balance can go negative up to the amount of a trustline (often called credit limit in mutual credit systems I think).

In coins, balance is only positive. The currency has to be "magically" created into circulation (in blockchain by paying the validators).

In traditional banking, a "loan" is similar to a trustline, it is not logically represented as a negative balance though to the user but it is the same thing I think. The "coins" get magically created into circulation by hiding the negative balance (initially, the user gets both a negative and a positive balance... as they get a loan but also the money...).

The two puzzle pieces for a truly decentralized Ripple are probably consensus mechanism to solve Two Generals Problem and penalty system to enforce command propagation. I solved both and implemented both. We could all work as a community from those two solutions. If people dislike symmetric cryptography solution, we could work as a community to build one with asymmetric cryptography. It is easy, I just prefer symmetric because only Ripple can do that (in a decentralized way, of course banks also use it but not same thing). Ripple is the only "decentralized money" that can use symmetric cryptography only. This is powerful, security-wise. Theoretically stronger.

Peace, Johan

[Melvin Carvalho]

ne 11. 5. 2025 v 14:59 odesílatel Johan Nygren <joha...@gmail.com> napsal:

Hi Melvin. I agree with you, in "mutual credit" balance can go negative up to the amount of a trustline (often called credit limit in mutual credit systems I think).

In coins, balance is only positive. The currency has to be "magically" created into circulation (in blockchain by paying the validators).

In traditional banking, a "loan" is similar to a trustline, it is not logically represented as a negative balance though to the user but it is the same thing I think. The "coins" get magically created into circulation by hiding the negative balance (initially, the user gets both a negative and a positive balance... as they get a loan but also the money...).

I have to think about this a bit more, but I thought when a bank creates a loan, it creates money out of thin air.  What one person sees as an asset, the bank sees as a liability.  Due to double-entry accounting.

RIght now I'd like to try and get a unified data model, before having yet another go at distributed ledgers.  If we can get the details down cleanly, I think that might simplify the implementations alot.

 

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/23cad8ec-a01c-4982-aa5c-d46853c0a2b9n%40googlegroups.com.

[Johan Nygren]

What exactly is it you want to unify?

For Nostr, in Ripple what do you need to relay?

Users know the address of the users they trust, user...@server.xyz. They just send transactions directly between each other.

Nostr is probably great for many things, Jon Stokes who helped me with Bitpeople.org likes it a lot. But there is nothing to relay in Ripple.

What was needed to build Ripple Inter Server Protocol was not hash locks or on-chain commits or "frameworks", it was 1) a user-to-user consensus mechanism to solve Two Generals Problem, and 2) a penalty system, the same type that Ryan Fugger pioneered but with reduced penalty size. There is two ways to achieve that, one is what Interledger came up with, the other is what I came up with (simulated on https://multihop.xyz/?view=sim).

I think, because people tend to be trained to fall back on "frameworks", that everyone has been overthinking how to build Ripple. What I did was I got rid of all the "frameworks". No "HTTP". Not even TCP, because why use that. Ryan Fugger was trying to optimize by keeping connections alive and such but these are all consequences of TCP. UDP + retransmission, there is none of that. No handshakes. Nothing. Also "set theory" for "database", I got rid of that too. The "database" in a single user Ripple server is almost nothing, why add "set operations" (although I would prefer using B-Tree or something but I dumbed it down entirely instead to simplify). And, instead of asymmetric cryptography, I just use SHA-256 message signatures. I also did a single-user implementation instead of multi-user. I did it mostly single-threaded. By getting rid of all the noise, I could focus on solving the unsolved fundamental problems. And I did. From there, sure someone can write an implementation with TCP instead. It is probably inoptimal but they can do so. They can add as much frameworks as they want to try and make things "simpler". They can make a multi-user implementation. But they still need to solve "stuck payment attack" and I was able to come up with the ideal solution because I did not prioritize "but framework X!". I got rid of all the "frameworks".

Peace, Johan

[Johan Nygren]

Hi Melvin I understand your point now maybe.

I agree with you a trustline is a balance that can go negative. As in, you can use a positive balance as "bandwidth" to make a payment, and you can also use trustline if there is no positive balance. Since Ripple treats both "the same", it requires bilateral authority, a single user being the authority is not enough, they both have to agree on a central authority (ideally by taking turns being that central authority, as in my "Lockstep" mechanism). If instead balance was one thing and a credit limit another thing, authority could be unilateral but then a payment could not go "backwards". Then, manual "circular credit clearing" would be needed instead. My impression is Evgeni Pandurski's ideas rely on that the balance is actually not a bandwidth for payment and instead everything has to be always cleared by the "a circle of debt" mechanism. When the balance adds to the "payment bandwidth", the Two General's Problem gets introduced as you need bilateral authority (whereas with unilateral authority, there is on Two General's Problem since there is only one general, one authority).

So what you bring up is fundamental to authority in Ripple, and why some of the more trivial approaches of assuming authority can be unilateral have failed.

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

I also want to say about the "Circular Multilateral Barter" thing that Ryan credits as having invented Ripple in parallel (on its own), it does not seem to use the design that each "node" in the graph is two users. Instead each "node" seems to be a group. To me, Ripple is defined by that each node is two people. It developed from LETS by shrinking each LETS to just two people (and as in any LETS no one would administer their own credit limit reasonably, with just two people each person logically sets the limit of the other). I have noticed people seem to like to defined Ripple as just the multi-hop, but multi-hop can be done regardless of what a "node" is. Like Interledger, where each "node" is a blockchain. Ripple was the idea that people were responsible for their own mutual credit debt, Ryan says this in interviews frequently. It was defined by that the "node" is a relationship between two people. I try to emphasize this a bit in my short "Ripple Inter Server Protocol" "whitepaper" on ripple.archi/ripple_inter_server_protocol.pdf.

I also want to emphasize: Ripple Inter Server Protocol does not need relaying as far as I can see. Nostr is probably very good for systems that need to relay. But there is nothing to relay in RISP.

Peace, Johan

[Johan Nygren]

maybe "unilateral authority" is possible if two users trust each other

are your implementations viewable online Melvin?

[Melvin Carvalho]

st 14. 5. 2025 v 22:28 odesílatel Johan Nygren <joha...@gmail.com> napsal:

maybe "unilateral authority" is possible if two users trust each other

are your implementations viewable online Melvin?

I'm still speccing right now, and creating building blocks to make a full system.  My last spec was webcredits in 2019:

https://webcredits.org/

With implementation here

https://www.npmjs.com/package/webcredits

Things have moved on quite a lot in the last 5 years.  And I'm ready to throw most of this away, and do a rewrite and full implementation.

My thoughts are to use secp256k1 key for keypair identities.  Model JSON linked objects for ledger, transactions, trust lines, balances etc.

Nostr for realtime pub/sub and a web book keeping system

What I have learnt is that you really need to get the underlying data model right, and to simplify it and make it clean.  A 10% simpler model doubles the effectiveness of the implementation.

There's a bit of nuance around IOUs and trust lines which involve a small trust graph.  I always intended to go this direction.  The thing I had in my head was that a credit a transaction and a trust line are very similar data structures, and how to merge them.  If you think about the balance==0 constraint this might make the model a bit cleaner.

 

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/8b7978a2-18b4-4ff2-be37-20d6e3ae2257n%40googlegroups.com.

[Johan Nygren]

how do you keep track of balances for a user-to-user relationship?

do you do something like a user has authority when they are creditor, if an exchange crosses the zero balance, each user is creditor for part of the exchange

1000 XYZ from A->B->C->D->E

B has a balance of +200 from C

B can authorize 200 of the 1000 XYZ exchange, C has to authorize the remaining 800 XYZ

[Johan Nygren]

I ask since if each user is creditor and only authorizes when they are creditor, there is no Two General's Problem.

Evgeni Pandurski was using such design, separating into two separate creditors, I think. For some reason I assumed it would not work but it seems it would.

In Ryan's design in RipplePay the balance was a singular parameter. Then the users have to agree on it. If they have to agree, there is Two General's Problem and a consensus mechanism is needed.

If each user has their "half" of the balance, agreement is not needed. Of course very easy to lie then, but if there is trust and people prefer using the simpler codebase then that should work too.

This is a "link layer" (user-to-user exchanges, similar to Ethernet in internet) topic. Anyone can use whatever they want. Consensus mechanism or no consensus mechanism (just as with secp256k1 signature vs a sha256(msg+secretKey) vs HMAC, all "link layer"). I was probably wrong about that user-to-user consensus mechanism was crucial. It seems it is not.

The "network layer" in Ripple seems like it has the "stuck payment attack" as the main "unsolved problem". I think what I have come up with (multihop.xyz) is the perfect solution to it.

[Jorge Timón]

Sorry, I haven't fully read the thread, or the previous threads. I don't quite understand Nygren's proposal, but I suspect he means the  "three generals problem"  or "Byzantine Generals Problem".

Regarding the data model, certainly trust lines or negativw values are not needed.

I haven't been working on this stuff since the plandemic, but I can explain the last model I was working on.

Each user (or group) could run their own private (or federated) elements chain[1].

Within the same chain, things are easy, just like doing ripple in a centralized server.

For multiple chains, my idea was to use lightning, but adapted to be able to work across multiple chains and assets.

Lightning's smart contracts can give uss the atomicity we need.

As for the data model, here's how it works. You can issue units of of your own asset. Let's say I issue jtEUR, ryan issues ryanCAD, etc.

Let's say I issue 1000000 jtEUR. While they stay in my wallet, they're kind of meaningless, my "balance" is zero in reality.

But Let's say I trade 100 jtEUR for 100 ryanCAD. Then my balqnce would be -100 jtEUR and +100 ryanCAD.

Does that make sense?

Similarly, a "ripple transaction" is just a series of trades that the payer does until reaching the currency that the payee has to be paid in (let's say, payeeUSD) and the payment itself, all executex atomically (ie all of them are executed or nothing is executed).

One advantage of this is it would be compatible with p2p chains like bitcoin too. Not all the assets involved in a ripple need to be based on credit. For example, real bitcoin from the bitcoin blockchain could be involved in a ripple transaction, transparently to the payer and payee, just like other intermediary assets.

Instead of "trust lines" you have open offers. For example:

"I sell up 100 jtEUR for ryanCAD at a 1:100000 price"

But I could also say, "I buy up to 0.001 btc for jtEUR at a 1:100000 price"

It would work the same for the path finding algorithms.

I wasn't doing things atomically at first, but here's where I left my initial demo on that design:

https://github.com/jtimon/multi-ln-demo

[1] https://github.com/ElementsProject/elements

 

I may come back to this in the future, but currently I'm working on a new programming language. Please, don't use it yet, it's currently super slow and buggy (I've only worked on it for some months so far), but just in case anybody is curious, I'll leave that here too:

https://github.com/jtimon/cil

Glad to see people interested in this again, since Xrp is centralized through the UNL (unique node list). All nodes need to use the same list provided by ripplelaps, or they risk being partitioned from the network. Thus xrp works more like federated chain with a list of block signers than as a truly p2p chain with proof if work instead of signers.

Let me know if you have any doubts about this design.

Cheers

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/9d221b91-28ef-456d-9aaa-eff230a7d097n%40googlegroups.com.

[Johan Nygren]

I meant Two General's Problem, when two users have an account with each other where they need to agree. I assumed two users in Ripple had to agree (therefore I used a consensus mechanism) but if each is a creditor and authorizes whenever the other has debt to them there is nothing that needs to be agreed on, so no Two General's Problem.

I may still be right about the penalty system I came up with. You and Ryan both emphasized "stuck payment attack" back in 2010s Jorge (around the time you both pivoted to Bitcoin-inspired ideas). Ryan's solution back then included a penalty system (a very rudimentary one) where propagation of the "commit" (I call this "finalize" but you called it "commit) decision was enforced with a penalty. The penalty was the full payment. This led to a "distributed race condition" (as Ryan described it), and the solution would be to reduce the size of the penalty. Interledger did this by reducing the size of the payment, their "STREAM payments". This was not a good solution. The other way to do it, is to reduce the size of the penalty. To do it in proportion to how long a user waited to propagate what you called "commit". Organizing this requires a few steps, it is all very logical.

If I was wrong about Two Generals Problem being inherent to Ripple, then maybe, by accident, I ended up right about the penalty system design (a design I came up with by going all-in on my idea that user-to-user consensus was what was missing... i.e., the reason no one had build a true Ripple Inter Server Protocol yet...).

[Jorge Timón]

I think you misunderstand the problem at hand. It's not just two users. A ripple transaction could involve an arbitrary number of users.

For example, a ripple transaction could involve 10 trades + 1 payment, all of which must happen atomically (either all of them happen or nothing happens).

The problem is that aftrr finding a path, even if the parties said they were ready to do their trades, perhaps one of the nodes doesn't go through with the actual final commitment.

Does that make sense?

This is related to the "two-phase commit" design, which is somewhere in the old ripple wiki.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/91623655-972b-4b3b-b13f-8a0f579f672dn%40googlegroups.com.

[Johan Nygren]

No. The "atomic" concept, Ryan Fugger's original design where the penalty was the full system, was not "atomic" in the sense of "either all of them happen or nothing happens". It was an incentive system that meant "if they do not all happen, the person who caused it to not happen pays". You and Ryan (and a few others) then pivoted the design towards Bitcoin-inspired ideas (the topic you used in Sourceforge mail list at the time) but this came after the original penalty-as-enforcement idea. Part of the argument given for doing so was the "stuck payment attack" (you said yourself "The issue registers solve is [...] the possible attack of locking intermediaries credit with fake transactions that never commit") but this issue was already addressed by the penalty system Ryan already used, no? The penalty system Ryan used was too primitive, the penalty was too large (as Ryan described it, there was a "distributed race condition"). Fast forward a few years, and Interledger have realized what is needed: you need to shrink the penalty size so you shrink the "distributed race condition" to the point where it does not matter. But Interledger did this by reducing the size of the payment itself. This is not a good idea. Instead, you can shrink the size of the penalty. I have designed exactly how to do that, a simulation is on https://multihop.xyz/?view=sim (it does not show all information, it more shows the result, but from the documentation and the simple rules it is pretty easy to understand every step in detail).

re: "The problem is that aftrr finding a path, even if the parties said they were ready to do their trades, perhaps one of the nodes doesn't go through with the actual final commitment. "

This problem is fixed by penalty system, but it needs to be more advanced than Ryan's 15 year old one. You need three step payment: commit, seal, finalize. In commit, from buyer to seller, if it does not reach the seller, the buyer has an incentive to cancel because penalty system acts on the buyer at that "state". So you have no problem of "perhaps one of the nodes doesn't go through with the actual final commitment" at that step. The next step, the buyer needs to revoke their right to cancel. The propagation there too, enforced by penalty system (see my rules or ask me how), so no "perhaps one of the nodes doesn't go through with the actual final commitment" problem (anyone who does not go through, is just ending up paying for the payment, slowly, very slowly). The final step, "finalize", is just your old "finish from seller" but with reduced penalty. There too, no "perhaps one of the nodes doesn't go through with the actual final commitment" problem. If anyone does not go through with "finalize", great, they will be paying the payment.

[Johan Nygren]

re: " This is related to the "two-phase commit" design, which is somewhere in the old ripple wiki."

That is not related to "atomic" payment, it is related to the penalty-as-incentive system.

Here in the old Wiki, from 2010s, "Commit message is the receipt, passed backwards down the path from recipient to payer so that each intermediary must transmit value before receiving it in exchange, motivating them to continue passing the receipt along the path. "

It was an enforcement mechanism that solved "the possible attack of locking intermediaries credit with fake transactions that never commit" (as you claimed "commit registers" solved but this is false). But it was a very rudimentary penalty system. I have designed a complete one, see multihop.xyz.

The same concepts seem to be discussed back to 2006 in Sourceforge Ripple forum, Evgeni Pandurski sems very active back then. Back then in 2006 I also see "late-receipt penalty rate" mentioned by Ryan, and this is exactly what has been the missing puzzle piece.

You Jorge seem to join later (2011 on Sourceforge) and you seem to push "Bitcoin-inspired ideas" heavily (as Jed McCaleb later clearly also did... )

The thing with "atomicity" is that it is not possible to have Bitcoin-like atomicity in a decentralized multi-hop payment system. It is not a consensus system. What is needed, is incentives. As the discussion in the Ripple Inter Server Protocol project was focused on back in 2006/2007.

The problem has probably been that you need a three step payment, and conceptualizing and inventing all three steps is hard. You do need "late-receipt penalty rate"  and this lets what you called "commit" (the seller sends "receipt" towards buyer via intermediaries and each person finishes payment) have a smaller penalty than the full payment. It is exactly what is needed.

The problem is: how to organize the late-receipt penalty? This seems simple enough, but there is a catch. With slow-acting penalty, credit gets locked longer. In Ryans design, the pending payment could always time out by itself if there was a problem. But with slow acting penalty, you need a system to make sure that the buyer-to-seller "commit-ready" message (as you called it back in 2010s and maybe earlier) succeeds. This is where my design comes in. I rely on that the buyer has an incentive to cancel, if a penalty system is set up to enforce that (analogous to the late-receipt penalty). Such cancel signal (authenticated by the buyer, just like your receipt is authenticated by the seller) likewise has an incentive to propagate, as the penalty moves to the next hop once a node cancels.

You have all had most of the puzzle pieces. You just did not put them all together. You need a three step payment. The last step, Ryan had already figured out by 2007. He even had the "late-receipt penalty rate", i.e., that the penalty is gradual and not all-at-once. But, he did not figure out how to set up such an agreement without risking lock-credit attack. Here, my "buyer cancels" mechanism (authenticated just like receipt) with an analogous (but opposite) penalty, is the solution.

I have figured this out in a sort of teamwork with the work you have all been doing since 20 years. I also implemented it all already, on ripple.archi, but, I was assuming user-to-user consensus mechanism was needed. A simpler (much simpler) version is possible if each user is authority when they are creditor, and an exchange is thus split up into two "parts", each user authorizing their part (if exchange crosses zero balance boundary, both users authority gets involved, otherwise only one user). Evgeni Pandurski might have been relying on this in his CMB imlementations and I critiqued it originally as not secure but I was wrong, is each user authorizes only themselves as creditor there is no Two Generals Problem.

[Johan Nygren]

The "late-receipt penalty" was a partial solution to "the possible attack of locking intermediaries credit with fake transactions that never commit". But, you never figured out how to set that up without introducing a new lock-credit attack vector. Because of that, you pivoted to the "commit registers" as the "lock-credit attack" solution. But you were already half way to the solution in 2007. The missing puzzle piece is that you can use a similar penalty to enforce that the buyer has an incentive to cancel, unless everyone agrees to be "commit-ready" as you called it. This mechanism is an opposite of the receipt-penalty mechanism. The buyer has to authenticate the decision, just like seller has to authenticate receipt. I call that step "commit" and then I call the "receipt" step "finalize". And in between those, you need a step where the buyer revokes their right to cancel (otherwise there is an attack vector where buyer cancels while seller finalizes at the same time, causing an intermediary to take on the full payment).

[Johan Nygren]

Now finished with a version of my implementation that removes the consensus, http://bitbucket.org/bipedaljoe/ripple-simple.

Melvin I would be happy to contribute to your implementation to, a "link layer" that uses secp256k1 for keypair identities and JSON for state and transactions.

What needs to be agreed on between implementations is the "network layer". The late-receipt penalty Ryan used, based on the late-receipt penalty rate Ryan described in 2006 (here on Sourceforge mailing list), that organizes finishing the payment. An opposite mechanism is needed for starting the payment. This is the one I came up with. To ensure everyone in payment agrees to start it, a penalty that acts on the buyer can enforce that the buyer cancels the payment (authenticated with preimage) unless everyone agreed. This solves how to lead up to the late-receipt penalty rate Ryan considered in 2006 without a "stuck credit" issue.

[Jorge Timón]

Sorry that I didn't read everything, but why would we want a model in which ripple transactions (no matter how many hops they tx has) are not executed atomically?

Seems like a sacrifice to perhaps simplify design, but we don't need to maje that sacrifice. I think a model in which transactions are executed atomically is just superior in all regards.

Unless I am missing some disadvantage of the atomic model, I don't know.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/fd564a0e-aea4-4885-83fa-50c07d54ef15n%40googlegroups.com.

[Jorge Timón]

Also, commit registers provide atomicity just fine, not sure what you mean by "this is false". The problem is all users in the transaction need to trust the same commit server.

[Johan Nygren]

You Jorge seem to have joined the Ripple project around 2011 and it seems you were always interested in "commit register" as solution. Maybe you came from Bitcoin? Or maybe you were following or part of Ripple project long before 2011 but you never posted on the Sourceforge mailing list.

"Commit registers" were the "plan B". They were introduced because "plan A" failed. Ryan was half way to solving "plan A" by 2006 from what I can see. Interledger continued on the "plan A" approach, with their STREAM payments, but those are also not very good, so "plan B" ("commit registers") may have still been the best option. But I have now solved "plan A", and "commit registers" is no longer the best option.

Ripple is a money system that has to potential to transcend the trusted third party. "Commit registers" as "plan B" just reintroduce the trusted third party. With "commit register" people could just as well do a direct payment without trustlines, as there is already a trusted third party. There may be some benefits of a hybrid system compared to just a bank, and I acknowledge "plan B" has probably been the best option. It is not anymore as I have solved "plan A". "Plan A" took 19 years or so then to invent, as Ryan invented half the solution by 2006 and I invented the rest now in 2024/2025.

re: "why would we want a model in which ripple transactions (no matter how many hops they tx has) are not executed atomically?"

Ripple is a money system that gets rid of the third party. Why would anyone want to get rid of the third party? Everyone here can probably explain with their own words why they want to. One reason is just efficiency, computationally. Then there are other reasons too.

re: "Also, commit registers provide atomicity just fine, not sure what you mean by "this is false"."

I assumed path could still time out, since otherwise there is still lock credit problem. But if this time out is set to a block height or so, then you get atomic time out.

[Evgeni Pandurski]

I think Johan's attempts to invigorate the debate around Ripple's
history and fundamentals is necessary and timely, given the
current obsession with snake-oil solutions like Bitcoin.

I think the complexity of the subject is such that it is easy to
be drawn to solutions to "the wrong problem".

Indeed, what problem Ripple (and Johan) is trying to solve?

*Payments without intermediaries?*

Well, you've got much more intermediaries with Ripple.

*Payments without a "big brother" third party?*

Ripple does not exclude this by design. Moreover, I claim that
only barter, delayed barter, and commodity money (those are simply
different forms of barter) can, in principal, achieve this. People
easily forget that when we have a creditor, and a debtor that owes
money to the creditor, there is an "invisible" third party -- the
issuer and the backer of the money. (Although, the issuer and the
backer can be different as it is in the current banking system.)
As money become increasingly digital, the "big brother" third
party can intervene in the creditor's and debtor's affairs with
pin-point precision. Therefore, the only way to really exclude the
"big brother" third party is to arrange either the debtor or the
creditor to be the issuer and the backer of the currency in which
the debtor is indebted to the creditor.

There are only two possibilities:

a) When the creditor is the issuer of the currency, both the
creditor (as he should be the backer of the currency), and the
debtor (as he is in debt) must be trustworthy. In practice, this
is a serious problem. Welcome to the current banking system we all
love: Creditors have political (and physical) power over debtors,
and the result is that the creditors are the issuers of the
currency, but the debtors are the backers. Everything works well
until debtors realize that they have been swindled, which usually
happens only when they have lost everything. Eventually, creditors
lose everything too.

b) When the debtor is the issuer of the currency, he is the only
party that need to be trusted. The debtor is the issuer and the
backer of the currency. I believe this is the only solution that
works in the long run. Note that the debtor may decide to
denominate his currency in some third-party's currency (that is: a
currency peg). In this case, there would be a third party, but
this is entirely optional, and only a convenience. The debtor is
the backer of the currency.

But lets go back to what problem Ripple is trying to solve.

*Maybe then, Ripple is simply about making payments in third
parties' currencies?*

This makes sense. Do one thing, but do it well, right? There are
two possible types of payments:

1. Payment which do not include currency exchanges along the way
to the recipient.

If this is the problem Ripple is trying to solve, in the age of
digital currencies, it is an exceedingly easy to solve problem. To
make a transfer in a physical currency, money needs to change
hands (a Vala-like system). To make a transfer in a digital
currency, you simply need to "tell" some server to do it.

2. Payments which include currency exchanges along the way to the
recipient.

If this is the problem that Ripple is trying to solve. I believe
it is shooting for the Moon with this. Essentially, this would
require engineering an a completely automatic, de-centralized,
currency exchange platform.

I believe the only special case in which this problem has a
relatively simple automatic solution is when the exchange is
centralized, and all the participating currencies are pegged to
each other (or to one common currency).


I guess, the sneaky question I am asking is: What is Ripple
*really* about?

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

[Johan Nygren]

Hi Evgeni first I want to apologize for making false claims about that Two Generals Problem was inherent to ripple-like systems. It is not (it can be a good feature to have if trustworthiness is not 100% or people want to be able to audit transaction history for other reasons or they simply want a copy if one server explodes, but authority can be fully unilateral too). Not sure how your Swaptacular did it, it seemed to still use some kind of central authority somehow, but you did seem to separate users into creditors and debtors instead of a single shared account and at the time I was assuming a shared account was needed.

re: "Indeed, what problem Ripple (and Johan) is trying to solve?"

I invented multi-hop wealth redistribution in 2012, a system called Resilience (link). I have over the years tried to figure out why no one has built Ripple. A year ago I decided to build it myself. I made a few wrong assumptions, but eventually ended up finding what was missing. It continues where you and Ryan were in 2006 (here for example), I also have "penaltyRate" in my equivalent to your "promise message" (I came up with it without knowing about your drafts in 2006). Where you hit a dead end must have been for how to organize that the penalty starts to tick. There you have a "lock credit attack vector". You solved the lock credit attack vector during "finishing payment" (what you called the "commit" phase) with your penalty, so you solved half the problem. Now 19 years later I solve the other half, how to start the payment.

re: " There are only two possibilities:"

I don't really know what it means (or what the difference is) between creditor is issuer or debtor is issuer. The creditor reasonably sets the credit limit. Without a user-to-user consensus mechanism (agreeing on a central authority, that is either constant or the users take turn being the authority) that means the creditor has to be the record keeper of the balance (debt) too. Otherwise, no way to synchronize credit limit and balance.

re: " There are two possible types of payments:"

To me it seems both you and Ryan have been very interested in exchange rates at every hop. Myself I do not see the need for it. But it does not seem it has to be one or the other. I give it no thought. It seems like a "link layer" issue and not a "network layer" so there would not be a compatibility issue, people could use it or not use it and still use same network. However it would work (I give it no thought).

re: "I guess, the sneaky question I am asking is: What is Ripple *really* about?"

To me it seems you and Ryan had similar, but slightly different, ideas. You had the same decentralized multi-hop payment idea, but, differed on what the "node" was. In your system, the "node" was a group, and in Ryan's system the node was a person. Those overlap mostly. Resilience happens to require that a node is a person, otherwise the basic income does not reach people directly. To me Ripple is about the truly decentralized money system that I can integrate swarm redistribution into, so that each person in the world gets access to basic needs in the same way they can breath O2 from the atmosphere.

[Jorge Timón]

No, actually I was never interested in the "commit registries solution and has 0 to do with bitcoin.

To me, non atomic solutions were never part of the plan, and not because of anything I learned from bitcoin, that's just basic database stuff from university. ACID, they call it. It's  concept from computer sxience, you're clearly not familiar eith such concepts, nut that's not my fault.

If suboptimal solutions without atomicity are interesting to you, you are free to persue them.

There is no need for any "third party", we can have atomicity, with or without blockchains, with a two phase commit.

As for the tone you're using, now I'm glad that I didn't read everything you wrote, because it seems clear to me that it would have been a waste of time.

I was trying to be nice to you, but I don't think you deserve that treatment anymore.

I was trying to explain things to you. But you're bit interested in learing anything, only in lecturing us on a topic you clearly know very little about.

Good luck, you're going to need it.

And have a nice day.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/f0c1cdba-e49e-46d8-89a8-9ed08962d8a2n%40googlegroups.com.

[Johan Nygren]

re: "There is no need for any "third party", we can have atomicity, with or without blockchains, with a two phase commit."

The two phase commit: "Distributed 2-phase transaction model: commit-ready, then commit" (as defined here, https://ripple.ryanfugger.com/Protocol/DesignConsiderations.html), is "atomic" in the sense that the seller always gets paid, but not in the sense that "either all of them happen or nothing happens)." 

re: "To me, non atomic solutions were never part of the plan,"

If you define atomic as "either all of them happen or nothing happens)."  then the design Ripple Inter Server Protocol had prior to "commit registers" was not that. You joined in 2011 on Sourceforge (not sure if you were part of the Ripple project before that) so that older plan may never have been your plan, but I was also not saying that, I said it was the plan of the Ripple project.

re: "you're clearly not familiar eith such concepts, nut that's not my fault."

Well, I disagree (or misunderstand) your definition of two-phase commit compared to how it has been defined by the Ripple project. I am not sure that has to mean I am not familiar with computer science or that I am a retard or a nut.

re: "I was trying to explain things to you. But you're bit interested in learing anything, only in lecturing us on a topic you clearly know very little about."

I do think I have solved where Ryan and Evgeni and others got stuck with the late-reciept penalty rate  model, and I do think this could be relevant to the Ripple project and the community of people around it. If that comes across as me only wanting to lecture you, I guess that is right in case I am wrong. But if I am right and I solved the "lock credit attack vector" during setting up of penalty rate ticking, why would my reason to write here be only to lecture.

Either I am full of shit and not worth any attention at all, or, I actually have solved the problem that Ryan and Evgeni and others got stuck at in 2006. My simulation and description on mutlihop.xyz is pretty good.

[Jorge Timón]

I'm sorry, I don't feel like reading anything else you write anymore.

Check this out:

http://www.catb.org/esr/faqs/smart-questions.html

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/811822b5-631f-4f34-97b7-914ab957afddn%40googlegroups.com.

[Johan Nygren]

Jorge that is fine.

I think I have replied accurately to you. I have claimed that the original plan for Ripple Inter Server Protocol was not "commit registers". I have claimed that the way you describe 2-phase commit would be "atomic" ("either all of them happen or nothing happens") is not how the 2-phase commit seems to be defined, as can be verified here, https://ripple.ryanfugger.com/Protocol/DesignConsiderations.html. I have claimed that the original design (that used that "2-phase commit") got stuck at a problem, and pivoted to "commit registers" as a "plan B" around the time you seem to join the Sourceforge mailing list (so it may appear then to you that it was always the plan, unless you were also following or part of Ripple project before that too). Correctness of these claims can be verified independently by anyone.

If there is anyone in this community interested in how to finish the design ideas Ryan and Evgeni had back in 2006 when they got stuck (specifically they got stuck at how to get the penalty ticker to start without creating yet another "lock credit attack vector", and this is specifically what I have solved), this community forum seems like the right place to discuss it. Interledger has pursued an alternative to the "late-receipt penalty rate" by shrinking the size of the payment itself but it is not a good idea (but it does highlight what the problem is and has been since 2006).

[Evgeni Pandurski]

I think the reason for this escalation between Jorge and Johan is
to a very large degree linguistic.

Because some of us are not native speakers, it is very hard for us
to write naturally, without convening some negative attitudes. It
has happened to me more than once. When you write passionately, in
the manner natural to your native language, you can not feel the
important nuances that your writing conveys, in the foreign
language, which the reader, even if the reader is not a native
speaker, unconsciously pick up, and reacts to.

I do not think Johan was trying to be condescending toward Jorge
or me. I believe this is just the wrong impression of his writing.

I assume Johan is a young man, and if anything, the interest of a
young man in the history of old mans' discussions is not
condescending but flattering.

[Johan Nygren]

I can try to prove that I have solved the missing puzzle piece.

Evgeni do you remember why you and Ryan abandoned the late-receipt penalty rate?

The one you discuss in 2006: https://sourceforge.net/p/ripple/mailman/message/1307802/

I am assuming that you abandoned it because it could not be organized without creating new problems.

I assume the problem was: the message people send to tell each other to start the penalty ticker, what prevents the payment from getting stuck at that step?

[David Watson]

Meh, Johan is just an asshole.  No need to overthink it.

He was rude to me as well.  He's an amateur bully who wants help figuring out shit he doesn't understand, so he attacks any feedback that doesn't confirm his own beliefs.  He doesn't have his own community so he's squatting on this one.  His behavior makes it quite clear that even if he did achieve some success, his self-interest would likely destroy it before it had a chance to take off.

Maybe he's young and immature, but even if that's the case, making excuses for him isn't going to help.

Just seems like a bipolar spamming the thread.  

My two cents.

David.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/87msbaymvu.fsf%40hp6000.home.net.

--

David N Watson Jr.
Email:  wizard...@gmail.com
Cell:  1-785-220-4318

[Evgeni Pandurski]

Johan Nygren <joha...@gmail.com> writes:

> Hi Evgeni first I want to apologize for making false claims
> about that Two Generals Problem was inherent to ripple-like
> systems. It is not (it can be a good
> feature to have if trustworthiness is not 100% or people want to
> be able to audit transaction history for other reasons or they
> simply want a copy if one
> server explodes, but authority can be fully unilateral too). Not
> sure how your Swaptacular did it, it seemed to still use some
> kind of central authority
> somehow, but you did seem to separate users into creditors and
> debtors instead of a single shared account and at the time I was
> assuming a shared
> account was needed.

I think the shared account is not needed when the debtor is the
sole authority. In this case all the creditor may have is "an
opinion". Of course, the creditor will observe closely all the
transactions, but the debtor has the final say, at least formally.
Informally, the creditor may have other powers that can make the
debtor cautious of any stupid ideas.

>
> re: "Indeed, what problem Ripple (and Johan) is trying to
> solve?"
>
> I invented multi-hop wealth redistribution in 2012, a system
> called Resilience (link). I have over the years tried to figure
> out why no one has built Ripple.
> A year ago I decided to build it myself. I made a few wrong
> assumptions, but eventually ended up finding what was missing.
> It continues where you and
> Ryan were in 2006 (here for example), I also have "penaltyRate"
> in my equivalent to your "promise message" (I came up with it
> without knowing about
> your drafts in 2006). Where you hit a dead end must have been
> for how to organize that the penalty starts to tick. There you
> have a "lock credit attack
> vector". You solved the lock credit attack vector during
> "finishing payment" (what you called the "commit" phase) with
> your penalty, so you solved half
> the problem. Now 19 years later I solve the other half, how to
> start the payment.

Somewhere around 2009-2010 I lost interest in the Ripple protocol,
because I started working on the "Circular Multilateral Barter"
project. I thought, Ripple is trying to solve the wrong problem,
and the only reason people persist on this, is because the problem
is interesting and hard. If it weren't, people would instantly
realize that this is "the wrong problem".

The right problem, I believe, is "Who and how issues the
currency(es), and who backs it".

>
> re: " There are only two possibilities:"
>
> I don't really know what it means (or what the difference is)
> between creditor is issuer or debtor is issuer. The creditor
> reasonably sets the credit limit.
> Without a user-to-user consensus mechanism (agreeing on a
> central authority, that is either constant or the users take
> turn being the authority) that
> means the creditor has to be the record keeper of the balance
> (debt) too. Otherwise, no way to synchronize credit limit and
> balance.
>
> re: " There are two possible types of payments:"
>
> To me it seems both you and Ryan have been very interested in
> exchange rates at every hop. Myself I do not see the need for
> it. But it does not seem it
> has to be one or the other. I give it no thought. It seems like
> a "link layer" issue and not a "network layer" so there would
> not be a compatibility issue,
> people could use it or not use it and still use same network.
> However it would work (I give it no thought).

Arriving at an exchange rate that is approved by both the seller
and the buyer is a very hard problem. It can not be solved
automatically. It is kind of a power-play between two (or more)
players.

>
> re: "I guess, the sneaky question I am asking is: What is Ripple
> *really* about?"
>
> To me it seems you and Ryan had similar, but slightly different,
> ideas. You had the same decentralized multi-hop payment idea,
> but, differed on what
> the "node" was. In your system, the "node" was a group, and in
> Ryan's system the node was a person. Those overlap mostly.
> Resilience happens to
> require that a node is a person, otherwise the basic income does
> not reach people directly. To me Ripple is about the truly
> decentralized money system
> that I can integrate swarm redistribution into, so that each
> person in the world gets access to basic needs in the same way
> they can breath O2 from the
> atmosphere.

LETS systems were very influential at that time. I remember that I
thought Ripple can not work between individuals, because of it
complexity, among many things, but it could work as a way to trade
between LETS systems.

The constant failure of LETS systems to deliver what they promise,
made me skeptical about them too. Ironically, I came to the
conclusion that the way banking works is much closer to what is
needed than I thought. It only needed a few alternations...

> I don't really know what it means (or what the difference is)
> between creditor is issuer or debtor is issuer. The creditor
> reasonably sets the credit limit.

I think this is precisely the difference between a just and
sustainable banking system and a dysfunctional one. In the current
banging system, the creditor (the bank) is the issuer of the
money, so in order to collect their debts banks need to obtain
huge political power and control. Otherwise debtors would be
untrustworthy. Unfortunately, this gives banks too much power.

When debtors are the issuers of currencies, there is a balance of
power. Creditors may continue to have political power and control,
but the debtors are not helpless. In the worst case, if creditors
apply too much pressure, the debtor may declare bankruptcy and
leave town. The "socialistic" countries had more or less this kind
of a banking system (under pressure, the banks "left town").

I believe the most important alternation, however, is to have many
"banks" and not just one. By "bank" I mean any trustworthy private
or public business or organization. This could be a private
restaurant, a municipality, or even a whole country. All of them
existing in parallel. Some may "leaves town", but others will
remain functioning.

In any case, I believe banking is inherently a "dirty business".
Decent people generally should avoid it. I would not look at any
sort of banking in order for everybody to "get access to basic
needs in the same way they can breath O2". That being said, it
does not mean that banking is inherently bad. Draining sewage is a
dirty business too, but it is crucially important. And it must be
done properly, otherwise things get even worse.

[Johan Nygren]

Evgeni do you remember why you and Ryan abandoned the late-receipt penalty rate that you were discussing in 2006?

re: David Watson

Yes I was up front with you and said Ripple is not basically lightning, and that many here agree on that. As for bipolar, part of my interest in decentralization came from med. school in 2009 and how the cause of disturbed executive function was neglected and the medical profession appropriated as a sort of "butcher" there. This is well defined here and my work there has been pretty popular in the "p2p community". I think it is very low behavior to try and label people as bipolar and what-not. Just like it was low and cowardly behavior to label women as Hysteric 150 years ago, yet, cowards still did!

[Evgeni Pandurski]

On Sun, May 18, 2025, 19:43 Johan Nygren <joha...@gmail.com> wrote:

Evgeni do you remember why you and Ryan abandoned the late-receipt penalty rate that you were discussing in 2006?

I do not remember exactly. I vaguely remember that I thought that as a whole, the system started to become too complex to be practical.

[David Watson]

You scraped old posts looking for something to attack.  Fuck off.

David N Watson Jr.
Email:  wizard...@gmail.com
Cell:  1-785-220-4318

--

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/b037a8cc-f010-4708-a817-ae2fb346a2dfn%40googlegroups.com.

[Johan Nygren]

Evgeni, OK yes a complete penalty system does get a bit complex.

But it is manageable. Mainly you need to add one step. The late-receipt penalty rate introduces just one new attack vector.

Ryan do you remember why you and Evgeni abandoned the late-receipt penalty rate that you were discussing in 2006?

re: David Watson

No I had seen it before. It stands out as the topic "Bitcoin Lightning Network is Ripple" and I posted around that time too. I disagree, many others here do too, this we already discussed two months ago.

[Dan Miller]

It seems like several thinkers and experimenters still have interest in
these types of issues, even if the past, present, and future of Ripple
is probably something not many on this list are interested in anymore. I
wonder if there is a contemporary community where this type of ethos is
practiced and discussed?

[Johan Nygren]

Dan in 2006 Ryan and Evgeni had half of a perfect design. They used a "late-receipt penalty rate". It introduced an attack vector (a "lock credit" attack vector). I assume Ryan and Evgeni abandoned the idea because of that. As Evgeni said, the protocol was getting too complex. Additions to it were causing new problems. But, they were on the right track. You just have to solve the problem "late-receipt penalty rate" created, and the protocol is complete. Simply put, Ryan and Evgeni's "late-receipt penalty rate" solves how to finish the payment without a "lock credit attack vector". What is then needed, is how to start the payment without a "lock credit attack vector" (i.e., set up the penalty ticker based on the "late-receipt penalty rate"). The same "penalty rate" can serve to enforce that the buyer has to cancel unless everyone agrees to start the penalty ticker and start the payment. The "late-receipt penalty" then serves to finish the payment. Both when starting and finishing payment process, there is a "lock credit attack vector". It needs to be solved in both cases, but Ryan and Evgeni only solved it in the latter.

Since this solves where Ryan and Evgeni got stuck in 2006, and as far as I know no one else has solved it until now, it seems like this is the contemporary discussion, happening right here. I do not think there is such discussion anywhere else unless someone else has solved this exact problem too. I have simulated the model in full on multihop.xyz, I have complete implementations (both with or without user-to-user consensus, and also with swarm redistribution on either consensus and no consensus version). As this solves "network layer" problem (how to prevent "the possible attack of locking intermediaries credit with fake transactions that never commit" as Jorge Timon put it in 2011 on Sourceforge mailing list), it is easy to write "link layer" implementations with any format. Such as secp256k1 (whereas I use just sha256(msg+key) as I wanted simplest possible reference implementation). Anyone could do so in probably a few weeks of work, and we could start using a true Ripple Inter Server Protocol network. The missing puzzle piece has been how to prevent the possible attack of locking intermediaries credit with fake transactions that never commit.

My point being: this is the contemporary discussion.

[Jorge Timón]

8I think these designs may be interesting, even if I prefer atomic designs.

But this guy is disrespectful, ignorant, and he doesn't listen.

For example, he says: "the two phase commit is atomic in the sense that the payee always gets paid, not in the sense that all the payment hops happen or none of them".

This is very evidently wrong, if that was the case, what would be the point of the two phases?

Not only this guy seems to think he is some sort of genius, but he is clearly clueless ans can't read. If that's what he understands about the two phase design after reading it, if he thinks he has solved anytjing about ripple while at the same time he thinks that "it's a two general problem because there's only payer and payee" (ie he didn't even know that ripple is all about multi-hop payments), then I certainly don't want to even try to understand his design which is almost surely broken, and if it was an atomic design too.

And he can't fix the design because not onlt he can't properly read, but also hs no will to learn. You explain to him what the concept atomic means in computer science and the guy answers that's not what it means to him. Ok, buddy...

Plus he also implies I have nefarious intentions for prefering atomic designs or using bitcoin.

If he is not going to listen to anything and he is going to insult me, he can take this dessign of his or any other design he has (atomic or not) up his ass, to be honest.

But, hey, dan, if you don't think you're wasting your time by talkibg to this guy, I think you can do it here just fine. I just personally read enough from him.

I'm still ibterested in these topics, but not in wasting my time with an arrogant and deaf clueless DS.

As explained in the "how to ask quesrions the smart way" document (which he clearly also didn't read), with his attitude he will be ignored in most free software communities if not all, not just in this one.

He is wrong about many things and he can't be explained wht because he doesn't listen. Therefore it is a waste of my time to try to explain anything to him or trying to understand his likely-broken design, that's all.

Have fun discussing his design yourself if you don't consider it a waste of time.

--
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/e244216c-7ac1-4b9b-85e4-1d053ccecdbd%40gmail.com.

[Dan Miller]

Discussion of technical improvements is obviously important and interesting
when its respectful and focused and open-minded, but I think the points
David Watson brought up about community issues, adoption, UX, etc. really
trump this because the reason these systems do not see the use we all hoped
for are not technical. One reason I was interested in 2006 or so Ripple was
because it reminded me of informal distributed clearing networks that
Japanese
banks and traders used for interest rate swap trades (pre-electronic
trades).
I'm sure this wasn't novel, its just the only direct experience I had at
the time.

[Melvin Carvalho]

po 19. 5. 2025 v 18:10 odesílatel Dan Miller <dan.r....@gmail.com> napsal:

Very good point.  However, to create a world class UX can be work or capital intensive, especially in 2006.

I think in 2016 things improved with various frameworks.

By 2021 there was some maturity and stability in the front end tooling.

Now in 2025 creating a great UX is doable by a small team or single dev.  It will get easier next year.

If we nail down the data model and requirements, a small team would be able to make a great UX, IMHO. 

 

--
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/f4f856e7-6fb5-4de9-8056-f697efef66c3%40gmail.com.

[Melvin Carvalho]

po 19. 5. 2025 v 18:13 odesílatel Melvin Carvalho <melvinc...@gmail.com> napsal:

po 19. 5. 2025 v 18:10 odesílatel Dan Miller <dan.r....@gmail.com> napsal:

Discussion of technical improvements is obviously important and interesting
when its respectful and focused and open-minded, but I think the points
David Watson brought up about community issues, adoption, UX, etc. really
trump this because the reason these systems do not see the use we all hoped
for are not technical. One reason I was interested in 2006 or so Ripple was
because it reminded me of informal distributed clearing networks that
Japanese
banks and traders used for interest rate swap trades (pre-electronic
trades).
I'm sure this wasn't novel, its just the only direct experience I had at
the time.

Very good point.  However, to create a world class UX can be work or capital intensive, especially in 2006.

I think in 2016 things improved with various frameworks.

By 2021 there was some maturity and stability in the front end tooling.

Now in 2025 creating a great UX is doable by a small team or single dev.  It will get easier next year.

If we nail down the data model and requirements, a small team would be able to make a great UX, IMHO. 

For example, here is a screenshot of a prototype I was able to build quite quickly:

[Dan Miller]

I should have been more clear, I don't think the reasons these systems aren't used is because a lack of a magic bullet technical implementation detail breakthrough, or a nice, clean, friendly interface either, but because of the lack of a compelling answer to the question David Watson Surfaced: "Why would I want to use this?"

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/CAKaEYhJ1%3DrEg%2BdppNQz%2B1rCFkOKn4t2o2mXUKp3y_ccVEAEoPQ%40mail.gmail.com.

[Melvin Carvalho]

po 19. 5. 2025 v 18:52 odesílatel Dan Miller <dan.r....@gmail.com> napsal:

I should have been more clear, I don't think the reasons these systems aren't used is because a lack of a magic bullet technical implementation detail breakthrough, or a nice, clean, friendly interface either, but because of the lack of a compelling answer to the question David Watson Surfaced: "Why would I want to use this?"

I would definitely want to use it, otherwise I would not be so interested in building it.

IOUs make up 97% of the money in the world.  So that's already a huge market.

Plus there is a need for the emerging agentic space for agents to communicate, do jobs for one another, pay for a request, an image, a chat and so on.

Anyone that's used proprietary versions of ripple might want to consider switching to an open version too.

 

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/09967ff4-96ea-4d13-8049-82a1d165bdb3%40gmail.com.

[Johan Nygren]

Dan, what has been missing is a "magic bullet technical implementation detail breakthrough". This "magic bullet" is the same Ryan and Evgeni were pursuing in 2006, the "late-receipt penalty rate" (as they discussed here). Evgeni has said here that the system starting to get too complex may have been one reason that "magic bullet" was abandoned. As I have said, the "late-receipt penalty rate" solves one "lock credit attack vector", it forces each hop to propagate the decision to finish the payment. But, it also created another "lock credit attack vector". A solution to a problem that ends up creating the exact same problem at another place, can seem like the wrong solution. It is understandable Ryan and Evgeni abandoned it (or, set the penalty to be the full payment instead...). But if you instead solve the problem it created, by adding one more step to the payment, you have a complete solution. This I have defined well on multihop.xyz. Evgeni and Ryan could verify more if my assumption about why they abandoned the "late-receipt penalty rate" is true.

Interledger around 2018 something returned to the same type of solution Ryan and Evgeni had in 2006, i.e., a "chunked" penalty. They did this in another way than "late-receipt penalty rate", they did it by reducing the size of the payment itself with STREAM payments. I.e., Interledger were clearly pursuing the same type of "magic bullet technical implementation detail breakthrough" that I am discussing here. Their solution is not good, but it does highlight the need for a "chunked penalty" solution and it does corroborate that Ryan and Evgeni were on the right track in 2006. Now 19 years later, I finish what they started, and I present the complete solution on multihop.xyz. It is very easy, but it required a team effort to come up with, it required the work of Ryan and Evgeni in 2006 and then the work of myself now (and Michiel de Jong has contributed too, at least indirectly. Michiel feel free to chime in here in the discussion on the penalty system).

re: "This is very evidently wrong, if that was the case, what would be the point of the two phases?"

Jorge if you mean the 2-phase commit described here, https://ripple.ryanfugger.com/Protocol/DesignConsiderations.html, it does not mean every hop succeeds, it only means the seller gets paid.  Anyone can verify this independently. I have also acknowledged that prior to solving the "lock credit attack" in a truly decentralized way (as Ryan and Evgeni were halfway to doing in 2006, and Interledger also attempted with STREAM payments), "commit registers" was probably the best solution. This is probably why Ryan Fugger decided to use them.

[Johan Nygren]

Ryan and Evgeni's "late-receipt penalty rate" solved the issue of one decision getting stuck, but it itself required a decision that could also get stuck. The issue of that next decision getting stuck can be solved with yet another penalty, but it also requires a decision that can get stuck. And that last decision, can also be solved with a penalty (with a combination of the two previous penalties).

Evgeni's feeling that the protocol was getting too complicated was very reasonable. A solution that creates another problem that motivates a new solution that in turn creates yet another similar problem. It is very reasonable to feel like it might be the wrong approach.

The thing with these "stuck decision" problems is they occur from two directions. From the seller when finishing the payment, from the buyer when starting the payment. I was innovating from the point of view of starting the payment (and I was completely ignorant of how to solve finishing the payment) and I managed to come up with the idea that if the decision got stuck, the buyer would always have the right to cancel, and that a penalty could enforce that the buyer always cancelled. When I noticed that my solution created yet another stuck decision problem, I might have given up too, but co-incidentally I noticed that if I just added what Ryan and Evgeni already had 19 years ago, it worked.

Do you understand? Ryan and Evgeni abandoned the approach because it got too complex, each solution created a new problem. I was facing the same problem, but my innovating process was from the opposite point of view. So I could simply add Ryan and Evgeni's old design on top of mine for a full solution. I did not plan to do so, it happened accidentally. A form of "indirect teamwork" stretched out over 19 years. Multihop.xyz shows a good simulation.

[Johan Nygren]

Melvin, the way to rethink Ripple data model might be to separate the "user-to-user account" into two separate creditors instead. Your post here inspired that idea. The problem when the "user-to-user account" is treated as an entity (i.e., "So every user has a balance, and a minimum balance that could be negative, for a set of trusted users" as you wrote), is it introduced a Two Generals Problem. This can be solved but simply skipping the shared balance is an alternative. Then user_in contributes as much as they can to the payment and user_out the rest (see code here https://bitbucket.org/bipedaljoe/ripple-simple/src/63538a0a51ce5c00457a28d771ba5d366c19f7fe/handler/accountHandlers.go#lines-182).

To avoid user_in lying in this design about how much debt user_out had, users simply have to synchronize their peer (master slave type synchronization) but that has no Two Generals Problem. This part is not yet in https://bitbucket.org/bipedaljoe/ripple-simple but it should be easy to add. The penalty system is there in full.

I am open to that I miss something (I have assumed for over a year that user to user consensus was needed) but so far it seems like it should work.

To unsubscribe from this group and stop receiving emails from it, send an email to rippleusers+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rippleusers/dbf4e344-56a4-4a8a-8cc0-51e9ae444e60n%40googlegroups.com.

[Johan Nygren]

Now finished non-consensus version, https://bitbucket.org/bipedaljoe/ripple-simple.

Probably no new ideas, others probably have similar design for long time.

I see some benefits to user-to-user consensus approach and some to non-consensus approach, and as it is "link layer" in Ripple (and not "network layer") anyone can use whatever implementation they want. It is an "implementation issue".

The implementation has the full penalty system that continues on Ryan's "late-receipt penalty rate" idea from 2006. This is what I suggest is an innovation, and I suggest it has been the missing puzzle piece. I describe it in full on multihop.xyz including an interactive simulation. With it solved I think we as a community could launch Ripple Inter Server Protocol. There are many people interested in doing so. But the project has been "stuck in a rut". Because there was an obstacle that could not be overcome. I suggest my 3-step payment solves that.

Peace, Johan

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/dbf4e344-56a4-4a8a-8cc0-51e9ae444e60n%40googlegroups.com.

[Johan Nygren]

re: For example, he says: "the two phase commit is atomic in the sense that the payee always gets paid, not in the sense that all the payment hops happen or none of them".

This is very evidently wrong, if that was the case, what would be the point of the two phases?

"Staggered timeouts" (timelock delta in Lightning) make it likely that each hop can "redeem the promise" or the "htlc claim" from the next hop, but this can still fail. This means it is not atomic in the sense that every hop succeeds, only in the sense that the end recipient always gets paid.

One approach is to neglect this problem, and pretend like it does not exist. This seems to be what Jorge does, and then, my person must be attacked if I point out the problem (and I say "it is not atomic", which it is in fact not).

Those interested in acknowledging the limitation in the current approach to multi-hop payments, may also be interested in solving the limitation - removing it. Interledger worked on trying to do that with their 2018 "stream payments", an example of that many are interested in solving the limitation. To pretend the limitation does not exist, and attack my character, is low behavior.

I initially assumed Jorge was interested in commit registers and made his "it is atomic" argument based on that (and yes, "commit registers" can be atomic), but it seems he was just neglecting the scenario where the "cancel on timeout" is not atomic, pretending like that limitation does not exist, and that the person who points at it should be ignored and publicly slandered.

Now that I understand Jorge's PoV, Jorge you have a solution that fails if someone fails to pass on payment before the timeout. They get stuck with the full payment. This is a big risk. People have acknowledged this risk. Ryan acknowledged it and this is why he pivoted to commit registers idea (and attempted "chunked penalty" prior to that). You can remove that risk.

You have publicly stated you will ignore me. But, now that I understand your PoV, I can try and meet half way (it was hard to do so previously as you made no sense). You have only half a solution and the other half is quite easy.

The timeout can be used in two ways, cancel on timeout or finish on timeout. You use cancel on timeout. There you have DoS vectors not penalized. You have to add "initialize" step that finishes on timeout, that leads into the one that cancels on timeout, to penalize every DoS vector. With that, you can do continuous timeouts (increase the full length of the combined timeouts) as the timeout alone is no longer what prevents DoS, it is the penalty imposed by the timeout (in the trivial solution such as what Lightning Network uses, you only have penalty when "redeeming promise", not when doing what Ryan called "commit-ready", so it relies both on the timeout itself but also on the penalty imposed by the timeout).



Peace, Johan

[Jorge Timón]

If you want me to insult you more, please, keep insulting me, misrepresenting my words and lying about me.

I'm trying to ignore you, but you're making it really hard.

I don't want to interact with you in any way. Can you please stop talking about me?

Thank you

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/9a0bb3d4-e150-41e2-a2c8-f77c5b39344dn%40googlegroups.com.

[Johan Nygren]

That's fine. For the community here, you brought up the topic that 2-phase commit is already atomic and already works and there is no problem. For the community here, I explain how it is not atomic, the "staggered timeouts" can time out at any hop. It is a pretty good solution that Ryan came up with in 2006/2008, but it is not atomic. As I now understand your PoV (I assumed you referred to commit registers as atomic, but you actually refer to the 2-phase commit as atomic as it is in the cases "staggered timeouts" do work) I can better explain what the miscommunication was. My goal is the success of multihop payments, and not to insult you, or invade on you in any way, and as I have solved multihop payments, that is directed to this community and not to you personally. I originally shared a year of work here where I had come up with the "finish on timeout" approach, and given the feedback from Ryan and Michiel, I managed to solve the DoS problem entirely. This is not about you, personally. And this is also not a personal space, it is a community space. If this community wants to exclude someone, they can. But an individual who wants to exclude someone, can do so in their space but not in a community space. Right. So I must be able to respond here. You are not a victim, stop acting like one.

The cancel on timeout mechanism all multi-hop solutions use so far will always have the risk of punishing a non-attacker. Likewise, a finish on timeout mechanism that is easy to invent as well, will also always have the risk of punishing a non-attacker. The risk of punishing non-attacker is solved by a "chunked penalty", but it requires increasing the combined time of the timeouts which means the timeout itself can no longer prevent DoS attacks. This means every step of the payment has to be enforced with a penalty. This requires a combination of the cancel on timeout and finish on timeout approach.

What I describe is very logical. It is very appropriate to share it in a group dedicated to multihop payments (to Ripple). It is a significant discovery. It is explained well. It can be nice to pretend like the "cancel on timeout" approach alone is atomic, but it is not. If it was, why has not Ripple Inter Server Protocol succeeded? Why did Interleder abandon it? "Staggered timeouts" are a pretty good work around to the issue of non-attacker ending up with full penalty, but the problem can also be solved perfectly, doing so is easy, and a communication about it here is appropriate. What Ryan used in 2006/2008 (and everyone else uses) and what I came up with over past year, the two trivial solutions (both easy to invent) has to be combined.



Peace, Johan

[Jorge Timón]

Please, stop lying. You're a shameless liar. Find someone else dumb enough to want to waste his time with you.

You don't want peqce either, that's just another lie.

One day you say mukti-hop doesn't matter because ripple isn't multi-hop.

Another day you admit you didn't even know the problem to solve is multi-hop, Another day you tell is you have been working for a year in solving multi-hop transactions.

You are a pathetic shameless liar. You lie about yourself, about others, and about others designs which you clearly don't even understand.

You can't be helped.

Please, stop talking to me. You are only wasting your time and humilliating yourself.

Nobody else seems interested in your bullshit anymore. Have fun being ignored, lying clown.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/8bd80a5d-d313-4a46-932d-ce5337fa353bn%40googlegroups.com.

[Johan Nygren]

re: "One day you say mukti-hop doesn't matter because ripple isn't multi-hop.

Another day you admit you didn't even know the problem to solve is multi-hop, Another day you tell is you have been working for a year in solving multi-hop transactions. "

To this community (and not Jorge personally and privately, this is a community group and both me and Jorge interact via it). I worked for a year to build Ripple as no one else had. I came up with a "finish on timeout" approach to payments.



I shared this work on February 21 in this mailing list. The feedback from Ryan and Michiel was "it is not a good solution". I then looked at Ryans solution (the one every multihop payment system uses). It uses "cancel on timeout". The other alternative.



Timeout as a solution to Denial of Service (DoS) always introduces a penalty (it cannot be used without one), but neither the "cancel on timeout" or "finish on timeout" will penalize every DoS vector.

When timeout ends full payment, the penalty is the full payment. The problem with this is well understood and well recognized by most people here. The solution, to do "chunked penalty", was recognized by Ryan in 2006 and by Evgeni and others as well I think, but introducing it tends to mean increasing the duration which credit is locked, which means the timeout in itself (i.e., the parts where the DoS vectors are not financially penalized) no longer works. To be more clear, in Ryan's "cancel on timeout" there is no penalty when doing what Ryan called "commit-ready", and this step is therefore vulnerable to DoS attack when the penalty rate was added (as Ryan added in 2006, see the Sourceforge mailing list here). So, there is a problem (Denial of Service attack) and a solution (timeout) that causes another problem (risk that non-attacker is penalized) that motivates another solution ("chunked penalty") that makes the original solution (timeout) vulnerable to attack again as duration had to increase, so the penalty aspect of the timeout has to be the solution but only one step of the "cancel on timeout" has such a penalty (i.e., "commit" as Ryan called it has penalty but "commit-ready" does not).

The solution is to combine "cancel on timeout" and "finish on timeout". Both alone have the exact same problems. Both alone are easy to come up with. To come up with both requires teamwork. I have listened to feedback from Ryan and Michiel - a form of teamwork - and I have realized how to solve Denial of Service attacks in decentralized multi-hop payments. And I have explained it well. Others are very welcome to try and start a discussion on it here, so we can work as a community to make Ripple Inter Server Protocol happen, and at the same time make Bitcoin Lightning Network, Ethereum Raiden, Interledger, and whatever else, work (as well as allow for systems built on top of either of those such as my Resilience protocol).



Peace, Johan

[Johan Nygren]

To simplify explanation:

In 2-phase commit with timeout, only one phase has a penalty.

To do "chunked penalty" as Ryan suggested in 2006, both steps need a penalty, as the combined timeouts is long time and vulnerable again to DoS attack.

With cancel on timeout, the second phase in 2-phase commit has a penalty.

With finish on timeout, the first phase in 2-phase commit has a penalty.

If finish on timeout is used for the first phase, and cancel on timeout for the second, both two phases have a penalty.

The "commit-ready" (as Ryan called it) then uses finish on timeout, and relies on the buyer cancelling (authenticated with hash lock) unless everyone agrees.

The "commit" step (as Ryan called it) uses cancel on timeout, same as everyone is familiar with. And it is authenticated with hash lock.

Between those, an extra step is needed. To change from "finish on timeout" to "cancel on timeout", and, to avoid buyer cancelling and seller finishing at same time. This step is automatically enforced with penalty as well, thanks to timeout acting opposite ways on outgoing/incoming balance for the node who has received but not propagated this step.

Technically, combining the two 2-phase commits (finish on timeout and cancel on timeout) might make this new thing a 3-phase commit.

Very simple.

There is a big community here around multi-hop backed by different things (trust in Ripple/CMB, bitcoin in Lightning, anything in Interledger), the realization that both possible 2-phase commits (cancel on timeout and finish on timeout) have to be combined into a 3-phase commit to make "chunked penalty" possible is probably the idea that has been missing, and I share it here therefore with all of you as a community. I discovered the idea thanks to trying to meet this community half way. Teamwork. Michiel contributed a lot, at least indirectly.

Peace, Johan

[Johan Nygren]

To use Ryan's design from 2006 with a penalty rate, the two possible 2-phase commits have to be combined. Each alternative only penalizes one phase, but they penalize opposite phases so if they are combined all phases are penalized. The problem Ryan had was that "penalty rate" (daily penalty rate it was often referred to) increases how long a pending payment is open. A quick timeout can prevent DoS but with the slow daily penalty rate the timing-out was not quick, so the penalty was all that could deter DoS but a 2-phase commit alone only has penalty on one phase. The 3-phase commit that combines both 2-phase commits is what is needed. This is what you have all been missing, for any and all decentralized multi-hop payment systems, Ripple, Lightning, Interledger, CMB.

[Johan Nygren]

re: "Another day you admit you didn't even know the problem to solve is multi-hop, Another day you tell is you have been working for a year in solving multi-hop transactions."

Jorge refers to that I said I was ignorant of the "lock credit attack" and mostly considered the network failure aspect.

It is more accurate to say I gave it half attention only

I noticed over the past year that the "finish on timeout" 2-phase commit was a very good solution

Without "chunked penalty", it works

Just like the "cancel on timeout" 2-phase commit also works when "chunked penalty" is not used

When I shared my year long work here, the "cancel on timeout" 2-phase commit group came to critique my "finish on timeout" 2-phase commit (Michiel asked in this email group why I was not using the "cancel on timeout" approach, Ryan said in email it was not a good system and referred to Michiel when explaining why, etc). I decided to demonstrate the "chunked penalty" could be used to resolve the race condition "finish on timeout" has (it has it during "cancel" step). I had already considered "chunked penalty" but never implemented it. When attempting to implement "chunked penalty", I ran into the same problem that Ryan ran into in 2006 with the "cancel on timeout": one of the phases in the 2-phase commit does not have a penalty and there you introduce DoS vulnerability as you add "chunked penalty" (as you increase total time until fully timed out payment...). I then noticed I could "transcend" that problem, by combining both 2-phase commits. I would never have made that realization without the indirect teamwork with all of you who believe in the "cancel on timeout" 2-phase commit.

This is a form of teamwork. But, it needs some community support. One alternative is to marginalize me, label me an idiot and apply all sorts of labels (bipolar, uneducated, rude, nut, liar), stick to the "cancel on timeout" 2-phase commit and form a community agreement that people who attempt the "finish on timeout" 2-phase commit are poorly educated and do not listen. Another alternative, is to grow as a community, and realize the 3-phase commit is needed. That both "sides" (both 2-phase commit attempts) were wrong. That we were all wrong. Jorge was wrong. David was wrong. Michiel was wrong. I was wrong. Ryan was wrong. Evgeni was wrong. And we could work together to build the right solution, the one that combines the two "wrong" ideas.

The 3-phase commit is the missing puzzle piece for all decentralized multi-hop payments. It is easy to see.

I can also say in response to Jorge mentioning plandemic that I never supported the plandemic. My original interest in p2p back in 2011 during my pause from med. school was partly due to how easy genetic engineering is these days, I noticed that already by 2011 (genomecompiler.com had just been launched...) and that social organization had to improve to handle those risks. I would be happy to try and meet half way but I cannot do that if I am marginalized and you form an agreement that it should be how things are, as any attempt at meeting half way by me is then impossible and would be seen as a provocation. So it would be good if people here try and pick up this discussion on the 3-phase commit, so we can all work as a community to make decentralized multihop payments happen.

Peace, Johan