ripple-protocol

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Ryan F. <rf...@gm...>]

On 10/14/06, Jiri Baum <ji...@ba...> wrote:
> > My reason for not wanting to integrate passing interest charges back
> > to the payer boils down to being able to answer simply the user's
> > question "what do I have to pay my friend so I don't owe her any more
> > ?"  To me, the answer "you owe her $100 at 6%, and she owes you $100
> > at 3%, so to fairly wipe the slate clean you have to precisely reverse
> > those transactions as intermediaries in other people's payments" isn't
> > a very simple one -- and that's about as simple as it could ever
> > possibly be.
>
> > Maybe you have answers to these questions that I haven't thought of?
>
> The trick is that the above description is missing the *dates* at which the
> loans took place. Let's add a couple of dates to it: the 6% loan is 4 months
> old and the 3% loan is 3 months old (and in each case $100 was the amount
> originally borrowed).
>
> At that point, my answer is: "as of today, you owe her $102.02 and she owes
> you $100.75, so to wipe the slate clean you need to pay her $1.27".
>
> In fact, the program would normally display the debts as "$102.02 at 6%" and
> "$100.75 at 3%", to indicate balance including interest, so the answer would
> be obvious.

You're not considering the fact that much of this interest is likely
being charged to defray costs incurred further up a payment chain.
I'll give an example:  Suppose there's a payment chain Alice -> Bob ->
Carol -> Dan, for a $50 payment, with all balances initially zero.
Bob charges Alice 1% interest, Carol charges Bob 2%, and Dan charges
Carol 3%.  The whole complication with interest arises because Carol,
as an intermediary, is hit with a 3% interest charge, *which recurs
continually over time* on her $50 balance as a side-effect of this
payment.  Perfect fairness dictates that she be able to pass that back
to Bob, who caused her to incur this charge, in addition to charging
the regular 2% to defray her perceived risk of his default.  Bob,
likewise, would pass the 3% as well as the 2% on $50 back to Alice,
and also charge her the regular 1%.

It's easy to calculate the balances at any point in the future, so we
can know what payment is required to zero those balances.  However, if
Bob pays off Carol before Carol pays off Dan, Carol still being
charged interest by Dan for a transaction that she neither initiated
nor substantially benefitted from.  She should still be able to charge
interest to Bob, and Bob to Alice, until her debt with Dan is cleared.
 However, Bob can never know for certain Carol's balance with Dan...

In fact, if the true principle of fairness is that the situation for
intermediaries should remain as close as possible to that before the
transaction took place, then Carol should be able to continue charging
the 3% in perpetuity, since if the transaction hadn't taken place and
her balance was zero, and she gave $50 value to Dan in exchange for a
Ripple bookkeepping entry in her favour, she would be entitled to
charge him interest on that entry.  So, her charging interest (albeit
not necessarily at the same rate she would charge Dan) to Bob makes up
for that.  Sort of...  Of course, Carol *could* stop charging Bob
whenever she wanted to.  But then Bob would be collecting interest
from Alice on Carol's behalf, and pocketing it himself.  Anyways, this
makes up for Bob needing to know Carol's balance with Dan.

So my point is that just because a balance gets zeroed, doesn't mean
interest charges can stop.  (In fact, it's entirely possible to have a
negative balance, but still be collecting interest.)

In my opinion, interest-rate imbalances along the payment chain are
much more cleanly (although not always as fairly) handled using
transaction fees, which propagate naturally back to the payer.  I
think most users would prefer a great increase in simplicity and
intuitiveness to a small (and most often likely very small) increase
in fairness.

Ryan

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Jiri B. <ji...@ba...>]

Hello,

> > > My reason for not wanting to integrate passing interest charges back
> > > to the payer boils down to being able to answer simply the user's
> > > question "what do I have to pay my friend so I don't owe her any more
> > > ?"  To me, the answer "you owe her $100 at 6%, and she owes you $100
> > > at 3%, so to fairly wipe the slate clean you have to precisely reverse
> > > those transactions as intermediaries in other people's payments" isn't
> > > a very simple one -- and that's about as simple as it could ever
> > > possibly be.

> > > Maybe you have answers to these questions that I haven't thought of?

Jiri Baum:
> > The trick is that the above description is missing the *dates* at which
> > the loans took place. Let's add a couple of dates to it: the 6% loan is 4
> > months old and the 3% loan is 3 months old (and in each case $100 was the
> > amount originally borrowed).
> >
> > At that point, my answer is: "as of today, you owe her $102.02 and she
> > owes you $100.75, so to wipe the slate clean you need to pay her $1.27".
> >
> > In fact, the program would normally display the debts as "$102.02 at 6%"
> > and "$100.75 at 3%", to indicate balance including interest, so the
> > answer would be obvious.

Ryan Fugger:
> You're not considering the fact that much of this interest is likely
> being charged to defray costs incurred further up a payment chain.
> I'll give an example:  Suppose there's a payment chain Alice -> Bob ->
> Carol -> Dan, for a $50 payment, with all balances initially zero.
> Bob charges Alice 1% interest, Carol charges Bob 2%, and Dan charges
> Carol 3%.  The whole complication with interest arises because Carol,
> as an intermediary, is hit with a 3% interest charge, *which recurs
> continually over time* on her $50 balance as a side-effect of this
> payment.  Perfect fairness dictates that she be able to pass that back
> to Bob, who caused her to incur this charge, in addition to charging
> the regular 2% to defray her perceived risk of his default.  Bob,
> likewise, would pass the 3% as well as the 2% on $50 back to Alice,
> and also charge her the regular 1%.

The interest rates would be passed along the chain:

* Carol is being charged 3%, she adds her own 2% and charges Bob a total of 5%

* Bob is being charged 5%, he adds his own 1% and charges Alice a total of 6%

(Note: when I say "charges", what I really mean is that the balance of the 
debt will grow at that rate. There are no separate "interest" payments.)

> It's easy to calculate the balances at any point in the future, so we
> can know what payment is required to zero those balances.  However, if
> Bob pays off Carol before Carol pays off Dan, Carol still being
> charged interest by Dan for a transaction that she neither initiated
> nor substantially benefitted from.  She should still be able to charge
> interest to Bob, and Bob to Alice, until her debt with Dan is cleared.

Well, she just got money from Bob, she can use it to pay off Dan. (In reality, 
she'll use it to pay off her highest-interest debt, whether that's with Dan 
or someone else.)

>  However, Bob can never know for certain Carol's balance with Dan...

He also has no way of influencing it, no way of actually clearing the debt.

> In my opinion, interest-rate imbalances along the payment chain are
> much more cleanly (although not always as fairly) handled using
> transaction fees, which propagate naturally back to the payer.  I
> think most users would prefer a great increase in simplicity and
> intuitiveness to a small (and most often likely very small) increase
> in fairness.

I'm not sure transaction fees are particularly simple.

Transaction fees also introduce friction into the system, while interest rates 
do not. This may be a good thing or a bad thing, but it certainly is a 
different species of charge.

Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Evgeni P. <epa...@gm...>]

>> In my opinion, interest-rate imbalances along the payment chain are
>> much more cleanly (although not always as fairly) handled using
>> transaction fees, which propagate naturally back to the payer.  I
>> think most users would prefer a great increase in simplicity and
>> intuitiveness to a small (and most often likely very small) increase
>> in fairness.

> I'm not sure transaction fees are particularly simple.
>
> Transaction fees also introduce friction into the system, while interest
rates
> do not. This may be a good thing or a bad thing, but it certainly is a
> different species of charge.

I will try to explain my thoughts about the interest and how it plays with
Ripple.

Let us start with the simple barter-trading:
1) Alice gives Bob 1kg potatoes and Bob *instantly* gives Alice 0.5kgonions.
This is simple an it works bit is not always convenient.

Here is where the money comes:
2) Alice gives Bob 1kg potatoes and Bob *instantly* gives Alice $1. The $1
in fact has no "real" value to Alice therefore "in-reality" Bob owes Alice
1kg-potatoes-equivalent. Such a debt "in-reality" would be a subject of
interest-charges. However the $1 has an indirect value to Alice - she is
able to purchase 1kg-potatoes-equivalent form the market-place
*whenever she wants*. The "whenever she wants"-part is crucial. This
makes the $1 a perfectly valid pay-off for the 1kg-potatoes with no
interest charges taking part (because the $1 *IS* a pay-off). Therefore
the "whenever she wants" part transforms the dollar-money from an instrument
for liability-accounting into a valid and valued commodity. Dollar is no
more a IOU
(and therefore the debt being a subject of interest charges). Dollar becomes
a
good suitable for debt pay-off much like potatoes and onions.

