DDRS - Network Mechanisms for a Distributed Reserve System in Ripple

[David Watson]

Man, it sure has been quiet around here lately. : )

Anywho, here's some fresh meat for you. And this time I got
PICTURES!!! Woo hoo!

--------------------------------------

Decentralized Reserve Ripple System (DRRS) .... or something.

I've been wrestling with this concept of using Ripple (or Ripple with
minor tweaking) for my idea for a reserve based currency. Was
wondering if anyone could give me some feedback.

The diagrams I'm referring to are posted on the RippleUsers Group, and
are prefixed with "DDRS" (Decentralized Reserve Ripple System).

Basically I'm trying to show that a completely decentralized currency
system is possible. Now people on the RippleUsers Group know this is
doable, I know, but I'm trying to show how a 'reserve-based' system
could work as well. Having a reserve based system that is
decentralized in the manner I'm describing virtually eliminates any
risk involved. When I say 'decentralized' I primarily mean 'legally'
decentralized and logically decentralized. Decentralizing the
software implementation is beyond the scope of what I'm trying to
demonstrate at the moment, though I don't see any theoretical
obstacles in that regard.

I'm going to break this into parts for anyone who has questions
because I know how hard it is even for me to understand what I'm
trying to explain to myself when it comes to Ripple and graph theory,
so if you have questions, try to include which Part you are referring
to.

PART I - Basic Idea

Instead of user Ripple nodes being directly connected to each other
they can be connected to groups. Groups each have a defined amount of
'value' that the group represents. Users will be members of multiple
groups. When payments occur it changes the relative values between
the members of groups in one or more of those groups.

PART II - Basic Group Arrangement

*(See DRRS_Reserve_Node_Group_Diagram.jpg for this section)

There are three types of nodes in the system; Reserve Nodes(R),
Terminal Nodes(T), and Connector Nodes(C). Every person or identity
belongs to one or more Reserve Node groups. A Reserve Node group is
just like a LETSystem setup only with a fixed amount of credit based
on whatever value the group is trying to represent, be it a commodity
or some kind of fixed asset. Each member of the Reserve Node group is
represented by a Terminal Node that is connected to the Reserve Node.
All the Terminal Nodes (except the property/asset owning node) extend
credit to the Reserve Node up to the entire amount of the reserves.
The Reserve Node only extends credit to whichever Terminal Node was
the legal owner of the reserve assets. In this way, the entire value
represented by the Reserve Node group can flow freely between all
members of the group, even though one or more parties essentially has
full control within that group initially.

PART III - The Connector Node

*(See DRRS_Connector_Node_diagram.jpg for this section)
*(See DRRS_Basic_C-T-R_Diagram.jpg for this section)

The Connector Node is the node that connects together all of an
individual identities Terminal Nodes. If Bob belongs to 3 Reserve
Node groups his connector node will connect to his three Terminal
Nodes, which in turn connect to their respective Reserve Nodes. The
credit relationships then are as follows: Connector Node extends
unlimited credit to Terminal Nodes. Terminal Nodes extend unlimited
credit to Connector Node. Terminal Nodes extend credit to Reserve
Nodes up to the total value of that Reserve Node group (Except the
property/asset owning node). Reserve Nodes extend credit based on the
share of the value the Terminal Node currently has a claim on.

PART IV - Making Payments

*(See DRRS_Payment_Chain_Diagram.jpg for this section)

Payments originate from a users Connector Node and resolve on the
receivers Connector Node. Now if you've studied how Ripple works for
a while you might realize that having the Connector Node in the middle
of all the Terminal Nodes and also giving it unlimited credit makes it
a dummy node, because you could simply use one Terminal Node and
connect it to all the Reserve Nodes. Since Ripple treats every
connection like a separate account, and the Reserve Nodes bottle-neck
the payment resolution anyway, having unlimited credit in both
directions between the Connector Node and the Terminal Nodes doesn't
provide any benefit. This was done deliberately, however, and not for
simply organizational or aesthetic reasons as I explain later. For
now, just realize that in Ripple, the separate Terminal Nodes would
essentially be separate user accounts, and so would the Connector
Node.

PART V - Some Observations

Since its a reserve-based system, the Terminal Nodes will always have
a zero, or net-positive balance. The Reserve Nodes will always have a
net-zero balance. The Connector Node could have a net-positive, zero,
or net-negative balance.

PART VI - User Centric Nature of Ripple

