Now gas-per-query in my Ripple/Resilience implementation

[Johan Nygren]

Deters query spam entirely,
https://bitbucket.org/bipedaljoe/proxy-py/commits/f0e1f1cbd451d36148566707f3d29588e7af7c8e

Required changing 3-5 lines of code.

Cost per query such that 65536 queries (can reach 4 billion people in bidirectional search as I use) costs maybe 50 cent.

It hitchhikes on the redistribution mechanism, to build it stand-alone for Ripple just need equivalent (a buffer and triggering sync occasionally).

I suggested the mechanism in 2020, https://groups.google.com/g/rippleusers/c/oXegbIXG5qg. I solved "reserve payment attack" this spring with the 3-phase commit (schematic) from discussion in this group, and have a full Ripple Inter Server Protocol node implementation and a network up and running where anyone could launch a server.

Peace, Johan
def...@johan.to on the Resilience Network

[Johan Nygren]

Gas-per-query now added in stand-alone way (not hitchhiking on redistribution any more).

Now have a direct transfer mechanism used for direct payments, gas, and redistribution. Previously, direct payments used the multi-hop mechanism (and before that briefly, their own).

https://bitbucket.org/bipedaljoe/proxy-py/commits/8aeedce600680cc87f1cf80f7f2c704ce7c48a5a

I assume most people here think query flooding the network is not scalable. With bidirectional search that is incremental (think ping-pong, each increments depth one, then on first path recurse tells the other to increment depth one, and so on), number of queries is sqrt(unidirectional). This is not the same as Gnutella or communication networks that search from one direction. It is 1000 queries (2000...) instead of a million.

With the gas-per-query, it can be prohibitively expensive to spam the network. Very easy mechanism to add.

I will be testing in following days to make sure there are no bugs in it. Note that "reserve payment attack" has been solved, Ryan had the right idea in 2006 with "gradual penalty" and I realized how to achieve it: you need a penalty on all phases (since cumulative timeout gets very long with "gradual penalty" approach), and no 2-phase commit has that (neither "cancel-on-timeout" or "finish-on-timeout").

So Ripple Inter Server Protocol has been created. It now has gas-per-query to fix the query spam issue. And it has guaranteed basic income via voluntary tax (funded similar to routing fees...) built-in, as I invented in 2012: the Resilience protocol.

Hakuna matata
Johan

[Johan Nygren]

Have tested the gas-per-query system for the past days, the code looks good. There were some minor bugs (as expected) that have been fixed.

To give some numbers for why query flooding will not break the network: a single path finding message is 200 byte. If each person does a hundred payments a day and queries 1000 nodes on average each (reaching equivalent of a million queries in unidirectional) that is 20 mb (and since bidirectional, 40 mb). This is nothing. Even if it was 100 worst case scenario payments of 10^5 queried (reaching 10^10 people, 10 billion, in bidirectional search), it is 40 gb and still not going to break the internet in the future. Average person uses 5 gb of data on net already, and in a few years handling 50 gb per person is nothing (and this is an extreme upper bound, 50 mb per person much more realistic and still extremely high bound, and that is just 1% of what a person already uses today on average). No one will do 100 x 10^5 queries I just demonstrate that even that will likely be scalable 10 years from now. And the gas-per-query ensures the search cannot be attacked.

I know many here are skeptical of query flooding but maybe it actually does scale well. The bandwidth in Ripple is not a constant, so keeping memory of routes is not as rewarding as for normal internet. It can still be added on in the future but even without it, it seems it would scale. Today people use absurd amounts of data anyway already, unlike in 2003.

The codebase and a pretty good README: https://bitbucket.org/bipedaljoe/proxy-py. Articles and videos (and code) on https://resilience.me.

Peace,
Johan

[Evgeni Pandurski]

Can you explain how the "gas" thing works? It seems to me that this is the next BIG blocker. (I will assume that you are correct, and the scalability of queries is a solvable problem, although as you pointed out, I have some doughts.)

--
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/f5b8a89f-4b17-4d5a-84cc-53c1a50d2dc8n%40googlegroups.com.

[Johan Nygren]

re: "Can you explain how the "gas" thing works?"