And now we are trying to invent electronic money-equivalent. Notice that
bank-account's balances *are not* electronic-money. They are an instrument
for liability-accounting and therefore they are a subject of
interest-charges.
In a sentence: Bank-account's balances does not posses the pay-off power of
the real-money. And therefore bank-account's balances are a subject of
interest-charges.
If we want to "invent" an equivalent to the real-money (cache) we have to
*bless* our invention with *the power to pay-off debts* and not just to
account
for debts. Notice that the bless-metaphor if not far from the truth. Take
the
dollars for example - they are "blessed" to have *the power to pay-off
debts*
by the vast acceptation they have in society.

Here is my strong assertion: As long as we want to make Ripple to be
more than a sophisticated way to trade with debts but instead to be a
vivid alternative to the real-money we need to "bless" Ripple-balances
with the the power to pay-off debts.

Ripple-balances being a pay-off commodity implies:

a)  Nearly instant on demand pay-off of debts. This corresponds
to the "spend whenever you want"-property of the dollars.

Comment: This means that debts having more special policy for
repayment are not suitable to be Ripple-accounts. For example mortgage-
style debts can not be Ripple-debts.


b) No interest on Ripple-accounts. This corresponds to the "no interest on
paid-off debts" property of the dollars.

Comment: This is in pair with (a). As soon as somebody could instantly
acquire possession on the goods she have landed there is no sense to
charge interest. It's equivalent to having the goods available.


c) Low risk of default on Ripple-accounts.This corresponds to the "I have
them
in my pocket" property of the dollars.

Comment: This is OK as soon as Ripple is a trusted-network.


I hope this thoughts are not overly abstract. Actually I believe this to be
a really
practical foundation for the Ripple-money. Waiting for your comments...












On 10/16/06, Jiri Baum <ji...@ba...> wrote:
>
> Hello,
>
> > > > My reason for not wanting to integrate passing interest charges back
> > > > to the payer boils down to being able to answer simply the user's
> > > > question "what do I have to pay my friend so I don't owe her any
> more
> > > > ?"  To me, the answer "you owe her $100 at 6%, and she owes you $100
> > > > at 3%, so to fairly wipe the slate clean you have to precisely
> reverse
> > > > those transactions as intermediaries in other people's payments"
> isn't
> > > > a very simple one -- and that's about as simple as it could ever
> > > > possibly be.
>
> > > > Maybe you have answers to these questions that I haven't thought of?
>
> Jiri Baum:
> > > The trick is that the above description is missing the *dates* at
> which
> > > the loans took place. Let's add a couple of dates to it: the 6% loan
> is 4
> > > months old and the 3% loan is 3 months old (and in each case $100 was
> the
> > > amount originally borrowed).
> > >
> > > At that point, my answer is: "as of today, you owe her $102.02 and she
> > > owes you $100.75, so to wipe the slate clean you need to pay her
> $1.27".
> > >
> > > In fact, the program would normally display the debts as "$102.02 at
> 6%"
> > > and "$100.75 at 3%", to indicate balance including interest, so the
> > > answer would be obvious.
>
> Ryan Fugger:
> > You're not considering the fact that much of this interest is likely
> > being charged to defray costs incurred further up a payment chain.
> > I'll give an example:  Suppose there's a payment chain Alice -> Bob ->
> > Carol -> Dan, for a $50 payment, with all balances initially zero.
> > Bob charges Alice 1% interest, Carol charges Bob 2%, and Dan charges
> > Carol 3%.  The whole complication with interest arises because Carol,
> > as an intermediary, is hit with a 3% interest charge, *which recurs
> > continually over time* on her $50 balance as a side-effect of this
> > payment.  Perfect fairness dictates that she be able to pass that back
> > to Bob, who caused her to incur this charge, in addition to charging
> > the regular 2% to defray her perceived risk of his default.  Bob,
> > likewise, would pass the 3% as well as the 2% on $50 back to Alice,
> > and also charge her the regular 1%.
>
> The interest rates would be passed along the chain:
>
> * Carol is being charged 3%, she adds her own 2% and charges Bob a total
> of 5%
>
> * Bob is being charged 5%, he adds his own 1% and charges Alice a total of
> 6%
>
> (Note: when I say "charges", what I really mean is that the balance of the
> debt will grow at that rate. There are no separate "interest" payments.)
>
> > It's easy to calculate the balances at any point in the future, so we
> > can know what payment is required to zero those balances.  However, if
> > Bob pays off Carol before Carol pays off Dan, Carol still being
> > charged interest by Dan for a transaction that she neither initiated
> > nor substantially benefitted from.  She should still be able to charge
> > interest to Bob, and Bob to Alice, until her debt with Dan is cleared.
>
> Well, she just got money from Bob, she can use it to pay off Dan. (In
> reality,
> she'll use it to pay off her highest-interest debt, whether that's with
> Dan
> or someone else.)
>
> >  However, Bob can never know for certain Carol's balance with Dan...
>
> He also has no way of influencing it, no way of actually clearing the
> debt.
>
> > In my opinion, interest-rate imbalances along the payment chain are
> > much more cleanly (although not always as fairly) handled using
> > transaction fees, which propagate naturally back to the payer.  I
> > think most users would prefer a great increase in simplicity and
> > intuitiveness to a small (and most often likely very small) increase
> > in fairness.
>
> I'm not sure transaction fees are particularly simple.
>
> Transaction fees also introduce friction into the system, while interest
> rates
> do not. This may be a good thing or a bad thing, but it certainly is a
> different species of charge.
>
> Jiri
> --
> Jiri Baum <ji...@ba...>
> http://www.baum.com.au/~jiri
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Ryan F. <rf...@gm...>]

On 10/15/06, Jiri Baum <ji...@ba...> wrote:
> Ryan Fugger:
> > You're not considering the fact that much of this interest is likely
> > being charged to defray costs incurred further up a payment chain.
> > I'll give an example:  Suppose there's a payment chain Alice -> Bob ->
> > Carol -> Dan, for a $50 payment, with all balances initially zero.
> > Bob charges Alice 1% interest, Carol charges Bob 2%, and Dan charges
> > Carol 3%.  The whole complication with interest arises because Carol,
> > as an intermediary, is hit with a 3% interest charge, *which recurs
> > continually over time* on her $50 balance as a side-effect of this
> > payment.  Perfect fairness dictates that she be able to pass that back
> > to Bob, who caused her to incur this charge, in addition to charging
> > the regular 2% to defray her perceived risk of his default.  Bob,
> > likewise, would pass the 3% as well as the 2% on $50 back to Alice,
> > and also charge her the regular 1%.
>
> The interest rates would be passed along the chain:
>
> * Carol is being charged 3%, she adds her own 2% and charges Bob a total of 5%
>
> * Bob is being charged 5%, he adds his own 1% and charges Alice a total of 6%

That would be nice, but compound interest rates don't add this way.

Take a $100 principal:

3% interest after one year, compounded monthly =  $3.0416
2% after one year =  $2.0184
Total: $5.0600

5% after one year = $5.1162

The difference magnifies exponentially after that.  It's not a bad
short-term approximation, though, which we could probably get away
with, since the point is to compensate the intermediary for interest
charges incurred, and adding the interest rates together gives a
higher charge which will always do the trick (and more).

I'm not sure this improves the situation, though, because now instead
of having to manage balances for separate interest rates in the range
0-10%, say, quantized into 0.1% or 0.5% increments, the range is now
essentially unlimited -- a long payment chain could easily put the
interest up over 100% (although in practice hopefully no payer would
accept such a path?).

The benefit to this approximation, however, is that interest is always
being charged only on the payment total, and no more, which makes
cancelling debt easier.

>
> > It's easy to calculate the balances at any point in the future, so we
> > can know what payment is required to zero those balances.  However, if
> > Bob pays off Carol before Carol pays off Dan, Carol still being
> > charged interest by Dan for a transaction that she neither initiated
> > nor substantially benefitted from.  She should still be able to charge
> > interest to Bob, and Bob to Alice, until her debt with Dan is cleared.
>
> Well, she just got money from Bob, she can use it to pay off Dan. (In reality,
> she'll use it to pay off her highest-interest debt, whether that's with Dan
> or someone else.)

