Main /
OldInterestPage
Main.OldInterestPage History
Hide minor edits - Show changes to output
Changed line 2 from:
The contents below are deprecated, but may still be of historical interest. At one point ripple project was going to have interest, along the following lines.
to:
The contents below are deprecated, but may still be of historical interest. At one point ripple project was going to be interest-aware, along the following lines.
Added lines 1-108:
----
The contents below are deprecated, but may still be of historical interest. At one point ripple project was going to have interest, along the following lines.
----
'''Current plans'''
Since it is impossible to stop two mutually-consenting people from charging interest on each other's obligations, Ripple will acknowledge this by including an interest rate for each account partner so these can be formalized in the Ripple protocol. Interest charges will not be passed back along payment chains.
''Note: The following is a discussion of how to pass interest charges fairly back along payment chains.''
'''Tracking interest on accounts'''
To start with, nodes should be able to charge interest on balances owed by their neighbours. They should be able to declare the rate they will charge ahead of time to each neighbour so there are no surprises.
Interest on a balance has two parameters: rate and compounding period. To simplify things, always compound continuously (the difference in practice is usually negligible anyway). The rate is a little more complicated, each intermediary's interest charges may get passed back along the payment chain, but 1% compounded plus 2% compounded doesn't give 3% compounded over the same time!
This shows the need to keep a separate balance for ''each interest rate'' that is being charged on the account. And there may be many, as interest rates can pile up on a transaction.
Actual interest charges could be calculated on the average balances for each interest rate over a period and charged to the main balance at the end of the period.
For example, suppose A owes B 100: A's balance with B is -100. A's outstanding interest balances are -200 at 2%, -100 at 5%, and 50 at 3% (the latter interest is owed to him by B).
To give an example of how interest would be calculated in this situation, this measn that at the end of a month, A's balance adjustment for interest charges would be:
|| border=0
|| -200 * (exp(.02/12) - 1) =|| -0.3336||
|| -100 * (exp(.05/12) - 1) =|| -0.4175||
|| 50 * (exp(.03/12) - 1) =|| +0.1252||
|| || -------------||
|| || -0.6260||
'''Passing interest back along the chain'''
Nodes must have the ability to pass interest charges back along a payment chain. Interest charges would be declared in the path-available message. Each rate charged would go in a list, with the principal it is being charged to, in transaction units. There could be repeats. For example, if three intermediaries charged 2% on the entire 1000-unit transaction, the list would look like: 2% on 1000, 2% on 1000, 2% on 1000. This could simplify to 2% on 3000 -- not 6% on 1000! This shows the need to keep balances for each interest rate separate from the main balance -- they are not the same.
Of course, any intermediary may report back any interest charges that it wants. Inflating the interest charges will only decrease the chance of that path being used. Nodes/implementations may also decide not to pass on interest charges for simplicity. Of course, this means they may end up paying for the privilege of being an intermediary, if other nodes are charging interest. They may also round off interest rates in order to simplify data storage.
The fact that balances for calculating interest are kept separate from the main account balance means that there may be interest charges even when the main balance is zero. But there is nothing preventing nodes from adopting strategies to minimize this effect.
A simple example is that I may owe my neighbour 100 at 5%, but generally charge her only 2% on balances owing to me. When the chance comes for her to send me IOUs, I may decide to charge her 5% specifically to zero out that 5% balance -- in other words, demand my outstanding IOUs at 5% back in payment. My neighbour will naturally pass that 5% down the chain, because presumatbly she charged it to defray charges from another of her neighbours during a transaction, and still needs to collect it somewhere.
A more complex example would involve weighted targetting of each outstanding interest balance based on the ratio of the payment amount to the overall main balance. Generally, adding these interest charges on to a through payment will make that path less appealing to the payer. Note that nodes may attach negative interest on a certain principal to a payment -- which would be interpreted as positive interest on a negative principal -- in order to make payment paths more appealing.
The simplest, and possibly the fairest, strategy, though, is to simply ignore existing interest charges on an account and treat each transaction independently.
In any event, to avoid getting "stuck" with a high interest chunk in perpetuity, nodes should be careful to accept transactions that only consist of comfortably low-interest chunks. This ensures that it will be possible and likely that interest charges will be wiped away by future transactions.
'''Releasing interest charges'''
Since each intermediary presumably passes back interest charges in order to defray their charges for participating in the payment chain, there ought to be a mechanism for indicating when the balance that originated the interest charge has been settled, and those charges no longer need to be defrayed. A message could be passed back up the payment chain that originally caused the interest charge informing each intermediary of its full or partial release. The message could take the form of a 0-unit payment with a negative balance for the appropriate interest rate.
Why would anybody voluntarily reduce the interest they are collecting? If one's neighbours are following the strategy of targetting high-interest balances to zero, it makes payment paths that cancel out their neighbours' obligations to them more attractive. It's also not nice to take advantage of your neighbours...
'''Exceeding credit limits'''
Interest charges may bring an account into overdraft. Deal with it.
'''Closing accounts'''
When an account is closed, no more interest charges may be collected, even if there are still some nonzero balances for some interest rates.
'''Addendum and comment on the notion of interest'''
It is proposed by this user (whos comments will likely be removed by system admin - ha) that compounding interest of any form is usury and morally should not be implemented. Also, interest creates a mathematical imbalance whereby the outstanding debt in a currency can never be repaid except by taking out more debt. The notion of applying interest to Hour balances when the previous statement is taken into consideration then just becomes silly.
-> @@Reply by some guy:@@ I don't think that's true. Interest ''can'' in fact be payed back. The only thing that has to happen to make that possible is that the ones who collect the interest have to spend the "money" on something. The borrowers can then use this money to pay back their debts+interest.
-> What should be taken into account IMHO, though, is to allow for the possibility of ''negative'' interest rates. It may very well happen that more people want to lend money than to borrow it (at any given interest rate). In that case the interest rate has to drop to bring the two sides of the market into equilibrium, if necessary ''below zero''.
-> @@Reply by some girl:@@ Absolutely right. Any interest rate -- positive, negative, or zero -- should be supported.
-> As for the notion that compound interest can never be fully repaid, Some Guy hits the nail on the head. It's true that with positive interest if I borrow a widget I'll eventually have to give two widgets back in return. People agree to terms like that because they want the one widget ''now''. They then put in extra labor (or whatever) to acquire the second widget (the interest) to pay back. In a "you scratch my back, I'll scratch yours next year" arrangement, interest is what you pay for getting your back scratched now. Only with a positive interest rate can such an arrangement be envy-free (else both parties want to have their back scratched first).
''' Conflicts with simplicity and neighbourliness '''
It seems to make sense to provide an API so that plugins can be independently developed to
cover charges etc. If this concept takes off, many will want to implement servers and nodes
without making charges, and will prefer a system where these are not included by default. Others might see this as a commercial opportunity and charge commission where the endpoints of a chained transaction involving them are between non-neighbours. Let them do so and risk being undercut. If those keeping accounts with neighbours make charges or don't based on
bilateral agreements, there is no need to complicate the protocol by making allowance for these. There will also be all kinds of unneccessary disagreements about the ethics etc. so why not keep this bit out of the main protocol and let those keeping accounts and servers apply third party charging modules based on an API that allows those favouring particular policies to
program and implement these, and those disliking such policies to avoid neighbouring with
charging nodes.
''' Treating interest as pseudo-currencies '''
Effectively, debt at a particular interest rate is almost in a separate currency with a predictable, gradually changing exchange rate.
* Basically, all debts at the same interest rate can be re-calculated to refer to the same base date.
** Once they refer to the same date, they can be added together.
** Example: If I borrow $100 at 3.5% today, it would instead be recorded as a loan of $78.82 (as of 2000); half a year later, I repay $101.77, which is converted to a repayment of $78.82 (as of 2000).
* All debts can be converted to a "current value" - the amount of money it would take to pay them off right now.
** They can be set off against each other at the current value (even if they have different interest rates).
** This is how they should be displayed to the user, regardless of how they're stored internally.
*** Continuing the above example, I will see the debt as "$100.00 at 3.5%" today and "$100.01 at 3.5%" tomorrow.
* Intermediary offers with interest would be treated similarly to offers of a different currency.
** To charge interest on a plain dollar amount of $100, just say so and pass the rate along.
** To charge interest on something that already has interest, simply add the two rates together.
*** 1% + 2% does in fact equal 3%.
**** This is because [@exp(q*t) * exp(r*t) = exp((q+r)*t)@].
**** In words, this means is that you're borrowing interest for the second person from the first.
* Apart from the predictable exchange rate, these would be currencies like any other, so they could do anything a currency can do - they could be loaned, used for payment, rippled, etc.
** In practice, they probably wouldn't be used that way in general, but the concept helps designing the special cases where they are in fact used.
** For instance, it answers the question of what happens when an account is closed: all the balances need to be zero first.
Notes:
* Instead of a fixed base date (such as 1.1.2000), the implementation could use a different base date at each calculation (obvious choices being "date of youngest debt" and "now"). That's just an implementation detail, though.
** Theoretically identical, but leads to different kinds of rounding errors.
The contents below are deprecated, but may still be of historical interest. At one point ripple project was going to have interest, along the following lines.
----
'''Current plans'''
Since it is impossible to stop two mutually-consenting people from charging interest on each other's obligations, Ripple will acknowledge this by including an interest rate for each account partner so these can be formalized in the Ripple protocol. Interest charges will not be passed back along payment chains.
''Note: The following is a discussion of how to pass interest charges fairly back along payment chains.''
'''Tracking interest on accounts'''
To start with, nodes should be able to charge interest on balances owed by their neighbours. They should be able to declare the rate they will charge ahead of time to each neighbour so there are no surprises.
Interest on a balance has two parameters: rate and compounding period. To simplify things, always compound continuously (the difference in practice is usually negligible anyway). The rate is a little more complicated, each intermediary's interest charges may get passed back along the payment chain, but 1% compounded plus 2% compounded doesn't give 3% compounded over the same time!
This shows the need to keep a separate balance for ''each interest rate'' that is being charged on the account. And there may be many, as interest rates can pile up on a transaction.
Actual interest charges could be calculated on the average balances for each interest rate over a period and charged to the main balance at the end of the period.
For example, suppose A owes B 100: A's balance with B is -100. A's outstanding interest balances are -200 at 2%, -100 at 5%, and 50 at 3% (the latter interest is owed to him by B).
To give an example of how interest would be calculated in this situation, this measn that at the end of a month, A's balance adjustment for interest charges would be:
|| border=0
|| -200 * (exp(.02/12) - 1) =|| -0.3336||
|| -100 * (exp(.05/12) - 1) =|| -0.4175||
|| 50 * (exp(.03/12) - 1) =|| +0.1252||
|| || -------------||
|| || -0.6260||
'''Passing interest back along the chain'''
Nodes must have the ability to pass interest charges back along a payment chain. Interest charges would be declared in the path-available message. Each rate charged would go in a list, with the principal it is being charged to, in transaction units. There could be repeats. For example, if three intermediaries charged 2% on the entire 1000-unit transaction, the list would look like: 2% on 1000, 2% on 1000, 2% on 1000. This could simplify to 2% on 3000 -- not 6% on 1000! This shows the need to keep balances for each interest rate separate from the main balance -- they are not the same.
Of course, any intermediary may report back any interest charges that it wants. Inflating the interest charges will only decrease the chance of that path being used. Nodes/implementations may also decide not to pass on interest charges for simplicity. Of course, this means they may end up paying for the privilege of being an intermediary, if other nodes are charging interest. They may also round off interest rates in order to simplify data storage.
The fact that balances for calculating interest are kept separate from the main account balance means that there may be interest charges even when the main balance is zero. But there is nothing preventing nodes from adopting strategies to minimize this effect.
A simple example is that I may owe my neighbour 100 at 5%, but generally charge her only 2% on balances owing to me. When the chance comes for her to send me IOUs, I may decide to charge her 5% specifically to zero out that 5% balance -- in other words, demand my outstanding IOUs at 5% back in payment. My neighbour will naturally pass that 5% down the chain, because presumatbly she charged it to defray charges from another of her neighbours during a transaction, and still needs to collect it somewhere.
A more complex example would involve weighted targetting of each outstanding interest balance based on the ratio of the payment amount to the overall main balance. Generally, adding these interest charges on to a through payment will make that path less appealing to the payer. Note that nodes may attach negative interest on a certain principal to a payment -- which would be interpreted as positive interest on a negative principal -- in order to make payment paths more appealing.
The simplest, and possibly the fairest, strategy, though, is to simply ignore existing interest charges on an account and treat each transaction independently.
In any event, to avoid getting "stuck" with a high interest chunk in perpetuity, nodes should be careful to accept transactions that only consist of comfortably low-interest chunks. This ensures that it will be possible and likely that interest charges will be wiped away by future transactions.
'''Releasing interest charges'''
Since each intermediary presumably passes back interest charges in order to defray their charges for participating in the payment chain, there ought to be a mechanism for indicating when the balance that originated the interest charge has been settled, and those charges no longer need to be defrayed. A message could be passed back up the payment chain that originally caused the interest charge informing each intermediary of its full or partial release. The message could take the form of a 0-unit payment with a negative balance for the appropriate interest rate.
Why would anybody voluntarily reduce the interest they are collecting? If one's neighbours are following the strategy of targetting high-interest balances to zero, it makes payment paths that cancel out their neighbours' obligations to them more attractive. It's also not nice to take advantage of your neighbours...
'''Exceeding credit limits'''
Interest charges may bring an account into overdraft. Deal with it.
'''Closing accounts'''
When an account is closed, no more interest charges may be collected, even if there are still some nonzero balances for some interest rates.
'''Addendum and comment on the notion of interest'''
It is proposed by this user (whos comments will likely be removed by system admin - ha) that compounding interest of any form is usury and morally should not be implemented. Also, interest creates a mathematical imbalance whereby the outstanding debt in a currency can never be repaid except by taking out more debt. The notion of applying interest to Hour balances when the previous statement is taken into consideration then just becomes silly.
-> @@Reply by some guy:@@ I don't think that's true. Interest ''can'' in fact be payed back. The only thing that has to happen to make that possible is that the ones who collect the interest have to spend the "money" on something. The borrowers can then use this money to pay back their debts+interest.
-> What should be taken into account IMHO, though, is to allow for the possibility of ''negative'' interest rates. It may very well happen that more people want to lend money than to borrow it (at any given interest rate). In that case the interest rate has to drop to bring the two sides of the market into equilibrium, if necessary ''below zero''.
-> @@Reply by some girl:@@ Absolutely right. Any interest rate -- positive, negative, or zero -- should be supported.
-> As for the notion that compound interest can never be fully repaid, Some Guy hits the nail on the head. It's true that with positive interest if I borrow a widget I'll eventually have to give two widgets back in return. People agree to terms like that because they want the one widget ''now''. They then put in extra labor (or whatever) to acquire the second widget (the interest) to pay back. In a "you scratch my back, I'll scratch yours next year" arrangement, interest is what you pay for getting your back scratched now. Only with a positive interest rate can such an arrangement be envy-free (else both parties want to have their back scratched first).
''' Conflicts with simplicity and neighbourliness '''
It seems to make sense to provide an API so that plugins can be independently developed to
cover charges etc. If this concept takes off, many will want to implement servers and nodes
without making charges, and will prefer a system where these are not included by default. Others might see this as a commercial opportunity and charge commission where the endpoints of a chained transaction involving them are between non-neighbours. Let them do so and risk being undercut. If those keeping accounts with neighbours make charges or don't based on
bilateral agreements, there is no need to complicate the protocol by making allowance for these. There will also be all kinds of unneccessary disagreements about the ethics etc. so why not keep this bit out of the main protocol and let those keeping accounts and servers apply third party charging modules based on an API that allows those favouring particular policies to
program and implement these, and those disliking such policies to avoid neighbouring with
charging nodes.
''' Treating interest as pseudo-currencies '''
Effectively, debt at a particular interest rate is almost in a separate currency with a predictable, gradually changing exchange rate.
* Basically, all debts at the same interest rate can be re-calculated to refer to the same base date.
** Once they refer to the same date, they can be added together.
** Example: If I borrow $100 at 3.5% today, it would instead be recorded as a loan of $78.82 (as of 2000); half a year later, I repay $101.77, which is converted to a repayment of $78.82 (as of 2000).
* All debts can be converted to a "current value" - the amount of money it would take to pay them off right now.
** They can be set off against each other at the current value (even if they have different interest rates).
** This is how they should be displayed to the user, regardless of how they're stored internally.
*** Continuing the above example, I will see the debt as "$100.00 at 3.5%" today and "$100.01 at 3.5%" tomorrow.
* Intermediary offers with interest would be treated similarly to offers of a different currency.
** To charge interest on a plain dollar amount of $100, just say so and pass the rate along.
** To charge interest on something that already has interest, simply add the two rates together.
*** 1% + 2% does in fact equal 3%.
**** This is because [@exp(q*t) * exp(r*t) = exp((q+r)*t)@].
**** In words, this means is that you're borrowing interest for the second person from the first.
* Apart from the predictable exchange rate, these would be currencies like any other, so they could do anything a currency can do - they could be loaned, used for payment, rippled, etc.
** In practice, they probably wouldn't be used that way in general, but the concept helps designing the special cases where they are in fact used.
** For instance, it answers the question of what happens when an account is closed: all the balances need to be zero first.
Notes:
* Instead of a fixed base date (such as 1.1.2000), the implementation could use a different base date at each calculation (obvious choices being "date of youngest debt" and "now"). That's just an implementation detail, though.
** Theoretically identical, but leads to different kinds of rounding errors.