Gladly! I search for paths by incrementing the depth with 1, and returning to the root (buyer or seller) in between. The buyer/seller has to renew the search with 1 depth increase each time (I also search from both directions). This means the buyer/seller can estimate how many nodes they have queries at a given depth, by using an average branching factor per node. They supply this as "gas" (the normal currency but in very small amounts), and simplest is to use 1 currency base unit per query. I use branching factor 16, but anyone can set their own. Each hop will forward the search request in proportion to "gas" paid (if 16 gas was paid per depth increment, so, 16^depth at any depth, a node would only forward to up to 16 nodes). This is all done in the forward_find_path function here. The "gas" is stored in a buffer (here in codebase) and sent as bulk payments infrequently, currently once per hour, was a reasonable way to do it. If someone cheats their friend, their friend ends up paying out gas while not getting it in.

Very happy you reply! I scale the currency right now so that smallest "user facing unit" is 1000 of the base unit, and then two decimal points on top of that to the "main unit", so that 1 RES is 100000 base units which is the "gas" that you need in the worst case scenario where you are the most distant from someone else in terms of trust in a network of 10 billion people. The Ripple network in the future probably being everyone in the world.

Also, one query is closer to 600-1000 byte, 1 kb at the very most (FIND_PATH, ACK, PATH_RECURSE, ACK, plus a few percent needing retransmission). Not 200 byte. I was wrong, but it is still not too much data and the "gas" can scale to similar cost as the data transfer and then congestion and attacks manages itself.

Hakuna matata, Johan

[Evgeni Pandurski]

Your explanation supposes that I have much more context that I
actually do. Or it supposes that I am willing to dive deep into
your code. I think your explanations generally have this problem.

I want to share a thought that I had, which may be useful:

I believe that all path-finding algorithms that were entertained
for Ripple to some extent rely on the [six degree of
separation](https://en.wikipedia.org/wiki/Six_degrees_of_separation)
effect (the "small word" effect). I think, in the real-world this
will not be true.

I think the misunderstanding comes from the fact that Ripplers
generally imagine a graph that consists of bi-directional links
(both nodes are willing both to sell and buy). In practice. this
can not be the case for a long period of time, because
opportunistic nodes will quickly "consume" this resource in order
to optimize their own credit-risk exposure. The result is that
almost always the graph will consists of uni-directional arcs (a
directed graph).

Finding paths in a directed graph is an O(n) operation. I have
implemented this for Swaptacular, and have run some simulations
with lots (millions) of nodes. It is fast enough when it runs on a
PC, but running it distributed at scale is pretty much impossible,
I believe. Even if you ignore the network latency, the problem is
that the paths *frequently* contain thousands of nodes. If even
one of the nodes in the path is temporarily down, the path will
not be found -- and how the distributed algorithm would recover
from those cases, without doing too much redundant work?

Note: I would be really interested if you refer me to a good
parallelizable algorithm for finding cycles in directed graphs. I
have not found a good one yet -- a one that is not much worse that
O(n), and do not require very fast shared memory. That is: It
should run on multiple servers in parallel, and give significant
improvements compared to the well-known single-threaded algorithm.
(It seems that the single-threaded algorithm might not be fast
enough, for my use case, when the number of users reaches the
order of billions.)

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

[Evgeni Pandurski]

One important clarification: The initially undirected graph, will
not only quickly become a directed graph (the process is driven by
opportunistic nodes), but almost all of the existing cycles in the
directed graph will be "consumed" (again driven by opportunistic
nodes). The end result is that the path-finding algorithm will
need to work with directed graph containing *almost no cycles* --
and those graphs are very far from the "six degree of
separations"/"small world" dream.

[Johan Nygren]

Your system is multilateral clearing, it has different context and problems. In Ripple path-finding is not limited to IOU-paths, it is also the credit limits. Like Jorge wrote multilateral clearing is just one special case of Ripple.

[Evgeni Pandurski]

My claim is that the long-term dynamics in the Ripple network will inevitably result in a directed graph with almost no cycles. Effectively reducing the network to a multilateral clearing system (I prefer the term "credit exposure optimization", because it is not always clearing what the nodes want).

The only way out of this dynamics is to introduce *proportional* taxes on each hop. This makes the graph a weighted graph, and makes the path finding algorithm much more complex, O(n*n) if I remember correctly.

The problem with introducing taxes is that it renders the path finding into a path-manipulating war, in which nodes are motivated to be uncooperative. Ultimately, the result is the sort of banking system that we all know and love.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/1a552c9f-f057-45da-8406-baac44658ff3n%40googlegroups.com.

[Johan Nygren]

Multilateral clearing is a special case in Ripple, RipplePay never used it as I understand nor Ripple.com as I understand and I have not added it either (but swarm redistribution achieves similar effect, an effect very similar to "chunked clearing" that Michiel de Jong uses in LedgerLoops). I have been interested in Ripple since 2012 and I think it is ingenious (and now I agree "collateral" on top of the trustlines, Lightning/Raiden network and Interledger, is "just Ripple" in a sense). I am interested in Ripple because it is a web-of-trust and not a community (hierarchy), I am not very interested in "federated community banks with multilateral clearing".

I use penalty fees and tax. Both are agreed by buyer and intermediaries, buyer says what they pay, anyone who accepts (above their minimum) will participate in path finding. First path found wins. It adds almost no complexity if done that way. People have a reason to want a penalty fee that is not too low (otherwise buyer can attack) and an honest buyer has nothing to loose by setting a good penalty fee (they pay nothing if they do not attack). And the tax in Resilience, same there, buyer who pays tax is assumed to be in favor of the voluntary redistribution mechanism. If they are not, they would not pay, and choose paths available where no tax is demanded. Adds no complexity (does limit possible paths for those paying low or no tax but otherwise adds no complexity to the path finding, a single path always found, first wins).

It is all very straight forward. I built it all in 2400 lines of code with zero dependencies (scheduler, transport layer, hash function, all built-in). In 2400 lines of code, a global money system + basic income. Very easy for anyone to audit and overview all of it. A hash function a concept anyone can understand.  No unnecessary added complexity. It has the "gradual penalty" Ryan suggested in 2006 (possible with the 3-phase commit) and it has gas-per-query so path finding attacks are no problem. And I provide a layer on top for user friendliness for those who want that. It is all complete. The hypotheticals 20 years ago, such as "reserve payment attack", are now solved (of course multilateral clearing you solved that with "chunked clearing" as Michiel de Jong uses and that is very smart but I am interested in Ripple and this is the Ripple group).

Johan
https://resilience.me

[Evgeni Pandurski]

Fair enough. No point in arguing about people's values and believes.

The most important point I want to reiterate is that putting simple systems in a network often result in very complex and surprising global dynamics. We all are not smart enough to predict all of the effects, and most often we choose to not to think about them, so as not to invalidate our values and believes. I also do not absolve myself or this weakness.

To view this discussion visit https://groups.google.com/d/msgid/rippleusers/20574716-29da-41b8-bc0c-64c1581e679bn%40googlegroups.com.

[Johan Nygren]

This is a group around Ripple, a simple system in a network that results in very complex and global dynamics.

I have very listened to concerns others have about it, such as the "reserve payment attack", and I managed to solve how to get the idea you and Ryan discussed in 2006 - "gradual penalty" - to work, with a 3-phase commit.

This is fantastic. I presented the 3-phase commit in Austria with Michiel de Jong, https://youtu.be/DVjMis02AE8, and my schematic is very good explanation of it too (here).

The "reserve payment attack" is not a problem in "multilateral clearing" (and there "chunked clearing" works perfectly well as Michiel de Jong uses in LedgerLoops) but this is a group about Ripple, not multilateral clearing. I don't entirely understand if you also originally had the same idea as Ripple (as it states on the old website) or if your idea was always just the multilateral clearing, it seems like you were both discussing similar goals back 20 years ago but today it does not seem so.

I'm not ignorant about weaknesses or problems, but it seems you are not focused on multihop payments and you bring up path finding issues in multilateral clearing context (where only path is IOU-debt-lines) that are not the same problems as in multihop payment system. An alternative to "we are not smart enough to build Ripple Inter Server Protocol" is that maybe we are? Maybe the people here, Ryan mainly but also others, did the foundational work (most of the work), I managed to add the 3-phase commit (and gas-per-query) and it is now a working system that actually scales and is actually real. The real barrier - the one this community have pointed at for 20 years, the "reserve payment attack" - has been overcome. This is fantastic, a first in 20 years, isn't it? There is now a true implementation (code) that does a true decentralized Ripple in just 2500 lines of code with zero dependencies. It works perfectly well, and there is a user friendly layer on top of it.

Johan

[Evgeni Pandurski]

I gave my arguments in an a mail I wrote here a few month ago,
which I will repeat at the end of this mail.

To summarize my position, I think in the era of Internet,
multi-hop payments make sense only if they include exchanges
between different currencies. And exchanges between different
currencies is a very complex game-theory problem which is
essentially unsolvable.

The problem is unsolvable, because it includes power dynamics
which if you attempt to formalize will inevitably force the most
powerful players in the game to opt out of your game/system, and
join another game/system whose formal rules are more beneficial to
them. As time passes, a another sub-group of players will become
dominant in the game, and they will opt out of the game, or change
the rules of the game so as the new game benefits them more.

The point is: If you design *a power-game* which do not benefit
the dominant group of players, the dominant group of players will
simply not play your game. Therefore: *Do not try to design a
power game.*

The crux of the matter is: Recognize that you are dealing with a
power-struggle game, and not with a technical problem. Instead,
try to find a *real technical problem* that you can solve.

-------------------------------------------
(I wrote this on 2025-05-18 in response to your mail):

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?

[Johan Nygren]

I think Ripple is a real goal, and that the technical challenges around it that people here worked on 20 years are real technical problems.

I have never been interested in exchange rates at every hop. To me, a global web-of-trust currency makes most sense. To me I see no problem with it.

For starters the value scales pretty well off the path finding attack "gas-per-query". I made the cost of one query the base unit. Since path finding attacks on the network each globally, it is reasonable people will tend to agree on similar cost for such attack, and then you automatically have a global singular currency. Gas-per-query in the code here.

I have a complete implementation in 2500 lines of code with zero dependencies, it is very good, works very well, it also demonstrates 3-phase commit for Lightning/Raiden network and Interledger. It is very easy to build implementations, I built most of one in Rust here (complete but have not tested it as I prefer the one I already have) and something like that is a good priority if people do not like my manual transport protocol (I think mine is better though), should be very easy to build an implementation most people can like and agree on, or maybe people actually like the one I already built. But you do not seem to have Ripple as the goal, and I am not sure if you had 20 years ago, it stated on the old website you did (that you invented it independently alongside Ryan) but it does not seem to be your goal today.

Hakuna matata
Johan

[Evgeni Pandurski]

Yes, at some point in the past I realized that Ripple is more an
Utopian dream of social harmony than a technical problem.
Obviously, you will disagree with this.

I realized that the real technical problems are:

1. Allowing ordinary people to easily issue their own debt-based
currencies. (I claim that all practical currencies outside of the
formalized game that the dominant group in the society plays, must
be debt-based currencies.)

2. Searching and finding Pareto optimal multilateral credit
exposures in a graph of gazillion of debt-based currencies.
https://en.wikipedia.org/wiki/Pareto_efficiency

I might be wrong, but these are my conclusions.

PS: I think you should make your mind whether your particular
Ripple system, will trade with different currencies or with just
one. The way I see it, you think of it as one currency, but really
each node issues it own currency, and you are forcing on them 1:1
exchange rate + some gas fee, which is kind exactly the kind of
wrong formalization of the rules that may drive people out of the
game, or more likely force people tho change the rule of the game,
again and again, ad infinum.

[Johan Nygren]

I may have misunderstood. Ryan mentioned in an interview someone who invented Ripple independently at same time as him. Your CMB is also on the old website under "Ripple Sites" as the only other besides Ripple. Was your CMB multilateral clearing with community banks and not multi-hop between the banks, or was it like Ripple? If it was not like Ripple, why is it mentioned as "independently operated as a separate Ripple network".

The problems you bring up ("path-finding when only searching via debt-lines and not credit limits") are not Ripple problems, they are "multilateral clearing" problems. The problems that assume everyone has their own exchange rate, Ripple was never defined as that. It said it does not exclude the possibility ("there can be many currencies") but not necessarily there has to be. I was never interested in exchange rates at every hop. You seem to have based CMB on the idea, there it makes more sense as a "community bank" is a little world of its own, and the "network" is an after-thought. The reason innovation on network-payments happened with Ripple (from work you did with Ryan in 2000s...) is because without the network, Ripple is meaningless, whereas CMB is not. CMB without the network is still like a LETS, and there is plenty of people who believe in those (to me they are just the same as a bank, I am interested in web-of-trust money not community money).

A full implementation of Ripple Inter Server Protocol is on https://bitbucket.org/bipedaljoe/proxy-py, the 3-phase commit solves "reserve payment attack" by making Ryan's "gradual penalty" idea from 2006 possible, the gas-per-query solves path-finding attacks, bidirectional path finding makes path finding cheap, and it also does swarm redistribution...

Hakuna matata
Johan

[Evgeni Pandurski]

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

> I may have misunderstood. Ryan mentioned in an interview someone
> who invented Ripple independently at same time as him. Your CMB
> is also on the
> old website under "Ripple Sites" as the only other besides
> Ripple. Was your CMB multilateral clearing with community banks
> and not multi-hop between
> the banks, or was it like Ripple? If it was not like Ripple, why
> is it mentioned as "independently operated as a separate Ripple
> network".

I guess Ryan was talking about CMB, although CMB did not have
multi-hop payments. I think pretty early I changed my focus on
*cycles*, while Ryan was focused on multi-hop. At the time I
realized that if you can find a multi-hop path between every 2
nodes on demand, you will be able to find at least one cycle that
includes any node you pick. This ment that as long as the
multi-hop thing works, people will be able to automatically
optimize their credit exposure, and the moment everybody has
optimized their exposure -- the multi-hop thing will cease to
work.

So it was obvious to me that the two things (optimal credit
exposure, and multi-hop payments) were mutually exclusive. And
because optimizing your own credit exposure is the selfish thing
to do, the natural equilibrium of the system would necessarily be:
Pareto-optimal credit exposures, and no free multi-hop payments.

You may device a system that manages to stay somewhere in-between,
for example by making payments expensive enough, so that a lot of
available paths will just stay alive, waiting for somebody willing
to pay for them. But this seems quite artificial to me.

In any case, I do not deny that the ability to make multi-hop
exchanges between multiple currencies is a great thing. I do not
have a solution for this, and I believe there is no universal
solution, because this is inherently a power-struggle game. If you
figure a solution that is better than the already existing ones
(currency exchanges) -- I am all for it. But I think this is a
very hard problem.

[Johan Nygren]

You say "I think pretty early I changed my focus on *cycles*" but were you originally focused on a multi-hop system and then you changed your focus to multilateral credit, or were you originally focused on multilateral credit, and then you found Ryan and Ripple, and you got a bit interested in it (you were very involved from what I see on Sourceforge forum) but then you want back to your original idea?

It sounds like your own idea and project was multilateral credit, then you joined Ryan and his multi-hop vision, then you went back to your own idea. But I believe in Ripple and the problems you bring up here, when I share that I have solved the barriers that other ran into, are multilateral clearing problems. In CMB exchange rates make sense because the community banks are their own world. But in Ripple, they do not. The balance assumes 1:1 "exchange rate", this is how RipplePay was built, Ripple.com (and my implementation now), how it was defined in all the whitepapers and everything else for 20 years. If every "edge" is an account with a singular balance that can be positive and negative and the exchange rate by definition 1:1 - where is the "exchange rate" supposed to be? Sure there can be many currencies, but I have never assumed that is the equilibrium, do not see why it would be. Your claim "each node issues it own currency, and you are forcing on them 1:1 exchange rate" makes no sense with how balance work in a user-to-user account in Ripple, it has always been "1:1". It makes sense with banks ("community banks") but not when the bank is reduced to one-person-one-bank, it then stops making sense and different rules kick in, from what I see. And that path-finding-per-hop-fee as a base unit fits perfectly with that as the whole network has the same attack problem, attacks can reach the whole network so everyone is in the same boat.

A full implementation of Ripple Inter Server Protocol is on https://bitbucket.org/bipedaljoe/proxy-py.

Hakuna matata
Johan

[Evgeni Pandurski]

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

> You say "I think pretty early I changed my focus on *cycles*"
> but were you originally focused on a multi-hop system and then
> you changed your focus to
> multilateral credit, or were you originally focused on
> multilateral credit, and then you found Ryan and Ripple, and you
> got a bit interested in it (you were
> very involved from what I see on Sourceforge forum) but then you
> want back to your original idea?

My journey to understand how money works started some time before
I found out about Ripple. At that time I had some multilateral
exchange ideas already developed. It was very exciting for me to
find people (Ryan) that were thinking and working on similar
ideas.

Community banks and LETS system were quite popular back then, and
I saw them as the main group of people that might be interested in
applying my ideas in practice (using CMB).

I will try to list several misconception that plague the
understanding of people so as to how money works. They are based
mainly on unconscious cultural believes, so they are very hard to
"undo":

1. Because individualism is the pervasive cultural norm,
money/credit issuing must be done mainly by individuals (like in
Ripple). This is wrong. We are social animals and the most
reliable issuers of money/credit are big organizations which have
large social support. Luckily, technically it does not matter much
-- the same software mostly works both for individuals and
organizations.

2. Because we mostly live in a mono-currency economy, we believe
that this is economically the most efficient way, but the truth is
exactly the opposite. I would expect many Bitcoin enthusiasts and
gold bugs to be in this camp. The mono-currency basically
represents the game that the dominant power groups in the society
have decided to play to get richer, and richer. Buy they do this
mostly on the expense of others. Schemes like Bitcoin, the US
Dollar, the Euro, the gold market, tend to economically stifle
everybody outside the "ring of power", and they inevitably
collapse when the power-groups shift their attention to other,
"better" games.

3. Because banks do not want people to know how banking works,
people believe that the money they have in the bank are issued by
the central bank of the state, and therefore, all money in banks
are the same money. No! Every bank issues its own money (that is:
their own digital currency), which is pegged to a currency called
"bank reserves", which is issued by the central bank, which is
controlled by the dominant elite. It seems that misconception is
the source of the confusion about the accounts that different
nodes in Ripple maintain -- they really are different currencies,
pegged to one well-known currency. The illusion that these
different currencies really are the same currency holds only as
long as exchanges between those currencies are easy and mostly
free (that is: the multi-hop payments work reliably). Obviously
this is a vicious cycle -- once the trust is gone, everything
collapses.

4. Because in the west people had 200 years of more or less
constant financial expansion and economic growth, we believe that
monetary systems are stable. This is not true. Unless you were
part of the western financial empire, in almost every country, on
average, every 30-70 years the monetary system collapses, and
everything starts from scratch.

My point is that monetary systems are really hard to understand!
Everybody, including me, started their journey into this being
completely naive. CMB was an experiment from which I have learned
a lot. I guess Ryan has learned a lot from working on Ripple too.
I am sure you will also.

[Johan Nygren]

But CMB and Ripple are not very similar ideas, they are similar in that they were "alternative" but they are not very similar.

The user-to-user account by definition has no exchange rate, it is a singular balance that goes positive and negative. The user-to-user account is like a LETS with two members. A mutual currency is not two currencies. There is no exchange rate.

My goal is Ripple network with swarm redistribution. If that was once your goal too but you left it, the goal is here if you want to return. Path-finding attacks affects the whole global network equally, thus the base unit naturally gains a globally recognized value. I'm happy that you responded and thank you for the work you and Ryan did in laying the foundation for it all, the "gradual penalty" ideas you developed and everything else. If you want to build Ripple again I hope we can work together. My custom transport protocol and "roll your own" MAC might seem like making things harder than they have to be but I think it might be easier. Works like clockwork. Easy to build it all with transistors from scratch.

Johan 
https://resilience.me