Good point.  What about the case of through payments cancelling debt
on an account?  What I really want to avoid is the case of interest
being paid on a zero balance.  That means that when the overall
account balance is reduced, interest-bearing debt must be erased, not
just balanced against debt in the other direction at a different
interest rate.

Suppose there's an outstanding debt owing from Bob to Carol at 32%
interest from a through payment on which Carol is paying 30% up the
chain.  What if a payment comes through Carol from a different
direction which could cancel that debt?  Musn't Carol ensure that she
keeps collecting at least her 30% on what is essentially for her a
balance transfer?  (Or alternatively, wipe out some of her debt with
the same high interest rate?)  If not, over the course of a few
months, she could pay a significant price.

The difference with through payments cancelling debt vs. cash is that
one can presumably route cash in whatever direction one wants, to
cancel the highest-interest debt, but one cannot route through
payments however one wants...

>
> > In my opinion, interest-rate imbalances along the payment chain are
> > much more cleanly (although not always as fairly) handled using
> > transaction fees, which propagate naturally back to the payer.  I
> > think most users would prefer a great increase in simplicity and
> > intuitiveness to a small (and most often likely very small) increase
> > in fairness.
>
> I'm not sure transaction fees are particularly simple.
>
> Transaction fees also introduce friction into the system, while interest rates
> do not. This may be a good thing or a bad thing, but it certainly is a
> different species of charge.

I think the example above shows how interest rates can introduce quite
a friction into the system...

Ryan

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Ryan F. <rf...@gm...>]

I agree with you Evgeni.  Chequing (demand) accounts traditionally
have little or no interest for the reason that they have a "whenever
you want" character.  Ultimately I feel that interest-bearing debts
don't belong in the Ripple system.  Ripple is the liquid for buying
and selling these structured debts, not for containing them.

I had added an interest rate in to the account data for sheer
convenience:  It is impossible to prevent people from agreeing between
themselves to charge interest on their Ripple account, so why not make
it easier for them if they want to.  But maybe doing so opens a can of
worms that is better kept closed...

Ryan

On 10/16/06, Evgeni Pandurski <epa...@gm...> wrote:
> >> In my opinion, interest-rate imbalances along the payment chain are
> >> much more cleanly (although not always as fairly) handled using
> >> transaction fees, which propagate naturally back to the payer.  I
> >> think most users would prefer a great increase in simplicity and
> >> intuitiveness to a small (and most often likely very small) increase
> >> in fairness.
>
> > I'm not sure transaction fees are particularly simple.
> >
> > Transaction fees also introduce friction into the system, while interest
> rates
> > do not. This may be a good thing or a bad thing, but it certainly is a
> > different species of charge.
>
> I will try to explain my thoughts about the interest and how it plays with
> Ripple.
>
> Let us start with the simple barter-trading:
> 1) Alice gives Bob 1kg potatoes and Bob *instantly* gives Alice 0.5kg
> onions.
> This is simple an it works bit is not always convenient.
>
> Here is where the money comes:
> 2) Alice gives Bob 1kg potatoes and Bob *instantly* gives Alice $1. The $1
> in fact has no "real" value to Alice therefore "in-reality" Bob owes Alice
> 1kg-potatoes-equivalent. Such a debt "in-reality" would be a subject of
> interest-charges. However the $1 has an indirect value to Alice - she is
> able to purchase 1kg-potatoes-equivalent form the market-place
> *whenever she wants*. The "whenever she wants"-part is crucial. This
> makes the $1 a perfectly valid pay-off for the 1kg-potatoes with no
> interest charges taking part (because the $1 *IS* a pay-off). Therefore
> the "whenever she wants" part transforms the dollar-money from an instrument
> for liability-accounting into a valid and valued commodity. Dollar is no
> more a IOU
> (and therefore the debt being a subject of interest charges). Dollar becomes
> a
> good suitable for debt pay-off much like potatoes and onions.
>
> And now we are trying to invent electronic money-equivalent. Notice that
> bank-account's balances *are not* electronic-money. They are an instrument
>  for liability-accounting and therefore they are a subject of
> interest-charges.
> In a sentence: Bank-account's balances does not posses the pay-off power of
> the real-money. And therefore bank-account's balances are a subject of
> interest-charges.
> If we want to "invent" an equivalent to the real-money (cache) we have to
> *bless* our invention with *the power to pay-off debts* and not just to
> account
> for debts. Notice that the bless-metaphor if not far from the truth. Take
> the
> dollars for example - they are "blessed" to have *the power to pay-off
> debts*
> by the vast acceptation they have in society.
>
> Here is my strong assertion: As long as we want to make Ripple to be
> more than a sophisticated way to trade with debts but instead to be a
> vivid alternative to the real-money we need to "bless" Ripple-balances
> with the the power to pay-off debts.
>
> Ripple-balances being a pay-off commodity implies:
>
> a)  Nearly instant on demand pay-off of debts. This corresponds
> to the "spend whenever you want"-property of the dollars.
>
> Comment: This means that debts having more special policy for
> repayment are not suitable to be Ripple-accounts. For example mortgage-
> style debts can not be Ripple-debts.
>
>
> b) No interest on Ripple-accounts. This corresponds to the "no interest on
> paid-off debts" property of the dollars.
>
> Comment: This is in pair with (a). As soon as somebody could instantly
>  acquire possession on the goods she have landed there is no sense to
> charge interest. It's equivalent to having the goods available.
>
>
> c) Low risk of default on Ripple-accounts.This corresponds to the "I have
> them
> in my pocket" property of the dollars.
>
> Comment: This is OK as soon as Ripple is a trusted-network.
>
>
> I hope this thoughts are not overly abstract. Actually I believe this to be
> a really
> practical foundation for the Ripple-money. Waiting for your comments...
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 10/16/06, Jiri Baum <ji...@ba...> wrote:
> >
> > Hello,
> >
> > > > > My reason for not wanting to integrate passing interest charges back
> > > > > to the payer boils down to being able to answer simply the user's
> > > > > question "what do I have to pay my friend so I don't owe her any
> more
> > > > > ?"  To me, the answer "you owe her $100 at 6%, and she owes you $100
> > > > > at 3%, so to fairly wipe the slate clean you have to precisely
> reverse
> > > > > those transactions as intermediaries in other people's payments"
> isn't
> > > > > a very simple one -- and that's about as simple as it could ever
> > > > > possibly be.
> >
> > > > > Maybe you have answers to these questions that I haven't thought of?
> >
> > Jiri Baum:
> > > > The trick is that the above description is missing the *dates* at
> which
> > > > the loans took place. Let's add a couple of dates to it: the 6% loan
> is 4
> > > > months old and the 3% loan is 3 months old (and in each case $100 was
> the
> > > > amount originally borrowed).
> > > >
> > > > At that point, my answer is: "as of today, you owe her $102.02 and she
> > > > owes you $100.75, so to wipe the slate clean you need to pay her
> $1.27".
> > > >
> > > > In fact, the program would normally display the debts as "$102.02 at
> 6%"
> > > > and "$100.75 at 3%", to indicate balance including interest, so the
> > > > answer would be obvious.
> >
> > Ryan Fugger:
> > > You're not considering the fact that much of this interest is likely
> > > being charged to defray costs incurred further up a payment chain.
> > > I'll give an example:  Suppose there's a payment chain Alice -> Bob ->
> > > Carol -> Dan, for a $50 payment, with all balances initially zero.
> > > Bob charges Alice 1% interest, Carol charges Bob 2%, and Dan charges
> > > Carol 3%.  The whole complication with interest arises because Carol,
> > > as an intermediary, is hit with a 3% interest charge, *which recurs
> > > continually over time* on her $50 balance as a side-effect of this
> > > payment.  Perfect fairness dictates that she be able to pass that back
> > > to Bob, who caused her to incur this charge, in addition to charging
> > > the regular 2% to defray her perceived risk of his default.  Bob,
> > > likewise, would pass the 3% as well as the 2% on $50 back to Alice,
> > > and also charge her the regular 1%.
> >
> > The interest rates would be passed along the chain:
> >
> > * Carol is being charged 3%, she adds her own 2% and charges Bob a total
> of 5%
> >
> > * Bob is being charged 5%, he adds his own 1% and charges Alice a total of
> 6%
> >
> > (Note: when I say "charges", what I really mean is that the balance of the
> > debt will grow at that rate. There are no separate "interest" payments.)
> >
> > > It's easy to calculate the balances at any point in the future, so we
> > > can know what payment is required to zero those balances.  However, if
> > > Bob pays off Carol before Carol pays off Dan, Carol still being
> > > charged interest by Dan for a transaction that she neither initiated
> > > nor substantially benefitted from.  She should still be able to charge
> > > interest to Bob, and Bob to Alice, until her debt with Dan is cleared.
> >
> > Well, she just got money from Bob, she can use it to pay off Dan. (In
> reality,
> > she'll use it to pay off her highest-interest debt, whether that's with
> Dan
> > or someone else.)
> >
> > >  However, Bob can never know for certain Carol's balance with Dan...
> >
> > He also has no way of influencing it, no way of actually clearing the
> debt.
> >
> > > In my opinion, interest-rate imbalances along the payment chain are
> > > much more cleanly (although not always as fairly) handled using
> > > transaction fees, which propagate naturally back to the payer.  I
> > > think most users would prefer a great increase in simplicity and
> > > intuitiveness to a small (and most often likely very small) increase
> > > in fairness.
> >
> > I'm not sure transaction fees are particularly simple.
> >
> > Transaction fees also introduce friction into the system, while interest
> rates
> > do not. This may be a good thing or a bad thing, but it certainly is a
> > different species of charge.
> >
> > Jiri
> > --
> > Jiri Baum < ji...@ba...>
> http://www.baum.com.au/~jiri
> >
> >
> -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Ripple-protocol mailing list
> > Rip...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
> >
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>
>
>

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Jiri B. <ji...@ba...>]