What we're really trying to achieve with decentralization in money is
decentralization of power more than anything else. Not to make
everyone weak, but to make everyone equally strong. In the current
system (the way money works now) all the regular people (leaf nodes)
have basically no power and the one's closer to the center are
privileged by easy and pre-inflated money. Objective then is to
decentralize the power of issuance while sacrificing universality of
money as little as possible, ideally making it more universal.

In this reserve-based system, rather than connecting directly with
friends, you join groups that your friends are in, or invite friends
to groups you are in. This doesn't limit the connection possibilities
Ripple allows/offers it just changes the nature of the default type of
connection.

So a user has the freedom to connect with different groups, form his
own group or connect directly to other Ripple Users if he wants (My
diagrams and explanations only deal with reserve-based group
connections, however). If he's part of a group that he doesn't like,
he can phase out his participation by dropping the credit limit
offered to the reserve node, without feeling that he's abandoning any
specific friend. But one problem still remains. The user has no real
control over the relative values stored in the terminal node. Perhaps
the user would like them all to be evenly balanced, or would like a
larger percentage of his value stored in one group rather than another
when possible. You can do it passively by dropping the credit limit
in one or more terminal nodes but there's another more active way.

Part VI - The Disconnected Node Mechanism

*(See DDRS_Disconnected_Nodes.jpg for this section)

Instead of merely altering credit limits and letting the pace of
transactions determine relative connection values, we can alter the
relative values directly. Since all Terminal Nodes go through the
Connector Node we can disconnect the Terminal Node of our choosing and
make a payment towards it via an alternate Terminal Node. This allows
us a mechanism to change the State of the network arbitrarily, or at
least exert force on the network arbitrarily as we can never be
certain the payments will resolve precisely as we want them to.

Part VII - Conclusion

There were a few mental blocks I was struggling with trying to imagine
a way to implement Ripple with a reserve-based currency. One thing
was who would be the issuer. I didn't like the idea of just simply
having 'trusted' people act as hubs for everyone. I see the use of
"Reserve Groups" as kind of a cooperative intermediary much more
ideal.

Second problem was how to allow large amounts of money to travel
through the system. Originally I saw this as a huge problem and kept
trying to devise clever ways to nodes that weren't highly networked to
receive excess money by fudging with the credit limits, and making
them in excess of the actual value of the group node. Now I'm not
really sure it is even a problem. The main bottleneck is on the
receiver side. If he wants to receive more he needs to be part of
more groups or more valuable groups. Basically, spread out more. The
person trying to pay large amounts already has the value and is likely
already spread out. My theory on what will eventually happen, is that
the network will tend to push those who transact in large amounts
together, leaving the more conservative users kind of in the 'suburbs'
of the network as far as network density goes.

Third big problem was the issue of not having control of relative
connection values. If I wanted more in this group and less in this
group there should be a more active way than lowering your credit
limit in one or the other. That's when I came across the idea of
having a Connector Node between all the Terminal Nodes allowing the
user to actively manipulate relative values.

Part VIII - Next Steps

Next steps are to try to find weaknesses in the idea, and to figure
out ways to simulate a user base and conduct transactions. The
problem with finding weaknesses in the idea, aside from doing actual
computational tests, is that it is very difficult to imagine all the
things that happen that affect the network. Imagination is very
powerful but the more complex and computational the scenario, the more
likely you are to make mistakes and false assumptions.

Apart from continuing to try to find inherent weaknesses and coming up
with ways to test a simulated version of the system, I don't see any
major obstacles at the moment to implementing it. So I'm all ears if
anyone has any input or advice for future direction.

Part VIII - Future Ideas

Not only am I looking at land as the ideal currency, as many of you
read in my "Money as Rent" thread, I actually think there's a very
powerful tool to spawn a system like this using a type of altruistic-
gifting metric. I found a paper recently over at altruists.org that
discusses the roots of economic systems being gift economies initially
and then evolving into market economies. You can find it on the site
in the download sections. The authors I'm referring to are Theo van
de Klundert & Jeroen van de Ven. They do a very good job of
explaining not only the intuitive relationship between the gift and
market economy, but they actually present a mathematical theory
linking the two. I was kind of struck when I read the paper, because
back in April I was thinking something eerily similar only I had
become too myopic and was thinking only in terms of the gift economy.
Probably a reactionary behavior related to how the rest of the world
seems to only see the market economy.

----------------------------------------------------------------------------------------------------------

Part IX - A Note about Theory

