Implementing Ripple using OpenTransact
John Paul Lewicke
Pelle Braendgaard's new OpenTransact peer-to-peer payment system --
http://www.opentransact.org/ . For those who may not be familiar with
it, OpenTransact is a very simple payment system built using OAuth (an
authorization/delegation API). Pelle has some typical use cases at
http://www.opentransact.org/usecases.html , and I think there are
several reasons why it should be relatively easy to implement Ripple
using it.
1. Authorization is built in. If someone wants to trade 40 Berkshares
for at least 60 Twollars, using OAuth allows the Ripple exchange node
to verify with the Berkshares website that that person has a valid
account and can prevent the person from transferring those Berkshares
somewhere else while the trade is in progress.
2. OpenTransact handles units of account in a very flexible and
sensible manner. Each unit of account is represented by a URL,
leaving the details of each currency, loan system, equity holding,
commodity, etc. up to individual asset trackers. An asset tracker is
simply a website that tracks ownership of some unit of account, and
that records transfers between individuals. The asset tracker for a
gold fund could be www.gold.com/transactions, while a Ripple-style P2P
loan site could be loans.com/jplewicke/usd .
3. OpenTransact transactions are very simple. They are instructions
for an asset tracker to transfer ownership of a certain quantity of a
given unit of account from the current owner to a new owner.
Pelle has some good descriptions of OpenTransact at
http://wiki.github.com/opentransact/opentransact/ ,
http://www.opentransact.org/ , his blog http://stakeventures.com/ ,
and the agile-banking google group
http://groups.google.com/group/agile-banking . I'm going to describe
now how I think the "distributed system of exchange" part of Ripple
could be implemented in OpenTransact. I'm going to concentrate on
this from the viewpoint of a single Ripple node that mediates between
several units of account (e.g. asset trackers like banks, gold vaults,
and peer loans).
People who wanted to exchange two units of account would submit a bid
to the Ripple server in the following form:
{from-currency, to-currency, max-amount, minimum-exchange-rate}
- from-currency would be the URL for the asset tracker in which they
already possess at least max-amount assets. The OAuth authorization
negotiations would allow the Ripple node to confirm that this user is
authorized to trade such-and-such an amount.
- to-currency would be the URL for the asset that they would like to receive.
- minimum-exchange-rate would be the minimum exchange rate they're
willing to accept (e.g. at least 1000 USD for each oz of gold).
Some examples:
An offer to exchange USD for gold:
{from-currency: bigbank.com/usd
to-currency: goldmoney.com/gold
maximum-amount: 2000
minimum-exchange-rate: 0.001 }
This would be an offer to sell $2000 for at least 0.001 oz/$.
Offering a $200 personal loan to me at par and 5% APR:
{from-currency: bigbank.com/usd
to-currency: loans.com/jplewicke/usd/5percent
maximum-amount 200
minimum-exchange-rate: 1.0 }
Backing a friend's credit with your own:
{from-currency: loans.com/jplewicke/usd
to-currency: loans.com/cwagner/usd
maximum-amount: 500
minimum-exchange-rate: 1.0}
The Ripple server would receive a bunch of these offers in sequence,
calculate the best possible exchange rate between each pair of units
of account, and cause a transaction when a cycle of beneficial
exchanges is possible. This sort of auto-arbitrage means that no one
unit of account need be dominant. I mentioned some algorithm details
on the "P2P currency conversion rate algorithm thread", and this can
probably be done in O(n^2.5 log^2 n) in a somewhat-scalable fashion.
I think this approach can work pretty well, and would help create a
useful exchange network for budding alternative units of account.
Best,
JP
Ryan Fugger
your post on agile-banking about building an alternative currency
exchange. I don't have a lot of time, but let me know if I can help
at all.
Ryan
> --
> You received this message because you are subscribed to the Google Groups "Ripple users" group.
> To post to this group, send email to rippl...@googlegroups.com.
> To unsubscribe from this group, send email to rippleusers...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rippleusers?hl=en.
>
>
David Watson
around with.
Essentially what needs to happen in order for payment clearing to
happen, is that these holders of different currencies have to let
their balances slosh around to some degree in order to facilitate the
payment mechanism.
I understand you're idea from a protocol/object definition
perspective. Like {from, to, max-amount, min-exchange-rate}, but this
part I'd like to see some more elaboration:
> The Ripple server would receive a bunch of these offers in sequence,
> calculate the best possible exchange rate between each pair of units
> of account, and cause a transaction when a cycle of beneficial
> exchanges is possible. This sort of auto-arbitrage means that no one
> unit of account need be dominant. I mentioned some algorithm details
> on the "P2P currency conversion rate algorithm thread", and this can
> probably be done in O(n^2.5 log^2 n) in a somewhat-scalable fashion.
To me, when a user wants to "buy into" these currencies, calculating
prices and what-not is a market function. Some currencies might be
exclusive, or full, or restricted in some manner to a certain number
of participants. It seems, by your example the "main inputs" to your
algorithm would be two users wanting to exchange currencies. But what
about the simple case where a user already has x number of currencies
and has no immediate desire to change his relative amounts in any of
the currencies he owns? In this case it seems the "main inputs" have
to be whatever conversion rates the participant assigns between the
currencies he/she currently owns, as we still need the conversion
rates for every node in order to facilitate the payment clearing
mechanism for every node/participant.
If a user decided he didn't want to modify his current wealth
allocation across whatever currencies he owns, then the Ripple payment
mechanism wouldn't function by definition. What is "looks like" your
suggesting (and feel free to correct or clarify) is that 'bids' or
'offers' for one currency in terms of another could be used to
determine some type of 'equilibrium rate' (like a Walrasian call
market). In my vision of how it would work, I don't see a lot of
currency movement on a user by user basis. I see users moving out of
currencies that are more erratic to ones that are less erratic in
terms of relative price within their own currency group. The primary
impetus for expanding into new currencies would be from the necessity
to actually represent more wealth.
Your idea seems like it would be very close 'functionally speaking' to
what I'm proposing, but I'm still unclear as to exactly how the "best
possible exchange rate" is calculated. But it does seem like this
would allow unchecked speculation in whatever currency it became
popular to 'demand'. Anyway, I still have some questions, for
instance, would every participant be able to "bid" on any currency, or
would it be restricted to the ones they were already a member of?
Anyway, glad to see someone thinking in this direction. As I've
mentioned elsewhere, I think this is the primary roadblock at this
point to moving forward.
On Feb 13, 8:36 pm, John Paul Lewicke <jplewi...@gmail.com> wrote:
> I've been thinking for a bit now about how to implement Ripple in
> Pelle Braendgaard's new OpenTransact peer-to-peer payment system --http://www.opentransact.org/. For those who may not be familiar with
> it, OpenTransact is a very simple payment system built using OAuth (an
> authorization/delegation API). Pelle has some typical use cases athttp://www.opentransact.org/usecases.html, and I think there are
> several reasons why it should be relatively easy to implement Ripple
> using it.
>
> 1. Authorization is built in. If someone wants to trade 40 Berkshares
> for at least 60 Twollars, using OAuth allows the Ripple exchange node
> to verify with the Berkshares website that that person has a valid
> account and can prevent the person from transferring those Berkshares
> somewhere else while the trade is in progress.
>
> 2. OpenTransact handles units of account in a very flexible and
> sensible manner. Each unit of account is represented by a URL,
> leaving the details of each currency, loan system, equity holding,
> commodity, etc. up to individual asset trackers. An asset tracker is
> simply a website that tracks ownership of some unit of account, and
> that records transfers between individuals. The asset tracker for a
> gold fund could bewww.gold.com/transactions, while a Ripple-style P2P
> loan site could be loans.com/jplewicke/usd .
>
> 3. OpenTransact transactions are very simple. They are instructions
> for an asset tracker to transfer ownership of a certain quantity of a
> given unit of account from the current owner to a new owner.
>
> Pelle has some good descriptions of OpenTransact athttp://wiki.github.com/opentransact/opentransact/,http://www.opentransact.org/, his bloghttp://stakeventures.com/,
> and the agile-banking google grouphttp://groups.google.com/group/agile-banking. I'm going to describe
John Paul Lewicke
anything that I can use help with.
David, I think that minimizing relative price volatility is a very
worthy goal, and hopefully one of the things we can learn from this is
which currencies and systems of exchange best serve it. In my view,
in equilibrium no one trades -- there are no trades left to be done
that make the buyer and the seller better off. However, equilibrium
is fleeting and uncertain. I'm not sure what my relative preferences
are for peaches in terms of salmon, and either they may change or I
may discover that I'd like to diversify more from lean protein into
pitted fruits.
The challenge here is to build an exchange that is free and fair.
Careful thought should go into designing it in a way that encourages
extensive competition, symmetric information, and a high volume of
trade.
> Your idea seems like it would be very close 'functionally speaking' to
> what I'm proposing, but I'm still unclear as to exactly how the "best
> possible exchange rate" is calculated. But it does seem like this
> would allow unchecked speculation in whatever currency it became
> popular to 'demand'. Anyway, I still have some questions, for
> instance, would every participant be able to "bid" on any currency, or
> would it be restricted to the ones they were already a member of?
In the current design, people would be able to bid on any currency.
This is mainly due to the design of OpenTransact, in which
authorization applies only to initiating payment, not receiving it.
I'm open to a system that relaxes this constraint, since it allows you
to build some interesting systems (e.g. it might be desirable to
restrict who can buy stock in a private company).
I'm going to be off grid about Friday, but I hope to explain more when
I'm back. Best,
John Paul
David Watson
On Feb 16, 8:21 am, John Paul Lewicke <jplewi...@gmail.com> wrote:
> Thanks, Ryan. I'll definitely be communicating my progress and
> anything that I can use help with.
>
> David, I think that minimizing relative price volatility is a very
> worthy goal, and hopefully one of the things we can learn from this is
> which currencies and systems of exchange best serve it. In my view,
> in equilibrium no one trades -- there are no trades left to be done
> that make the buyer and the seller better off. However, equilibrium
> is fleeting and uncertain. I'm not sure what my relative preferences
> are for peaches in terms of salmon, and either they may change or I
> may discover that I'd like to diversify more from lean protein into
> pitted fruits.
>
> The challenge here is to build an exchange that is free and fair.
> Careful thought should go into designing it in a way that encourages
> extensive competition, symmetric information, and a high volume of
> trade.
It's not about "minimizing relative price volatility" in the general
sense. It's about the fact that if you are trying to route payments
using a Ripple-based payment resolution algorithm, the conversion
rates even slightly skewed cause the 'costs' along each path to vary
too widely to function practically as a universal medium the way money
does currently. You always have 'real' price fluctuations but I'm
asking what method do we use to adjust for the fact that the graph
itself is innately out of balance. I don't think anyone would
disagree that in whatever system gets devised, a loaf of bread
purchased in the store one minute should be roughly the same the next
minute barring any wild schisms in the commodities market. If any
system is created that doesn't satisfy this condition, it might make a
great tool for currency traders but it isn't going to provide the
"money" function.
Yes "market equilibrium's" are fleeting. I'm talking about getting a
"graph equilibrium" between various participants subjective conversion
rates. Equalizing the rates in terms of "path cost". I'm calling it
an "equilibrium" rate only because from a coding/algorithm standpoint
that's basically what we're doing.
Anyway, it's becoming clearer that we're talking about different
ideas. The way I'm looking at the base system is more in line with a
'group strategy' kind of situation, where it's about having a monetary
system that protects value and doesn't destroy it. It's not about
what your relative preference is for salmon or peaches, it's about
setting a conversion rate between them such that you would still have
the same amount of wealth (from your perspective) if all your salmon
were turned into peaches or vice versa. Salmon and peaches are
probably bad examples from my perspective since those types of
commodities would likely be trading in real commodities markets and I
doubt too many people would want to use them as a base currency as
their day-to-day "checking account" money.
So to me the problem is the same no matter how we approach it. If we
want to allow payments between a buyer and a seller without a central
currency, and also where the buyer and seller do not share a common
currency, then some "clearing" process of some sort needs to be
applied so that the "relative price" is unaffected by the path taken
in the graph for the purpose of payment clearing. Otherwise the
relative prices will vary too wildly (you can look at the graph of the
simulation results that I posted as an example) on a transaction by
transaction basis.
Of course if the model you're envisioning isn't based upon the same
assumptions that mine is, this problem might not be relevant. For
instance, if you are envisioning people simply buying into the needed
currencies on the fly then decentralized payment clearing isn't even
relevant. But if you do use some mechanism that buys into currencies
on the fly, as I've said elsewhere, it seems that-just as in the
natural economy-you'd experience a centralization tendency towards one
currency.
>
> > Your idea seems like it would be very close 'functionally speaking' to
> > what I'm proposing, but I'm still unclear as to exactly how the "best
> > possible exchange rate" is calculated. But it does seem like this
> > would allow unchecked speculation in whatever currency it became
> > popular to 'demand'. Anyway, I still have some questions, for
> > instance, would every participant be able to "bid" on any currency, or
> > would it be restricted to the ones they were already a member of?
>
> In the current design, people would be able to bid on any currency.
> This is mainly due to the design of OpenTransact, in which
> authorization applies only to initiating payment, not receiving it.
> I'm open to a system that relaxes this constraint, since it allows you
> to build some interesting systems (e.g. it might be desirable to
> restrict who can buy stock in a private company).
See here's another area where the model I'm using differs from yours.
I'm assuming payment can only happen through a currency a user already
owns. They can never get paid or pay out in some random currency
someone wants to pay/receive in. They are always paid in terms of
currencies they own via the graph. The idea of getting a "conversion
rate" or a "price" (to use in order to settle a payment request) by
using an auction or exchange market is relevant perhaps to some
currency types, but for others like a REIT or a share in an equity
partnership, it's going to just be the corresponding members
subjective assessment. In this context, people 'bidding' on a
'currency' (using our broad definition of currency) that they have no
stake in (as you mention above) doesn't really apply. The way I am
running my simulation, only those who actually have a stake in a
currency have any say over the conversion rates used in the payment
clearing process.
As you can see, I keep hammering away at the problem in relation to
"the payment clearing process". Only because I have noticed, having
tried to communicate and explain this issue multiple times and in
multiple ways, that people are confusing the concept of "setting some
kind of price in terms of buying and selling these currencies or
currency types", with "using an algorithm in order to 'clear' the
prices with respect to the current exchange rates input by the
participants in a connected but random graph". It's not about
'fixing' exchange rates, it's about distilling a "most likely exchange
rate given current inputs" from a decentralized graph that is innately
and fundamentally distorted. If someone changes their input rate,
naturally you'd have to recalculate everything. And again, this
'rate' (really its a set of rates) is only used for the payment
clearing process, it isn't a price that's used for any other
purpose.
John Paul Lewicke
which transactions would occur based on a sequence of bids. You can
enter offers to trade currencies from the perspective of multiple
bidders, and see which transactions the exchange software would
trigger. The demonstration website is up on Google App Engine at
http://rippledaemon.appspot.com/ , and the code can be viewed at
http://github.com/jplewicke/ripple-daemon . Please let me know if you
have any questions or concerns.
Best,
JP