Hello,

Ryan Fugger:
> I had added an interest rate in to the account data 
...
> But maybe doing so opens a can of worms that is better kept closed...

There is that...

Please read my comments about interest as conditional; *if* there is to be 
interest in ripple, ...

Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Stanislav M. <qe...@co...>]

> If we want to "invent" an equivalent to the real-money (cache) we have
> to
> *bless* our invention with *the power to pay-off debts* and not just
> to account
> for debts. Notice that the bless-metaphor if not far from the truth.
> Take the 
> dollars for example - they are "blessed" to have *the power to pay-off
> debts*
> by the vast acceptation they have in society.
> 

Agree, however you cannot magically bless debts with money powers. Debt
becomes money when it acquires money properties:
- negotiable - debt holder must be able to pass it to other party
- liquid - other party has to agree to accept it as payment

Negotiability will be provided by Ripple - it's a technical details.
However, liquidity - willingness to accept someone else debts
(obligations) cannot be imposed. It is a matter of trust. It is either
trust in:
(1) ability and willingness of debtor to fulfill his promise
or
(2) trust in other people willingness to accept this debt as a payment.

'Real' money have liquidity for reason (2) - everybody accepts money
because they believe that everybody accepts money. It's not (1) because
government money are backed only with 'full faith and credit' which is
kind off difficult to deliver :)

> Here is my strong assertion: As long as we want to make Ripple to be
> more than a sophisticated way to trade with debts but instead to be a 
> vivid alternative to the real-money we need to "bless" Ripple-balances
> If A needs to buy gadget from B for $100 there might be
> with the the power to pay-off debts. 

Agree -- debts must be negotiable.

> 
> Ripple-balances being a pay-off commodity implies:
> 
> a)  Nearly instant on demand pay-off of debts. This corresponds 
> to the "spend whenever you want"-property of the dollars.

Not necessarily. What is wrong in paying with promissory note payable on
some later date if other party agrees to accept it? 

> 
> Comment: This means that debts having more special policy for 
> repayment are not suitable to be Ripple-accounts. For example
> mortgage-
> style debts can not be Ripple-debts. 

Again, any debt with any 'special policies' can be traded and used to
settle debts as long as all parties agree. This should not complicate
Ripple though, because Ripple is not interested in nature of these debts
- it's just an accounting instrument. It just cares that A passed B 123
units of instrument 12-345. Whatever that 12-345 means is strictly
between A and B.

> 
> 
> b) No interest on Ripple-accounts. This corresponds to the "no
> interest on
> paid-off debts" property of the dollars.
> Comment: This is in pair with (a). As soon as somebody could instantly
> acquire possession on the goods she have landed there is no sense to
> charge interest. It's equivalent to having the goods available.

Probably. Again it depends on trustworthiness of a person whose debts
you hold. If you are absolutely sure you could instantly buy goods and
pay them with this debt, fine. Accept it at face value. But what if you
are not sure? Forcing people to either accept somebody else promise at
its face value or not accept it at all looks kind off limiting.

Again, for Ripple these are just different instruments that are
negotiable at a mutually agreed upon rates.

Interest rates will be created implicitly through exchange rates. Or
discount rates in this case.


> 
> 
> c) Low risk of default on Ripple-accounts.This corresponds to the "I
> have them 
> in my pocket" property of the dollars.
> 
> Comment: This is OK as soon as Ripple is a trusted-network.
> 
> 
> I hope this thoughts are not overly abstract. Actually I believe this
> to be a really
> practical foundation for the Ripple-money. Waiting for your
> comments... 
> 

Here is my proposal:
1. No explicit interest rates, repayment schedules etc. in Ripple
2. Ability of each person to issue various forms of debts. At least two
'payable on demand' and 'payable on <date>'.
3. Concept of interest will be introduced implicitly by his creditors
insisting on discounts for delayed payment. For example, they will
either accept his '$100 on demand' or require '$110 in three months'.
for Ripple these are just two different kinds of money.

So, in general, my proposal is a superset of Evgeni's

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Jiri B. <ji...@ba...>]

Hello,

Jiri:
> > The interest rates would be passed along the chain:

> > * Carol is being charged 3%, she adds her own 2% and charges Bob a total
> > of 5%

> > * Bob is being charged 5%, he adds his own 1% and charges Alice a total
> > of 6%

Ryan:
> That would be nice, but compound interest rates don't add this way.

I'm pretty sure it does, provided you borrow the *interest* from the next 
person (as well as the principal).

> Take a $100 principal:
>
> 3% interest after one year, compounded monthly =  $3.0416

OK. (I thought we were compounding continuously, though?)

> 2% after one year =  $2.0184

Ah, but the 2% is not on $100, but on "$100 at 3%". Carol charges Bob interest 
not only on the original $100, but also on the interest that Dan is charging.

> The benefit to this approximation, however, is that interest is always
> being charged only on the payment total, and no more, which makes
> cancelling debt easier.

Yes.

> > > It's easy to calculate the balances at any point in the future, so we
> > > can know what payment is required to zero those balances.  However, if
> > > Bob pays off Carol before Carol pays off Dan, Carol still being
> > > charged interest by Dan for a transaction that she neither initiated
> > > nor substantially benefitted from.  She should still be able to charge
> > > interest to Bob, and Bob to Alice, until her debt with Dan is cleared.