One problem with computational systems like Ripple is that many people
don't even look at economics and money as a rule based system. They
think economics and money are mathematical equations or theories that
have already been solved and that we already have the basics down, and
if a better system was possible someone would have figured it by now.
But this is very far from the truth. Stephen Wolfram makes a lot of
excellent points in his book A New Kind of Science (NKS) about this
very thing. It's free online if you want to give it a lookesy. There
are lots of processes in nature and especially in the world of
programming that are rule based and produce very complex results that
have "numerical qualities" but aren't reducible to some 'set' of
mathematical theories. There's a significant number of NKS computer
people around the internets that were inspired by Wolfram's work.
They may be an excellent resource to help out with this kind of work
in the future.

Anyway, I don't want to bore you to death with philosophical mumbo
jumbo, point is that it seems one of the major hurdles to getting
people to see a 'new system' is they have trouble even believing that
such a thing is possible. People can't easily imagine a world where
there are no banks, and no central authority is controlling the money
system. So they pick the idea apart by thinking that the current
system is a 'natural' system, and the new system won't work becomes it
doesn't have this property or that property. So rather than looking
at what the benefits and drawbacks would be compared to the current
system, they deny the possibility of the new system altogether.

Anywho, that's all for now.

If anyone's wondering I generated the diagrams using Cumulative Draw.
It's a free web-based diagramming tool. Pretty rad, I'm hooked. If
you're a cheapy like me anyway, and don't like paying for, or
installing things

[David Watson]

I kept accidentally using DDRS instead of DRRS in the above post.
It's not important, it's just a meaningless temporary acronymn I made
up. Main purpose was so that the thread was prefixed the same way as
the files I uploaded so that they'd be easy to spot.

[matabele]

I like the reserve group idea - it is a simple way of distributing
risk.

In essence, all that is necessary:
- a special account is set up by a group of users, to which each user
extends limits on credit for the purposes of routing via the group.
- all routing takes place via reserve groups rather than via
individual accounts.

This would also facilitate routing.

Ripple can already be used in this way - a cc is set up for a local
community. A separate reserve group account is set up within the cc
which is linked to a single Ripple node. Perhaps it would be more
convenient if Ripple provided the entire mechanism.

> ...
>
> read more »

[David Watson]

On Jan 26, 10:18 pm, matabele <matabele.b...@gmail.com> wrote:
> I like the reserve group idea - it is a simple way of distributing
> risk.

Well, for the way I envision it its more about collateralizing risk.
But there is some risk distribution in the sense that you'd feel more
comfortable joining a group than connecting directly a peer. Doesn't
limit to just groups though. Kind of like mingling in the group
first, then maybe connecting directly. I envision the 'groups' as
more than just some arbitrary connection though.

> In essence, all that is necessary:
> - a special account is set up by a group of users, to which each user
> extends limits on credit for the purposes of routing via the group.
> - all routing takes place via reserve groups rather than via
> individual accounts.

Essentially.

>
> This would also facilitate routing.

I kind of feel like I'm hitting up against the same wall the Ryan's
been chipping away at now. How would the routing work between
hosts.

>
> Ripple can already be used in this way - a cc is set up for a local
> community. A separate reserve group account is set up within the cc
> which is linked to a single Ripple node. Perhaps it would be more
> convenient if Ripple provided the entire mechanism.

Yeah, everything I described can be done in Ripple as is.

> ...
>
> read more »

[Miles Thompson]

I've been thinking a lot about a scenario in which a community currency  *is* essentially a default pool coupled with a routing mechanism - essentially the community currency is a special type of node in the ripple pay network that (a) has lots of incoming and outgoing links and (b) that pays and/or gains debts by issuing and receiving its own scrip (c) that 'trusts' other people based on an algorithmic examination of how those people are trusted by others within the ripple network

or something. i hope to explore it more coherently soon  but thought I'd get this out there as random thoughts.

miles

[matabele]

It appears to me that routing via a reserve group, representing a
community, is easier than routing via an individual member of a group.

The required trust relationships are also more easily specified, as a
user need specify only the amount of trust to be extended to the
reserve group for routing (which should be common to that group - so
that the risk is evenly spread).

On Jan 27, 5:27 pm, Miles Thompson <utu...@gmail.com> wrote:
> I've been thinking a lot about a scenario in which a community currency
> *is* essentially a default pool coupled with a routing mechanism -
> essentially the community currency is a special type of node in the ripple
> pay network that (a) has lots of incoming and outgoing links and (b) that
> pays and/or gains debts by issuing and receiving its own scrip (c) that
> 'trusts' other people based on an algorithmic examination of how those
> people are trusted by others within the ripple network
>
> or something. i hope to explore it more coherently soon  but thought I'd get
> this out there as random thoughts.
>
> miles
>

> ...
>
> read more »