Main /
Interest
Main.Interest History
Hide minor edits - Show changes to output
Changed lines 11-15 from:
http://groups.google.com/group/rippleusers/browse_thread/thread/b0154c4cac6dc18d/6af3a857af29b086#6af3a857af29b086
[[Old Interest Page]]
[[Old Interest Page]]
to:
* [[http://groups.google.com/group/rippleusers/browse_thread/thread/b0154c4cac6dc18d/6af3a857af29b086#6af3a857af29b086|ripple users discussion on interest]]
* [[Old Interest Page]]
* [[Old Interest Page]]
Changed lines 7-8 from:
It might be possible to simulate the operation of interest, or something pretty close to it, by using [[multiple nodes]] and [[credit exchange rates]] in some creative way, but we haven't put too much thought into it. Once the protocol is established and the server is built, we expect to see clients doing all sorts of unexpected things :)
to:
It might be possible to simulate the operation of interest, or something pretty close to it, by using [[UsersPartiesAndNodes|multiple nodes]] and [[CreditExchange|credit exchange rates]] in some creative way, but we haven't put too much thought into it. Once the protocol is established and the server is built, we expect to see clients doing all sorts of unexpected things :)
Added lines 7-8:
It might be possible to simulate the operation of interest, or something pretty close to it, by using [[multiple nodes]] and [[credit exchange rates]] in some creative way, but we haven't put too much thought into it. Once the protocol is established and the server is built, we expect to see clients doing all sorts of unexpected things :)
Added lines 14-15:
Changed lines 10-118 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.
----
'''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.
to:
[[Old Interest Page]]
Added lines 1-14:
''' Ripple Does Not Have a Concept Of Interest '''
There has been much discussion on whether ripple should include some kind of functionality to track interest. The current consensus is that it should not.
Ripple clients are, of course, free to have their own notion of interest accounting, but when interacting with a ripple server they make payments and that's it.
See
http://groups.google.com/group/rippleusers/browse_thread/thread/b0154c4cac6dc18d/6af3a857af29b086#6af3a857af29b086
----
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.
----
There has been much discussion on whether ripple should include some kind of functionality to track interest. The current consensus is that it should not.
Ripple clients are, of course, free to have their own notion of interest accounting, but when interacting with a ripple server they make payments and that's it.
See
http://groups.google.com/group/rippleusers/browse_thread/thread/b0154c4cac6dc18d/6af3a857af29b086#6af3a857af29b086
----
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.
----
December 12, 2006, at 01:45 AM
by - philosophy of interest
Added lines 65-68:
-> @@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).
-> 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).
Changed lines 76-77 from:
Effectively, debt at a particular interest rate is almost in a separate currency with a predictable exchange rate.
to:
Effectively, debt at a particular interest rate is almost in a separate currency with a predictable, gradually changing exchange rate.
October 15, 2006, at 06:24 AM
by - interest as pseudo-currency
Changed lines 94-96 from:
* Apart from the predictable exchange rate, this would be a currency like any other, so it could do anything a currency can do - it can be loaned, used for payment, rippled, etc.
**It also answers the question of what happens when an account is closed: all the balances need to be zero first.
**
to:
* 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.
** 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.
October 15, 2006, at 06:19 AM
by - interest as pseudo-currency
Changed line 78 from:
* Basically, all debts at the same interest rate would be re-calculated to refer to the same base date.
to:
* Basically, all debts at the same interest rate can be re-calculated to refer to the same base date.
Deleted line 79:
October 15, 2006, at 06:15 AM
by - interest as pseudo-currency
Added line 100:
** Theoretically identical, but leads to different kinds of rounding errors.
October 15, 2006, at 06:14 AM
by - interest as pseudo-currency
Changed lines 85-86 from:
** 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.
to:
** 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.
*** Continuing the above example, I will see the debt as "$100.00 at 3.5%" today and "$100.01 at 3.5%" tomorrow.
October 15, 2006, at 06:13 AM
by - interest as pseudo-currency
Changed lines 81-83 from:
** Example: If I borrow $100 at 3.5% now, 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
* All debts can be converted to a "current value" - the amount of money it would take to pay them off right now
to:
** 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.
* All debts can be converted to a "current value" - the amount of money it would take to pay them off right now.
Changed lines 87-92 from:
*** Apart from the predictable exchange rate, this would be a currency like any other, so it wouldn't need any special treatment in Ripple. It can be loaned, used for payment, rippled, etc. It also answers the question of what happens when an account is closed: all the balances need to be zero first.
In fact, it would get special treatment: the calculation of the exchange rate should be automatic, and it should be able to combine arbitrary interest rates (and recognise that they ''are'' interest rates on the underlying currency).
* Adding interest: when passed along the chain, interest can in fact be added so that 1% + 2% equals 3%. All this means is that you're borrowing interest for the first person from the second. This is because [@exp(q*t) * exp(r*t) = exp((q+r)*t)@].
* Adding interest: when passed along the chain, interest can in fact be added so that 1% + 2% equals 3%. All this means is that you're borrowing interest for the first person from the second. This is because [@exp(q*t) * exp(r*t) = exp((q+r)*t)@]
to:
* 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, this would be a currency like any other, so it could do anything a currency can do - it can be loaned, used for payment, rippled, etc.
** It also answers the question of what happens when an account is closed: all the balances need to be zero first.
** 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, this would be a currency like any other, so it could do anything a currency can do - it can be loaned, used for payment, rippled, etc.
** It also answers the question of what happens when an account is closed: all the balances need to be zero first.
October 15, 2006, at 06:00 AM
by - interest as pseudo-currency
Changed lines 80-81 from:
to:
Changed lines 91-94 from:
* Adding interest: when passed along the chain, interest can in fact be added so that 1% + 2% equals 3%. All this means is that you're borrowing interest for the first person from the second. This is because [@exp(q*t) * exp(r*t) = exp((q+r)*t)@].
to:
* Adding interest: when passed along the chain, interest can in fact be added so that 1% + 2% equals 3%. All this means is that you're borrowing interest for the first person from the second. This is because [@exp(q*t) * exp(r*t) = exp((q+r)*t)@].
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.
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.
October 15, 2006, at 05:59 AM
by - interest as pseudo-currency
Changed lines 76-77 from:
** The base date can
to:
Effectively, debt at a particular interest rate is almost in a separate currency with a predictable exchange rate.
* Basically, all debts at the same interest rate would be re-calculated to refer to the same base date.
** Once they refer to the same date, they can be added together.
** 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.
** Example: If I borrow $100 at 3.5% now, 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).
* Basically, all debts at the same interest rate would be re-calculated to refer to the same base date.
** Once they refer to the same date, they can be added together.
** 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.
** Example: If I borrow $100 at 3.5% now, 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).
Changed lines 85-93 from:
** They can be set off against each other at the current value (even if they have different interest rates)
user will see "$100.00 at 3.5%" one day and "$100.01 at 3.5%" the next day.
Effectively, debta particular interest rate is almost in a separate currency with a predictable exchange rate. When I borrow money, I get $100 and owe (say) 50 "debt units". In half a year's time, when I want to repay, the exchange rate will be worse, so that I might need to pay $105 to repay those 50 debt units. The trick is that the same "debt unit" currency can be used for all loans at the same interest rate: someone borrowing half a year later would get $100 and owe 47.62 debt units.
Apart from the predictable exchange rate, this would be a currency like any other, so it wouldn't need any special treatment in Ripple. It can be loaned, used for payment, rippled, etc. It also answers the question of what happens when an account is closed: all the balances need to be zero first.
In fact, it would get special treatment: the calculation of the exchange rate should be automatic, and it should be able to combine arbitrary interest rates (and recognise that they ''are'' interest rates on the underlying currency).
Effectively, debt
Apart from the predictable exchange rate, this would be a currency like any other, so it wouldn't need any special treatment in Ripple. It can be loaned, used for payment, rippled, etc. It also answers the question of what happens when an account is closed: all the balances need to be zero first.
In fact, it would get special treatment: the calculation of the exchange rate should be automatic, and it should be able to combine arbitrary interest rates (and recognise that they ''are'' interest rates on the underlying currency).
to:
** 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.
*** Apart from the predictable exchange rate, this would be a currency like any other, so it wouldn't need any special treatment in Ripple. It can be loaned, used for payment, rippled, etc. It also answers the question of what happens when an account is closed: all the balances need to be zero first.
*** In fact, it would get special treatment: the calculation of the exchange rate should be automatic, and it should be able to combine arbitrary interest rates (and recognise that they ''are'' interest rates on the underlying currency).
** 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.
*** Apart from the predictable exchange rate, this would be a currency like any other, so it wouldn't need any special treatment in Ripple. It can be loaned, used for payment, rippled, etc. It also answers the question of what happens when an account is closed: all the balances need to be zero first.
*** In fact, it would get special treatment: the calculation of the exchange rate should be automatic, and it should be able to combine arbitrary interest rates (and recognise that they ''are'' interest rates on the underlying currency).
October 15, 2006, at 05:46 AM
by - interest as pseudo-currency
Changed lines 77-78 from:
* All debts can be converted to a "current value" - the amount of money it would take to pay them off right now; then they can be set off against each other (even if they have different interest rates).
to:
** The base date can be either fixed (eg 1.1.2000) or any convenient date (obvious choices being "youngest debt" and "now").
* 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; the user will see "$100.00 at 3.5%" one day and "$100.01 at 3.5%" the next day.
* 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; the user will see "$100.00 at 3.5%" one day and "$100.01 at 3.5%" the next day.
Changed line 88 from:
* Adding interest: when passed along the chain, interest can in fact be added so that 1% + 2% equals 3%. All this means is that you're borrowing interest for the first person from the second. This is because exp(q*t) * exp(r*t) = exp((q+r)*t).
to:
* Adding interest: when passed along the chain, interest can in fact be added so that 1% + 2% equals 3%. All this means is that you're borrowing interest for the first person from the second. This is because [@exp(q*t) * exp(r*t) = exp((q+r)*t)@].
October 15, 2006, at 05:38 AM
by - interest as pseudo-currency
Changed lines 74-77 from:
''' Treating interest as additional currencies '''
It seeems to me that interest can simply be treated as a separate currency with a predictable exchange rate. When I borrow money, I get $100 and owe (say) 50 "debt units". In half a year's time, when I want to repay, the exchange rate will be worse, so that I might need to pay $105 to repay those 50 debt units. The trick is that the same "debt unit" currency can be used for all loans at the same interest rate: someone borrowing half a year later would get $100 and owe 47.62 debt units.
to:
''' Treating interest as pseudo-currencies '''
* Debts at the same interest rate can be re-calculated to refer to the same base date; then they can be added together.
* All debts can be converted to a "current value" - the amount of money it would take to pay them off right now; then they can be set off against each other (even if they have different interest rates).
Effectively, debt at a particular interest rate is almost in a separate currency with a predictable exchange rate. When I borrow money, I get $100 and owe (say) 50 "debt units". In half a year's time, when I want to repay, the exchange rate will be worse, so that I might need to pay $105 to repay those 50 debt units. The trick is that the same "debt unit" currency can be used for all loans at the same interest rate: someone borrowing half a year later would get $100 and owe 47.62 debt units.
* Debts at the same interest rate can be re-calculated to refer to the same base date; then they can be added together.
* All debts can be converted to a "current value" - the amount of money it would take to pay them off right now; then they can be set off against each other (even if they have different interest rates).
Effectively, debt at a particular interest rate is almost in a separate currency with a predictable exchange rate. When I borrow money, I get $100 and owe (say) 50 "debt units". In half a year's time, when I want to repay, the exchange rate will be worse, so that I might need to pay $105 to repay those 50 debt units. The trick is that the same "debt unit" currency can be used for all loans at the same interest rate: someone borrowing half a year later would get $100 and owe 47.62 debt units.
Changed lines 83-87 from:
Actually, I think that adding
to:
In fact, it would get special treatment: the calculation of the exchange rate should be automatic, and it should be able to combine arbitrary interest rates (and recognise that they ''are'' interest rates on the underlying currency).
* Adding interest: when passed along the chain, interest can in fact be added so that 1% + 2% equals 3%. All this means is that you're borrowing interest for the first person from the second. This is because exp(q*t) * exp(r*t) = exp((q+r)*t).
* Adding interest: when passed along the chain, interest can in fact be added so that 1% + 2% equals 3%. All this means is that you're borrowing interest for the first person from the second. This is because exp(q*t) * exp(r*t) = exp((q+r)*t).
October 14, 2006, at 04:18 PM
by - more on interest as additional currencies
Added lines 80-81:
Well, maybe a little special treatment: the calculation of the exchange rate should be automatic, and it should be able to combine arbitrary interest rates (and recognise that they ''are'' interest rates on the underlying currency).
October 14, 2006, at 04:14 PM
by - repeated "actually" -> actually, in fact
Changed line 82 from:
Actually, I think that adding interest actually is simple: 1% + 2% does equal 3%, as long as you're borrowing interest for the first person from the second (which you would be if the "additional currencies" trick is used).
to:
Actually, I think that adding interest is in fact simple: 1% + 2% does equal 3%, as long as you're borrowing interest for the first person from the second (which you would be if the "additional currencies" trick is used).
October 13, 2006, at 08:08 PM
by - bah, adding interest is easier than that... I think...
Changed line 82 from:
to:
Actually, I think that adding interest actually is simple: 1% + 2% does equal 3%, as long as you're borrowing interest for the first person from the second (which you would be if the "additional currencies" trick is used).
October 13, 2006, at 07:32 PM
by - adding up interest
Added lines 79-82:
''' Adding interest '''
One way to handle adding up interest is to choose the rates well; instead of 1%, 2%, 3% etc, make them 1%, 2.01%, 3.0301% and so on (a geometric series). Then three people each charging 2.01% can be translated to 6.15202% and it all works out.
October 13, 2006, at 06:29 PM
by - interest as additional currencies
Changed lines 72-78 from:
charging nodes.
to:
charging nodes.
''' Treating interest as additional currencies '''
It seeems to me that interest can simply be treated as a separate currency with a predictable exchange rate. When I borrow money, I get $100 and owe (say) 50 "debt units". In half a year's time, when I want to repay, the exchange rate will be worse, so that I might need to pay $105 to repay those 50 debt units. The trick is that the same "debt unit" currency can be used for all loans at the same interest rate: someone borrowing half a year later would get $100 and owe 47.62 debt units.
Apart from the predictable exchange rate, this would be a currency like any other, so it wouldn't need any special treatment in Ripple. It can be loaned, used for payment, rippled, etc. It also answers the question of what happens when an account is closed: all the balances need to be zero first.
''' Treating interest as additional currencies '''
It seeems to me that interest can simply be treated as a separate currency with a predictable exchange rate. When I borrow money, I get $100 and owe (say) 50 "debt units". In half a year's time, when I want to repay, the exchange rate will be worse, so that I might need to pay $105 to repay those 50 debt units. The trick is that the same "debt unit" currency can be used for all loans at the same interest rate: someone borrowing half a year later would get $100 and owe 47.62 debt units.
Apart from the predictable exchange rate, this would be a currency like any other, so it wouldn't need any special treatment in Ripple. It can be loaned, used for payment, rippled, etc. It also answers the question of what happens when an account is closed: all the balances need to be zero first.
Changed lines 1-2 from:
''Note: Right now I'm not planning on including interest charges in the Ripple protocol. Interest-bearing debts probably don't belong in such a fluid system as Ripple.''
to:
'''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.''
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.''
Changed lines 7-10 from:
Interest on a balance has two parameters: rate and compounding period. To simplify things, always compound continuously. 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 is needed 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.
This shows the need to keep a separate balance is needed
to:
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.
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.
Changed lines 58-60 from:
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''.
to:
-> @@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''.
-> 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''.
Changed lines 59-60 from:
What should be taken into account IMHO, though, is to leave the possibility for ''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''.
to:
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''.
Added lines 58-60:
(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 leave the possibility for ''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''.
What should be taken into account IMHO, though, is to leave the possibility for ''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''.
Added lines 1-2:
''Note: Right now I'm not planning on including interest charges in the Ripple protocol. Interest-bearing debts probably don't belong in such a fluid system as Ripple.''
May 08, 2006, at 04:42 PM
by - Keep it simple - but allow an API so others can mess with it
Changed lines 54-63 from:
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.
to:
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.
''' 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.
''' 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.
Changed lines 50-54 from:
When an account is closed, no more interest charges may be collected, even if there are still some nonzero balances for some interest rates.
to:
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.
'''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.
Changed lines 24-27 from:
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.
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.
to:
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.
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.
Changed lines 34-38 from:
Since each intermediary presumably passes back interest charges in order to defray their charges for participating in the payment chain, there ought
to:
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.
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.
Added line 50:
When an account is closed, no more interest charges may be collected, even if there are still some nonzero balances for some interest rates.
Added lines 11-21:
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||
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||
Changed lines 28-42 from:
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. To avoid this counter-intuitive and unappealing situation, nodes may target the interest they charge on particular transactions to specifically zero the interest balances for each rate.
A simple example is that I may owe my neighbour 100 at 5%, but generally charge him only 2% on balances owing to me. When the chance comes for him to send me IOUs, I may decide to charge him 5% specifically to zero out that 5% balance -- in other words, demand my outstanding IOUs at 5% back in payment. 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:
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 owedto him by B).
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||
A simple example is that I may owe my neighbour 100 at 5%, but generally charge him only 2% on balances owing
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
At the end of a month, A's balance adjustment for interest charges would be:
|| border=0
||
||
|| 50 * (exp(.03/12) - 1) =|| +0.1252||
|| || -------------||
|| || -0.6260||
to:
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.
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.
Changed lines 38-42 from:
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 that balance has been settled, and those charges no longer need to be defrayed. Why would anybody voluntarily reduce the interest they are collecting? If one's neighbours are following the strategy of targeting overall interestIt makes payment paths that cancel out their neighbours' obligations to them more attractive.
to:
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 that balance has been settled, and those charges no longer need to be defrayed. Why would anybody voluntarily reduce the interest they are collecting? If one's neighbours are following the strategy of targeting overall interestIt makes payment paths that cancel out their neighbours' obligations to them more attractive.
'''Closing accounts'''
'''Closing accounts'''
Changed lines 24-30 from:
-200 *
-
to:
|| 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||
Changed lines 3-4 from:
To start with, nodes should be able to charge interest on balances owed by their neighbours.
to:
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.
Changed lines 15-17 from:
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.
'''Decreasing the interest
'''Decreasing the interest
to:
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.
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. To avoid this counter-intuitive and unappealing situation, nodes may target the interest they charge on particular transactions to specifically zero the interest balances for each rate.
A simple example is that I may owe my neighbour 100 at 5%, but generally charge him only 2% on balances owing to me. When the chance comes for him to send me IOUs, I may decide to charge him 5% specifically to zero out that 5% balance -- in other words, demand my outstanding IOUs at 5% back in payment. 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:
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).
At the end of a month, A's balance adjustment for interest charges would be:
@@
-200 * (exp(.02/12) - 1) = -0.3336
-100 * (exp(.05/12) - 1) = -0.4175
50 * (exp(.03/12) - 1) = +0.1252
--------
-0.6260
@@
'''Decreasing the interest rate'''
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 that balance has been settled, and those charges no longer need to be defrayed. Why would anybody voluntarily reduce the interest they are collecting? If one's neighbours are following the strategy of targeting overall interestIt makes payment paths that cancel out their neighbours' obligations to them more attractive.
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. To avoid this counter-intuitive and unappealing situation, nodes may target the interest they charge on particular transactions to specifically zero the interest balances for each rate.
A simple example is that I may owe my neighbour 100 at 5%, but generally charge him only 2% on balances owing to me. When the chance comes for him to send me IOUs, I may decide to charge him 5% specifically to zero out that 5% balance -- in other words, demand my outstanding IOUs at 5% back in payment. 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:
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).
At the end of a month, A's balance adjustment for interest charges would be:
@@
-200 * (exp(.02/12) - 1) = -0.3336
-100 * (exp(.05/12) - 1) = -0.4175
50 * (exp(.03/12) - 1) = +0.1252
--------
-0.6260
@@
'''Decreasing the interest rate'''
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 that balance has been settled, and those charges no longer need to be defrayed. Why would anybody voluntarily reduce the interest they are collecting? If one's neighbours are following the strategy of targeting overall interestIt makes payment paths that cancel out their neighbours' obligations to them more attractive.
Added lines 1-17:
'''Tracking interest on accounts'''
To start with, nodes should be able to charge interest on balances owed by their neighbours.
Interest on a balance has two parameters: rate and compounding period. To simplify things, always compound continuously. 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 is needed 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.
'''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.
'''Decreasing the interest rate'''
To start with, nodes should be able to charge interest on balances owed by their neighbours.
Interest on a balance has two parameters: rate and compounding period. To simplify things, always compound continuously. 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 is needed 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.
'''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.
'''Decreasing the interest rate'''