> > Well, she just got money from Bob, she can use it to pay off Dan. (In
> > reality, she'll use it to pay off her highest-interest debt, whether
> > that's with Dan or someone else.)

> Good point.  What about the case of through payments cancelling debt
> on an account?  What I really want to avoid is the case of interest
> being paid on a zero balance.  That means that when the overall
> account balance is reduced, interest-bearing debt must be erased, not
> just balanced against debt in the other direction at a different
> interest rate.

Yes, through payments repay debts before creating new ones.

> Suppose there's an outstanding debt owing from Bob to Carol at 32%
> interest from a through payment on which Carol is paying 30% up the
> chain.  What if a payment comes through Carol from a different
> direction which could cancel that debt?  Musn't Carol ensure that she
> keeps collecting at least her 30% on what is essentially for her a
> balance transfer?  (Or alternatively, wipe out some of her debt with
> the same high interest rate?)  If not, over the course of a few
> months, she could pay a significant price.

Yes, I'm not sure what to do about this. One possibility would be that any 
time a payment comes through that cancels a 30%-interest-bearing debt, that 
Carol *charge* 30% on that through payment (or on whatever part of the 
payment is cancelling the debt). I'm not sure if that's the right solution. 
It would certainly leave Carol even, but it doesn't *feel* right...

> The difference with through payments cancelling debt vs. cash is that
> one can presumably route cash in whatever direction one wants, to
> cancel the highest-interest debt, but one cannot route through
> payments however one wants...

One can influence the routing by charging different interest in different 
directions.

> > > In my opinion, interest-rate imbalances along the payment chain are
> > > much more cleanly (although not always as fairly) handled using
> > > transaction fees, which propagate naturally back to the payer.  I
> > > think most users would prefer a great increase in simplicity and
> > > intuitiveness to a small (and most often likely very small) increase
> > > in fairness.

> > I'm not sure transaction fees are particularly simple.

> > Transaction fees also introduce friction into the system, while interest
> > rates do not. This may be a good thing or a bad thing, but it certainly
> > is a different species of charge.

> I think the example above shows how interest rates can introduce quite
> a friction into the system...

Well, friction in the sense that a transaction itself costs something.

For instance, circular debts are no problem, even with interest (as long as 
it's all at the same rate); you might cancel them if you feel like it, but 
they make no difference. With transaction fees, they *do* make a difference: 
cancelling them costs something, but having them around makes some 
transactions more expensive (because they have to go the long way around the 
circle).

Similarly, if you have debt at an interest rate and you're trying to find a 
path with lower interest, with transaction fees you have to consider the 
one-off cost of the transaction versus the continuous interest charge.

Now, friction is not necessarily a bad thing; it can make a system more 
stable. Is it desirable in this particular case, though?


Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Evgeni P. <epa...@gm...>]

Evgeni:
> > ...
> > b) No interest on Ripple-accounts. This corresponds to the "no
> > interest on paid-off debts" property of the dollars.
> > Comment: This is in pair with (a). As soon as somebody could instantly
> > acquire possession on the goods she have landed there is no sense to
> > charge interest. It's equivalent to having the goods available.
> > ...

Stanislav:
> Here is my proposal:
> 1. No explicit interest rates, repayment schedules etc. in Ripple
> 2. Ability of each person to issue various forms of debts. At least two
> 'payable on demand' and 'payable on <date>'.
> 3. Concept of interest will be introduced implicitly by his creditors
> insisting on discounts for delayed payment. For example, they will
> either accept his '$100 on demand' or require '$110 in three months'.
> for Ripple these are just two different kinds of money.

I very much like what you say.

> 1. No explicit interest rates, repayment schedules etc. in Ripple

Yes. I am sure interest rates should not be Ripple's business. If nodes want
to charge interest they could use external program to calculate the
interest.
I even think that Ripple-account balance must not be changed by interest
charges - they are better being hold in external account and possibly
capitalized explicitly from time to time into the Rippple-account.

> 2. Ability of each person to issue various forms of debts. At least two
> 'payable on demand' and 'payable on <date>'.

I agree. But I see a problem with 'payable on <date>' - this means that
the 'payable on <date>'-unit would change it's value over the time (being
more precious near the due-date). It occurs to me that Ripple-units have to
hold time-translation invariance or at least not to have bias toward change
of it's value over the time.

> 3. Concept of interest will be introduced implicitly by his creditors
> insisting on discounts for delayed payment. For example, they will
> either accept his '$100 on demand' or require '$110 in three months'.
> for Ripple these are just two different kinds of money.

I will try to summarise the ideas if I correctly have understood what you
said.

Lenders could introduce interest by:
1) "embedding" it into the nature of Ripple-units.
2) charging subscription-like fees on Ripple account. For example
$15 per year for increasing Ripple's credit limit by $1,000. This would
be a good compensation for the risk lender exposes himself on.
3) choosing appropriate exchange-rates for Ripple-transactions
4) ...something else...?



On 10/17/06, Jiri Baum <ji...@ba...> wrote:
>
> Hello,
>
> Jiri:
> > > The interest rates would be passed along the chain:
>
> > > * Carol is being charged 3%, she adds her own 2% and charges Bob a
> total
> > > of 5%
>
> > > * Bob is being charged 5%, he adds his own 1% and charges Alice a
> total
> > > of 6%
>
> Ryan:
> > That would be nice, but compound interest rates don't add this way.
>
> I'm pretty sure it does, provided you borrow the *interest* from the next
> person (as well as the principal).
>
> > Take a $100 principal:
> >
> > 3% interest after one year, compounded monthly =  $3.0416
>
> OK. (I thought we were compounding continuously, though?)
>
> > 2% after one year =  $2.0184
>
> Ah, but the 2% is not on $100, but on "$100 at 3%". Carol charges Bob
> interest
> not only on the original $100, but also on the interest that Dan is
> charging.
>
> > The benefit to this approximation, however, is that interest is always
> > being charged only on the payment total, and no more, which makes
> > cancelling debt easier.
>
> Yes.
>
> > > > It's easy to calculate the balances at any point in the future, so
> we
> > > > can know what payment is required to zero those balances.  However,
> if
> > > > Bob pays off Carol before Carol pays off Dan, Carol still being
> > > > charged interest by Dan for a transaction that she neither initiated
> > > > nor substantially benefitted from.  She should still be able to
> charge
> > > > interest to Bob, and Bob to Alice, until her debt with Dan is
> cleared.
>
> > > Well, she just got money from Bob, she can use it to pay off Dan. (In
> > > reality, she'll use it to pay off her highest-interest debt, whether
> > > that's with Dan or someone else.)
>
> > Good point.  What about the case of through payments cancelling debt
> > on an account?  What I really want to avoid is the case of interest
> > being paid on a zero balance.  That means that when the overall
> > account balance is reduced, interest-bearing debt must be erased, not
> > just balanced against debt in the other direction at a different
> > interest rate.
>
> Yes, through payments repay debts before creating new ones.
>
> > Suppose there's an outstanding debt owing from Bob to Carol at 32%
> > interest from a through payment on which Carol is paying 30% up the
> > chain.  What if a payment comes through Carol from a different
> > direction which could cancel that debt?  Musn't Carol ensure that she
> > keeps collecting at least her 30% on what is essentially for her a
> > balance transfer?  (Or alternatively, wipe out some of her debt with
> > the same high interest rate?)  If not, over the course of a few
> > months, she could pay a significant price.
>
> Yes, I'm not sure what to do about this. One possibility would be that any
> time a payment comes through that cancels a 30%-interest-bearing debt,
> that
> Carol *charge* 30% on that through payment (or on whatever part of the
> payment is cancelling the debt). I'm not sure if that's the right
> solution.
> It would certainly leave Carol even, but it doesn't *feel* right...
>
> > The difference with through payments cancelling debt vs. cash is that
> > one can presumably route cash in whatever direction one wants, to
> > cancel the highest-interest debt, but one cannot route through
> > payments however one wants...
>
> One can influence the routing by charging different interest in different
> directions.
>
> > > > In my opinion, interest-rate imbalances along the payment chain are
> > > > much more cleanly (although not always as fairly) handled using
> > > > transaction fees, which propagate naturally back to the payer.  I
> > > > think most users would prefer a great increase in simplicity and
> > > > intuitiveness to a small (and most often likely very small) increase
> > > > in fairness.
>
> > > I'm not sure transaction fees are particularly simple.
>
> > > Transaction fees also introduce friction into the system, while
> interest
> > > rates do not. This may be a good thing or a bad thing, but it
> certainly
> > > is a different species of charge.
>
> > I think the example above shows how interest rates can introduce quite
> > a friction into the system...
>
> Well, friction in the sense that a transaction itself costs something.
>
> For instance, circular debts are no problem, even with interest (as long
> as
> it's all at the same rate); you might cancel them if you feel like it, but
> they make no difference. With transaction fees, they *do* make a
> difference:
> cancelling them costs something, but having them around makes some
> transactions more expensive (because they have to go the long way around
> the
> circle).
>
> Similarly, if you have debt at an interest rate and you're trying to find
> a
> path with lower interest, with transaction fees you have to consider the
> one-off cost of the transaction versus the continuous interest charge.
>
> Now, friction is not necessarily a bad thing; it can make a system more
> stable. Is it desirable in this particular case, though?
>
>
> Jiri
> --
> Jiri Baum <ji...@ba...>
> http://www.baum.com.au/~jiri
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Jiri B. <ji...@ba...>]

Hello,

Stanislav:
> > 2. Ability of each person to issue various forms of debts. At least two
> > 'payable on demand' and 'payable on <date>'.

Evgeni:
> I agree. But I see a problem with 'payable on <date>' - this means that
> the 'payable on <date>'-unit would change it's value over the time (being
> more precious near the due-date). It occurs to me that Ripple-units have to
> hold time-translation invariance or at least not to have bias toward change
> of it's value over the time.

Why not?

Accounts denominated in gold will tend to have a biased tendency compared to 
dollars, as will (in general) those denominated in company shares, CPI, real 
estate or bank deposit.

Contrairwise, "John Smith's time bucks" will decline in value, predictably in 
line with his remaining life expectancy and unpredictably with his fitness.

> > 3. Concept of interest will be introduced implicitly by his creditors
> > insisting on discounts for delayed payment. For example, they will
> > either accept his '$100 on demand' or require '$110 in three months'.
> > for Ripple these are just two different kinds of money.

> I will try to summarise the ideas if I correctly have understood what you
> said.

> Lenders could introduce interest by:
> 1) "embedding" it into the nature of Ripple-units.

Yes, that's been the one I've been suggesting, with the addition that the 
nodes would know of the embedding and be able to manipulate it.

However, as I wrote in the other post, this can be done by a plug-in in an 
interoperable fashion, so those who want to participate in charging / paying 
interest can do so while those who don't will simply see a lot of rare but 
easily convertible currencies.

Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] =?iso-8859-1?q?Interest_as_pseudo-currency_=28R?= =?iso-8859-1?q?e=3A_FAQ=09pre-existing_debt_-_procedure_not_atomic?= =?iso-8859-1?q?=29?=

[Jiri B. <ji...@ba...>]

Hello,

Stanislav Mazhara:
> 'Real' money have liquidity for reason (2) - everybody accepts money
> because they believe that everybody accepts money. It's not (1) because
> government money are backed only with 'full faith and credit' which is
> kind off difficult to deliver :)

I think you're over-simpifying this a little...

- When monetary systems started, they *were* backed; all money could be 
converted into silver and/or gold and the last vestiges of that went away as 
recently as the 1960s. It's quite possible that it's running on pure inertia 
now (and may one day run out).

- Money is "legal tender". Paying a debt with money clears the debt whether or 
not the creditor accepts it. Courts will no longer enforce the debt.

- Money is also legal tender for paying taxes, fines, government fees and 
charges.

...
> Interest rates will be created implicitly through exchange rates. Or
> discount rates in this case.

It would be convenient, though, for nodes to be able to manipulate them. 

However, that can be done by a plug-in! 

Nodes that have the interest rate plug-in will be able to manipulate interest 
while all other nodes will treat it as just another currency - they can pass 
it along, hold it, buy stuff with it, no different to any other currency.

Would that be an acceptable compromise?


Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Stanislav M. <qe...@co...>]

On Wed, 2006-10-18 at 03:10 +1000, Jiri Baum wrote:
> Hello,
> 
> Stanislav Mazhara:
> > 'Real' money have liquidity for reason (2) - everybody accepts money
> > because they believe that everybody accepts money. It's not (1) because
> > government money are backed only with 'full faith and credit' which is
> > kind off difficult to deliver :)
> 
> I think you're over-simpifying this a little...

Of course I am! I could not put here complete money theory due to lack
of space and knowledge :)

> 
> - When monetary systems started, they *were* backed; all money could be 
> converted into silver and/or gold and the last vestiges of that went away as 
> recently as the 1960s. It's quite possible that it's running on pure inertia 
> now (and may one day run out).

True. Even before money were backed, they were commodity money -
precious metal itself cut in convenient weights and stamped for
assurance. These were *real* money, valuable by themselves without
anyone needing to back them.

By the way, money were backed my mere promise anyway. That is,
government would accept ounce of gold and issue a paper banknote payable
on demand. But that was just a promise... which was broken all too
often.

In this sense government *backed* money are not that different from
individual backed.

> 
> - Money is "legal tender". Paying a debt with money clears the debt whether or 
> not the creditor accepts it. Courts will no longer enforce the debt.
> 
> - Money is also legal tender for paying taxes, fines, government fees and Absol
> charges.

True. That is more important distinction, because here government money
are backed by physical coercion - something that few of us have.


> 
> ...
> > Interest rates will be created implicitly through exchange rates. Or
> > discount rates in this case.
> 
> It would be convenient, though, for nodes to be able to manipulate them. 
> 
> However, that can be done by a plug-in! 

Absolutely. Plug-in, add-on, value added service whatever!

> 
> Nodes that have the interest rate plug-in will be able to manipulate interest 
> while all other nodes will treat it as just another currency - they can pass 
> it along, hold it, buy stuff with it, no different to any other currency.
> 
> Would that be an acceptable compromise?

Come to think about it it's not even a compromise - as least with me. I
am all for keeping Ripple as simple as distributed and as decentralized
as possible. Kind of TCP/IP layer of financial system.

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Stanislav M. <qe...@co...>]

> 
> I agree. But I see a problem with 'payable on <date>' - this means
> that
> the 'payable on <date>'-unit would change it's value over the time
> (being 
> more precious near the due-date). It occurs to me that Ripple-units
> have to 
> hold time-translation invariance or at least not to have bias toward
> change
> of it's value over the time.

True. But this is not a problem for Ripple because it should be
concerned about nominal value only. This is still '$1 payable on demand
by XXX'. Market valuation of this obligation will vary wildly based on
time, individual trustworthiness, and even based on creditor. Your
friend who knows you might take your promise at face value. Complete
stranger will take take it all - value it at 0. 

Basically that is the whole point of Ripple - to facilitate propagation
of real market value of personal obligations and make it as close as
possible to their nominal (declared) value.

> 
> > 3. Concept of interest will be introduced implicitly by his
> creditors
> > insisting on discounts for delayed payment. For example, they will 
> > either accept his '$100 on demand' or require '$110 in three
> months'.
> > for Ripple these are just two different kinds of money.
> 
> I will try to summarise the ideas if I correctly have understood what
> you said. 
> 
> Lenders could introduce interest by: 
> 1) "embedding" it into the nature of Ripple-units.
> 2) charging subscription-like fees on Ripple account. For example
> $15 per year for increasing Ripple's credit limit by $1,000. This
> would 
> be a good compensation for the risk lender exposes himself on.
> 3) choosing appropriate exchange-rates for Ripple-transactions
> 4) ...something else...?
> 

All of the above I would say. There is a notion of 'unit of account' in
Ripple. It specifies some most obvious units of accounts like national
currencies, joules (although I would be hard pressed to imagine how I
could deliver across the globe 10G joules I promised for that nice
screensaver I bought :).

Nothing stops anybody from creating this unit of account: "I will pay $1
each month for 12 months in a row" and then try to use it to buy someone
else obligation 'I will pay $10 right now'. See? We just created
installment interest bearing loan without even noticing it. From Ripples
perspective all that happened is that two persons created some
obligations and exchanged them. Creditor can collect 6 payments and then
re-sell this obligation obviously for less - say $5.5

In general different units of account represent different obligations or
promises. I envision hundreds of different units of account. Of course,
in order for them to be liquid they better be 'standard'. There might be
public repositories of standard contracts that everybody familiar with.
Units.

Each unit of account should actually be a a person's digital signature
of actual contract text that specifies it. That way it does not depend
on some trusted repository that stores its meaning. All one has to do is
to post signed and timestamped contract text online. Then before
accepting this unit of account person would search for its fingerprint,
check signature - make sure it really belongs to payer and verify
contract text.

But again, actual contract meaning is a concept extraneous to Ripple.
For Ripple they should just opaque strings.

Re: [Ripple-protocol] =?iso-8859-1?q?Interest_as_pseudo-currency_=28R?= =?iso-8859-1?q?e=3A_FAQ=09pre-existing_debt_-_procedure_not_atomic?= =?iso-8859-1?q?=29?=

[Jiri B. <ji...@ba...>]

Hello,

Stanislav:
> For Ripple they should just opaque strings.

Actually, I think it would be good if they were a bit more structured than 
that. I agree that it should be possible for a node to treat the unit of 
account as opaque; but it would also be good if other nodes could find 
meaning within them (those that have the corresponding plug-in).

Consider your unit "I will pay $1each month for 12 months in a row". That can 
be treated by ripple as opaque; but if it can also be expressed in a 
machine-readable form:

unit A: "after <date> I will exchange this for $1 and 1B"
unit B: "after <date> I will exchange this for $1 and 1C"
...
unit K: "after <date> I will exchange this for $1 and 1L"
unit L: "after <date> I will exchange this for $1".

Indeed, machine-readable is probably the only way to make any sense of those 
units at all...


Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Evgeni P. <epa...@gm...>]

Stanislav:
> > Nothing stops anybody from creating this unit of account: "I will pay $1
> > each month for 12 months in a row" and then try to use it to buy someone
> > else obligation 'I will pay $10 right now'. See? We just created
> > installment interest bearing loan without even noticing it. From Ripples
> > perspective all that happened is that two persons created some
> > obligations and exchanged them. Creditor can collect 6 payments and then
> > re-sell this obligation obviously for less - say $5.5

Juri:
> Consider your unit "I will pay $1each month for 12 months in a row". That
can
> be treated by ripple as opaque; but if it can also be expressed in a
> machine-readable form:
>
> unit A: "after <date> I will exchange this for $1 and 1B"
> ...

I thing things are becoming needlessly complicated here! Instead why don't
we
try to follow on-demand-payment metaphor. Thus the ripple-account-unit would
be
"I will pay $1 each month for 12 months in a row starting at the moment you
ask me"
(Let us name this unit "IWP1$EMF12YSMYAM").

Example:
- Alice owes Bob 5 "IWP1$EMF12YSMYAM"s.
- Bob requires 2 "IWP1$EMF12YSMYAM"s from Alice.
- From that time along Alice owes 3 "IWP1$EMF12YSMYAM"s to Bob and
we will have 2 "IWP1$EMF12YSMYAM"-payments from Alice to Bob being in
progress.

Notice that "IWP1$EMF12YSMYAM"-units itself are time-invariant.
On the other hand "IWP1$EMF12YSMYAM"-payments being in progress could
potentially form a whole family on ripple-account-units:

unit xxx1: "IWP1$EMF12YSMYAM"-in-progress-payment being at month 1
unit xxx2: "IWP1$EMF12YSMYAM"-in-progress-payment being at month 2
...

but I think the latter family of units is not suitable for Ripple. How we
are
going to keep track of all unit-transitions periodically taking place? I
mean:
xxx1 --> xxx2 ---> xxx3 .... ---> xxx12 ----> none (and that is going to
happen
every month!) We could have some plug-in responsible for doing transitions
but
this is  to me a quite pervert misuse of Ripple (especially if we handle
those
transitions internally using some complex data-structures)!

A am really eager to see ripple-unit being handy and not being
time-invariant also.




On 10/17/06, Jiri Baum <ji...@ba...> wrote:
>
> Hello,
>
> Stanislav:
> > For Ripple they should just opaque strings.
>
> Actually, I think it would be good if they were a bit more structured than
> that. I agree that it should be possible for a node to treat the unit of
> account as opaque; but it would also be good if other nodes could find
> meaning within them (those that have the corresponding plug-in).
>
> Consider your unit "I will pay $1each month for 12 months in a row". That
> can
> be treated by ripple as opaque; but if it can also be expressed in a
> machine-readable form:
>
> unit A: "after <date> I will exchange this for $1 and 1B"
> unit B: "after <date> I will exchange this for $1 and 1C"
> ...
> unit K: "after <date> I will exchange this for $1 and 1L"
> unit L: "after <date> I will exchange this for $1".
>
> Indeed, machine-readable is probably the only way to make any sense of
> those
> units at all...
>
>
> Jiri
> --
> Jiri Baum <ji...@ba...>
> http://www.baum.com.au/~jiri
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Ripple-protocol mailing list
> Rip...@li...
> https://lists.sourceforge.net/lists/listinfo/ripple-protocol
>

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Ryan F. <rf...@gm...>]

On 10/17/06, Stanislav Mazhara <qe...@co...> wrote:
> Nothing stops anybody from creating this unit of account: "I will pay $1
> each month for 12 months in a row" and then try to use it to buy someone
> else obligation 'I will pay $10 right now'. See? We just created
> installment interest bearing loan without even noticing it. From Ripples
> perspective all that happened is that two persons created some
> obligations and exchanged them. Creditor can collect 6 payments and then
> re-sell this obligation obviously for less - say $5.5

I really like this idea.  All that's needed is a specification of how
to convert into regular units, and then it's perfectly usable.

>
> In general different units of account represent different obligations or
> promises. I envision hundreds of different units of account. Of course,
> in order for them to be liquid they better be 'standard'. There might be
> public repositories of standard contracts that everybody familiar with.
> Units.
>
> Each unit of account should actually be a a person's digital signature
> of actual contract text that specifies it. That way it does not depend
> on some trusted repository that stores its meaning. All one has to do is
> to post signed and timestamped contract text online. Then before
> accepting this unit of account person would search for its fingerprint,
> check signature - make sure it really belongs to payer and verify
> contract text.

I would probably do it this way:

* Units are specified by URIs
* Account-creation messages contain the text of the account contract
which specifies the units URI and how to convert a real-valued amount
given in account units into generally recognized units, and are signed
by both parties.
* Transaction promise/receipt messages contain the units URI and are
signed by both parties.

The effect is the same I think.

>
> But again, actual contract meaning is a concept extraneous to Ripple.
> For Ripple they should just opaque strings.
>

Right.  The words are for people to fight over.  All the machine has
to know is how to convert.

Ryan

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Stanislav M. <qe...@co...>]

> ...
> 
> but I think the latter family of units is not suitable for Ripple. How
> we are 
> going to keep track of all unit-transitions periodically taking place?
> I mean:
> xxx1 --> xxx2 ---> xxx3 .... ---> xxx12 ----> none (and that is going
> to happen 
> every month!)

We don't! Ripple does not keep track of unit-transitions -- this is part
of persons promise and it is up to that person to keep it. Ripple does
not keep track of contract parties performance.

>  We could have some plug-in responsible for doing transitions but 
> this is  to me a quite pervert misuse of Ripple (especially if we
> handle those 
> transitions internally using some complex data-structures)!

It would not. Ripple itself should be simple, open, transparent and
decentralized system of accounting. People should be able to build on
top of it all kinds of contracts.

I got more to say about machine readable contracts by the way. Writing
another post..

Re: [Ripple-protocol] =?iso-8859-1?q?Interest_as_pseudo-currency_=28R?= =?iso-8859-1?q?e=3A_FAQ=09pre-existing_debt_-_procedure_not_atomic?= =?iso-8859-1?q?=29?=

[Jiri B. <ji...@ba...>]

Hello,

Evgeni:
> > but I think the latter family of units is not suitable for Ripple. How
> > we are going to keep track of all unit-transitions periodically taking
> > place? I mean: xx1 --> xxx2 ---> xxx3 .... ---> xxx12 ----> none (and]
> > that is going to happen every month!) 

Stanislav:
> We don't! Ripple does not keep track of unit-transitions -- this is part
> of persons promise and it is up to that person to keep it. Ripple does
> not keep track of contract parties performance.

In fact, the way I phrased them, it's very close to any other Ripple unit 
anyway.

A "normal" ripple unit says "IOU $1".

I only make two extensions to this:

1) maturation: "after <date>". However, nothing needs to be done on that date; 
the unit just becomes payable on demand, like normal ripple units.

2) basket of currencies: "USD 0.60 and EUR 0.40".


While unit A might mature in January, that's not a problem. You can keep 
trading with it. You might go to settle with the other person in April, at 
which point he'd give you $4 and 1 unit E. However, as with most ripple 
units, you might well never settle and just keep trading the IOUs.


As far as ripple is concerned, this should all be an opaque (URI, hash) pair. 

It's even irrelevant whether the contract is machine-readable or not - it 
could just be plain English. Making it machine-readable would make some 
operations easier, though (for instance, automatically determining an 
exchange rate for a "basket" unit based on the exchange rates of the 
components).


Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Stanislav M. <qe...@co...>]

On Wed, 2006-10-18 at 04:33 +1000, Jiri Baum wrote:
> Hello,
> 
> Stanislav:
> > For Ripple they should just opaque strings.
> 
> Actually, I think it would be good if they were a bit more structured than 
> that. I agree that it should be possible for a node to treat the unit of 
> account as opaque; but it would also be good if other nodes could find 
> meaning within them (those that have the corresponding plug-in).
> 
> Consider your unit "I will pay $1each month for 12 months in a row". That can 
> be treated by ripple as opaque; but if it can also be expressed in a 
> machine-readable form:
> 
> unit A: "after <date> I will exchange this for $1 and 1B"
> unit B: "after <date> I will exchange this for $1 and 1C"
> ...
> unit K: "after <date> I will exchange this for $1 and 1L"
> unit L: "after <date> I will exchange this for $1".
> 
> Indeed, machine-readable is probably the only way to make any sense of those 
> units at all...

Absolutely! Machine executable contracts is the way to go, but that
should not be a Ripple's task. Ripple itself just passes contracts back
and forth based on instructions given to it by users - be it human
beings or automated agents.


This idea is called 'smart contracts' (see wikipedia).

Ideally contract is a protocol which algorithmically defines who, what,
how and in what order should do. And also what to do is somebody is not
doing what he is supposed to do. Contract is an algorithm that should be
interpreted and executed. As we all know algorithms are best written and
interpreted using programming languages and computers.

Unfortunately historically contracts are written in vague and obscure
languages (human languages) that are so hard to interpret that we
actually have to pay fortunes to lawyers, arbitrators, mediators, courts
to interpret them for us.

Wouldn't it be nice to create contract in some formal executable
language and have computer interpret it? So in case of a dispute all
parties can enter contract data in it and get back the same result?

It would be even better to make this contract self-executable. Of
course, it is not possible in all cases, but in many cases it is. Think
about online sales, auctions, other electronic goods exchanges.

It would especially suit things like installment loan - like the one
Jiri described. Both side draft (program!) contract. Run it in dry-run
mode and test it. Than they run it on their nodes and it performs all
these steps. Alternatively there could be hosted solution - trusted
third party service that runs these contracts. Both parties will
digitally sign in and submit to that host.

But again - this is all complicated stuff and it belongs to a layers
above Ripple.

Re: [Ripple-protocol] =?iso-8859-1?q?Interest_as_pseudo-currency_=28_?= =?iso-8859-1?q?Re=3A=09FAQ=09pre-existing_debt_-_procedure_not_ato?= =?iso-8859-1?q?mic=29?=

[Jiri B. <ji...@ba...>]

Hello,

Jiri:
> > Consider your unit "I will pay $1each month for 12 months in a row". That
> > can be treated by ripple as opaque; but if it can also be expressed in a
> > machine-readable form:

> > unit A: "after <date> I will exchange this for $1 and 1B"
> > unit B: "after <date> I will exchange this for $1 and 1C"
> > ...
> > unit K: "after <date> I will exchange this for $1 and 1L"
> > unit L: "after <date> I will exchange this for $1".

> > Indeed, machine-readable is probably the only way to make any sense of
> > those units at all...

Stanislav:
> Absolutely! Machine executable contracts is the way to go, but that
> should not be a Ripple's task. Ripple itself just passes contracts back
> and forth based on instructions given to it by users - be it human
> beings or automated agents.

Yes. 

Note that technically we're talking about "negotiable instruments" rather than 
contracts as such. This has some consequences, the chief among them being 
that we need to have the equivalent of "bond coupons" to keep track of how 
many payments remain to be made. See wikipedia: coupons (bond).

> It would especially suit things like installment loan - like the one
> Jiri described. 

One nice thing about a URI is that it can have parameters; thus, a loan like 
this might be represented by something like:

http://www.example.com/ripple/loans/installment?firstpay=20070101&period=month&length=12

Once the first repayment has been made, the remaining loan would be 
represented by:

http://www.example.com/ripple/loans/installment?firstpay=20070201&period=month&length=11

(clip one coupon off and adjust the date)


As I noted in the other post, I don't imagine this running magically; as far 
as ripple is concerned, this would work as a settlement. The only difference 
would be that instead of settling in cash, the parties would settle in a 
combination of cash and another ripple unit.

> But again - this is all complicated stuff and it belongs to a layers
> above Ripple.

Yes. Having an URI in the "unit of currency" field will support those layers.


Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Jiri B. <ji...@ba...>]

Hello,

Ryan:
> I would probably do it this way:

> * Units are specified by URIs

Yes!

Much more sensible than transmitting around big blobs of XML for every 
five-cent transaction.

Note that they should probably also have a hash of the document, to prevent 
change (unless the URI completely specifies the contract or already contains 
a secure hash). So a unit specification will normally be a (URI, hash) pair.


Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Stanislav M. <qe...@co...>]

On Wed, 2006-10-18 at 16:44 +1000, Jiri Baum wrote:
> Hello,
> 
> Ryan:
> > I would probably do it this way:
> 
> > * Units are specified by URIs
> 
> Yes!
> 
> Much more sensible than transmitting around big blobs of XML for every 
> five-cent transaction.
> Note that they should probably also have a hash of the document, to prevent 
> change (unless the URI completely specifies the contract or already contains 
> a secure hash). So a unit specification will normally be a (URI, hash) pair.
> 

URI+HASH is a MUCH better approach. I was thinking just of hash and that
you would need to go to some search engine to find text of contract. But
combining it with URI is a win-win. We just need to be sure that
contract text is mirrored across multiple servers. Just to prevent
problems with sudden 404 on that URI.

There is another security hole here - hash itself only guarantees text
integrity. It does not prove that some person actually took that
obligation. After all I can myself compute sha1 of 'Ryan owes Stan
$1M' :)

So instead of hashes we should probably use digital signatures and then
you'd just pass signature fingerprint in URI - 20 bytes.

Re: [Ripple-protocol] =?iso-8859-1?q?Interest_as_pseudo-currency_=28R?= =?iso-8859-1?q?e=3A_FAQ=09pre-existing_debt_-_procedure_not_atomic?= =?iso-8859-1?q?=29?=

[Jiri B. <ji...@ba...>]

Hello,

Jiri:
> > So a unit specification will normally be a (URI, hash) pair.

Stanislav:
> URI+HASH is a MUCH better approach. I was thinking just of hash and that
> you would need to go to some search engine to find text of contract. 

Well, in ripple, you could always ask a node which already handles that 
currency... but yes, URI+hash is better.

> But combining it with URI is a win-win. We just need to be sure that
> contract text is mirrored across multiple servers. Just to prevent
> problems with sudden 404 on that URI.

The ripple nodes that have accounts in that currency will probably cache it.

> There is another security hole here - hash itself only guarantees text
> integrity. It does not prove that some person actually took that
> obligation. After all I can myself compute sha1 of 'Ryan owes Stan
> $1M' :)

As Ryan wrote, the signature is on the transactions actually creating the 
obligation.

Names of parties generally don't appear in the currency definitions anyway; 
the definitions are always of the form "IOU <something>", with ripple 
supplying the identities of the I and the U. Ripple has mechanisms for 
certifying those identities, but that's nothing to do with the currency 
definition.


Jiri
-- 
Jiri Baum <ji...@ba...>                   http://www.baum.com.au/~jiri

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Ryan F. <rf...@gm...>]

On 10/17/06, Jiri Baum <ji...@ba...> wrote:
> Hello,
>
> Ryan:
> > I would probably do it this way:
>
> > * Units are specified by URIs
>
> Yes!
>
> Much more sensible than transmitting around big blobs of XML for every
> five-cent transaction.
>
> Note that they should probably also have a hash of the document, to prevent
> change (unless the URI completely specifies the contract or already contains
> a secure hash). So a unit specification will normally be a (URI, hash) pair.

All important Ripple messages are digitally signed, so there's no need
to worry about alterations happening after the fact.

Ryan

Re: [Ripple-protocol] Interest as pseudo-currency (Re: FAQ pre-existing debt - procedure not atomic)

[Ryan F. <rf...@gm...>]

I've been thinking about this interest-as-account-unit thing...  I
think what we're really saying here is that it would be nice if the
node software could recognize that some accounts will have different
debt-settlement terms than others:  Some neighbours will repay on
demand, some every month, etc., and the software should be able to
take that into account when converting between them.

But does this need to be part of the protocol?  Couldn't each node
handle this in its own way, depending on the owner's understanding of
his arrangement with each of his neighbours?  Essentially what we're
talking about is transaction fees and when to charge them...  No?

Ryan