Bitcoin-like implementation of Ripple

[jtimon]

I've posted this same message in the ripple-project group:

http://groups.google.com/group/rippleusers/browse_thread/thread/eac0505ca4e5b839?hl=en

I want to convince you of the necessity of merging Ripple and Bitcoin projects. I'd say Ripple is the What and Bitcoin is the How.

For those of you who don't know what LETS is, I'd recommend you to watch "The money fix" documentary. Once you understand LETS, you can say that it's limited to small communities in which everybody knows each other. Ripple solves that problem by turning the community into a network. Ripple is a generalization of LETS. You can build a LETS community inside a Ripple network. In fact, a LETS community's accounting can be transferred easily to a Ripple Server.
 
The problem with Ripple is that the users must trust the server. Not only as a third party, the organization running the server can suffer legal bullying like Liberty Reserve or egold.
Here's where Bitcoin comes in. Bitcoin solves these problems by using proof of work and public key cryptography. Ripple can use these technologies too.
 
For the unit of account, many "currencies" can be used at the same time (like is currently done in Ripple). However, if the users of that unit want stable prices, I think the better approach is to define a currency as a basket of commodities, like Terra Reference Currency. Since ripple doesn't have to store the commodities to back the currency (because is not a currency but a unit), the basket can be composed of any number of different commodities.   

Now I want to start a draft of the design of a ripple-coin software. I've read the bitcoin white paper, but please correct me if I'm wrong in any technical detail.

In bitcoins transactions, the sender signs the address (public key) of the receiver so that everybody can verify the transaction.
On the other hand, a transaction in ripple is composed of several "micro-transactions" between all the agents in the chain of credit.
Let's have an example for the shake of simplicity.
User A wants to pay 10 units to user Z, but they're not directly connected. Let's assume that A is connected to B and B to Z with enough credit so that the transaction is possible according to ripple rules. In order for this transaction to be safe, it has to have the following micro-transactions (each of them signed by the debtor):
-A owes 10 to B
-B owes 10 to Z
Each transaction must obey two simple rules:
   1) Every Agent that appears in the transaction but is not the sender or the receiver must finish the transaction without moving his balance in any direction.
   2) The receiver must increase his balance in the amount that the sender reduces it.
The first problem appears: A needs B to be online when he pays Z, because he needs B to sign that owes money to Z.
If we don't want that painful limitation, A needs another way to proof that he can owe 10 to B, and that B can owe 10 to Z.
Two solutions come to mind.
1) The whole "credit graph" is stored in the block chain. There are pseudo-transactions or credit transactions in the form "A signs B can owe him up to 100 units".
The block chain would be bigger and it would contain a lot of data that doesn't represent any real transaction. Another disadvantage is that all the credits would be completely public.

2) The credit transactions are send between clients (not nodes) and they store them for later use. The problem is:
How can an address cancel (or decrease) the maximum credit it gives to some other address once it signed the "credit transaction"?
The solution a thought is that the credit transactions should contain a block number after which the credit expires.
The clients would have to renew their credit with each other. The clients can send their CT (credit transactions) not only to its neighbors in the Ripple network but to any client in the p2p ripple network.

Once a transaction is in the block chain, all its CT can be used for anyone (always following the rules). If they want to increase the debt for a given CT, they cannot exceed the maximum credit (taking to account every previous uses of that CT) and the transaction reusing the CT must be in a block previous to the Expiration Block Number.
If they want to decrease the debt, the block number doesn't matter and, of course, the debt cannot go under zero.
   
Privacy
To maintain privacy, a Ripple-coin agent can have multiple addresses, just like in bitcoin. The problem here, is that some debts could stay forever in the block chain if the debtor address becomes isolated in the credit graph.
Since the neighbors trust themselves, there are different solutions. Remember you can sign one of your new addresses with the old one to demonstrate to your neighbor that it belongs to you too.
1) The creditor cancels the debt in a transaction and the debtor creates it again (between different addresses) in another transactions.
2) The creditor accepts debts from the debtor's new address. The debtor's new address pays to the old address through the creditor so the debt is now in he new address and the old address debts are equal to zero. 
There has more ways to get the same result. We want them the less traceable and the more automatic possible.
In the other hand, some agents can give up privacy to be more "trustable". They can, for example sign with their address documents describing them or their organization.

Incentive for the nodes
As an incentive for the nodes, in bitcoin they can create a new bitcoin if they're able to supply the next block. In the future there will be no more new bitcoins and the incentive will be the fees charged by the nodes. As ripple-coin cannot create debt from nobody to the nodes, the transaction fee seems the only way to encourage the nodes to "waste" their CPU power. The problem with the fees is that the payer in a transaction has to be trusted (directly or indirectly) by the node. The fee can be charged to the receiver of the transaction instead of the payer. The receiver seems more "trustable" since someone (at least the payer) owes money to him. But the nodes still have to trust some unknown agent. The nodes could still refuse to record transactions if they don't trust any of the two main agents in the transaction. The only solution that comes to mind is changing the rules so that the money owed to the nodes in concept of fees must be accepted by anyone until it is "destroyed". That happens when the original debt is owed to someone who trusts (directly or indirectly) the original debtor. The original debtor (of the fee) can become isolated in the credit network, so the solution is not flawless.
 
Any criticism to this design from both communities (Ripple and bitcoin) is welcome, as well as fixes and different technical approaches.
I will defend the analysis the best I can. That is a Ripple-like system implemented in a p2p fashion that is secure and keeps acceptable levels of privacy.   

English is not my first language so I'm sorry if a repeat some words too much or if some sentences are not grammatically correct.

[1714041549]

1714041549

[1714041549]

1714041549

[1714041549]

1714041549

[1714041549]

1714041549

[1714041549]

1714041549

[dannyjpw]

Hi, I came here from the ripple forum. I completely agree with your suggestion.


All I have to add at this stage is to help solve this problem:

as ripple-coin cannot create debt from nobody to the nodes, the transaction fee seems the only way to encourage the nodes to "waste" their CPU power. The problem with the fees is that the payer in a transaction has to be trusted (directly or indirectly) by the node. The fee can be charged to the receiver of the transaction instead of the payer. The receiver seems more "trustable" since someone (at least the payer) owes money to him. But the nodes still have to trust some unknown agent. The nodes could still refuse to record transactions if they don't trust any of the two main agents in the transaction. The only solution that comes to mind is changing the rules so that the money owed to the nodes in concept of fees must be accepted by anyone until it is "destroyed".

The situation here is exactly analogous to the way fiat money works. In this case the block chaining node (master node) needs to be compensated, but he does not trust those who would pay him. This is solved by allowing the master node(s) to coin digital currency. He spends this as he sees fit on goods and services from other cell members, and he can do this because the currency is accepted for clearing debts among all those nodes subscribing to the master nodes cell.

The cell members then return this currency to the master node in payment for his cpu effort (and no doubt other efforts he would make in maintaining an active cell in the real world). The nice thing here is that the master node effectively gets paid 'up front' when he creates new currency.

Of course the situation is exactly the same as the US dollar reserve currency. It is created and then some of it is demanded back as tax. Except happily in this ripple/bitcoin case, if the master node misbehaves is is straightforward for the members to leave and create a new cell with new master nodes.

The currency issued here would obviously be bitcoins. If each new ripple block created also created 1 bitcoin as a side effect, then it is all quite neat I think.

[jtimon]

The situation here is exactly analogous to the way fiat money works. In this case the block chaining node (master node) needs to be compensated, but he does not trust those who would pay him. This is solved by allowing the master node(s) to coin digital currency. He spends this as he sees fit on goods and services from other cell members, and he can do this because the currency is accepted for clearing debts among all those nodes subscribing to the master nodes cell.

The cell members then return this currency to the master node in payment for his cpu effort (and no doubt other efforts he would make in maintaining an active cell in the real world). The nice thing here is that the master node effectively gets paid 'up front' when he creates new currency.

My proposal was to set the rules for valid transactions so that any user in the network has to accept the IOU's created as fees to the node even if they don't trust the original issuer of the IOU. Once these IOU's belong to a subnetwork that trust the issuer, those IOU's can be treated as normal and be destroyed by coming back to the issuer. The flaw in this is that if the issuer address becomes isolated, then the IOUs against that address are not redeemable and would stay in circulation forever.

Of course the situation is exactly the same as the US dollar reserve currency. It is created and then some of it is demanded back as tax. Except happily in this ripple/bitcoin case, if the master node misbehaves is is straightforward for the members to leave and create a new cell with new master nodes.

If a "master" node misbehaves the other nodes won't accept his block as the next block in the chain, so it's impossible for a node to misbehave.

The currency issued here would obviously be bitcoins. If each new ripple block created also created 1 bitcoin as a side effect, then it is all quite neat I think.

The IOU's issued here could be denominated in bitcoins. This way it would be easier for the nodes to calculate how much they earn by helping "ripple-coin" compared to what they earn helping bitcoin.
Each new bitcoin block generates 50 new bitcoins and not 1 (anyone correct me if I'm wrong).

What you're suggesting, I think, is a hybrid system with money based on debt between trusted parties (ripple's IOUs) and fiat (or electronic commodity backed if you wish) money.
I thought about that too, but finally I decided I don't like it.

I will post on Ripple forum, but I need some time to answer Ryan's long posts and I've been busy lately.
I'm very glad you are interested in my proposal. What a pity that no one seems to be interested here in the bitcoin community.

[Nefario]

Does ripple have working point of sale systems?

[dannyjpw]

My proposal was to set the rules for valid transactions so that any user in the network has to accept the IOU's created as fees to the node even if they don't trust the original issuer of the IOU. Once these IOU's belong to a subnetwork that trust the issuer, those IOU's can be treated as normal and be destroyed by coming back to the issuer. The flaw in this is that if the issuer address becomes isolated, then the IOUs against that address are not redeemable and would stay in circulation forever.

This sounds like a system in which assets, rather than liabilities, are a circulating medium of exchange. By saying that someone else's IOU must be accepted by others you are inverting the normal construction of any debt based system on its head. That can only work if the original issuer of the IOU IS trusted. Again, it comes back to some notion of reserve currency, which is no more really than saying this nodes debt is the best of all the nodes. In fact it is the same as a fiat currency regime in which IOUs written by the government are to be accepted by everyone els,e and of course there are laws to ensure this is the case.

One  way to deal with that flaw is to have the fees charged up front. The successful computer of the block is rewarded at the instant the block is solved and broadcast with a new coin. Assuming that block makes it into the longest chain then that chain also incorporates the validation of his coin.

Obviously this rubs against the built-in deflation of bitcoin but it is worth examining the economics here. Essentially one can have a node-incentive provided as an IOU redeemed after the fact in which case all transactors (buyers and sellers) give a small part of their purchasing power to the solving node, or you have the same fee charged in the form of inflation to all transactors. Except, not quite because with the latter only holders of debt are charged, not debtors. That can be balanced by having interest fees on outstanding debt, but that would be a matter for individual debtor-creditors to set for themselves.

Lastly, could it be done alternatively such that each time a coin gets used in ANY transaction it has its value decremented. That is, it is clipped and the clipping discarded. Eventually there would be nothing left of it. This would counter the inflationary impact of new coins. It also has the nice side effect that if you don't spend a coin it doesn't lose any value - it just loses value when it circulates. Essentially it has the same outcome as paying fees to the solver, but without all the troublesome  loose ends.

The IOU's issued here could be denominated in bitcoins. This way it would be easier for the nodes to calculate how much they earn by helping "ripple-coin" compared to what they earn helping bitcoin.
Each new bitcoin block generates 50 new bitcoins and not 1 (anyone correct me if I'm wrong).

Just to be clear, I am suggesting that there are no IOUs for fees, just new bitcoins in lieu of fees. I am suggesting a hybrid which does away with the 21M coin limit and perhaps uses an eroding coin to balance inflation. If 50 coins are made with a new block, that works fine. After 50 uses the coin will have no value left (effectively, it has all gone in fees).

[quopte]
What you're suggesting, I think, is a hybrid system with money based on debt between trusted parties (ripple's IOUs) and fiat (or electronic commodity backed if you wish) money.
I thought about that too, but finally I decided I don't like it.
[/quote]

well you should say why. There is nothing wrong with the fiat system except for its centralization. Having liquid cash that is accepted by all for clearing debts and for performing instant transfers of value for important stuff such as proof-of-work fees without loose ends is advantageous, especially if the way such currency is brought into being is through doing publicly accepted crypto work and the way the currency is retired is also encoded into the system in a decentralized manner.

What a pity that no one seems to be interested here in the bitcoin community.

Ryan did warn that that might be the case I think!

[jtimon]

Does ripple have working point of sale systems?

I don't know. maybe you can ask in the ripple forum.

[quopte]
What you're suggesting, I think, is a hybrid system with money based on debt between trusted parties (ripple's IOUs) and fiat (or electronic commodity backed if you wish) money.
I thought about that too, but finally I decided I don't like it.

well you should say why. There is nothing wrong with the fiat system except for its centralization. Having liquid cash that is accepted by all for clearing debts and for performing instant transfers of value for important stuff such as proof-of-work fees without loose ends is advantageous, especially if the way such currency is brought into being is through doing publicly accepted crypto work and the way the currency is retired is also encoded into the system in a decentralized manner.
[/quote]

Ok, you made me change my mind again.
I said that the issued currency could be rejected by some seller, but if the system allows the use of that currency to clear debts, then that currency would be obviously valuable.
You're view reminds me a post I wrote here before knowing the existence of ripple:

http://bitcointalk.org/index.php?topic=2910.0

Obviously this rubs against the built-in deflation of bitcoin but it is worth examining the economics here. Essentially one can have a node-incentive provided as an IOU redeemed after the fact in which case all transactors (buyers and sellers) give a small part of their purchasing power to the solving node, or you have the same fee charged in the form of inflation to all transactors. Except, not quite because with the latter only holders of debt are charged, not debtors. That can be balanced by having interest fees on outstanding debt, but that would be a matter for individual debtor-creditors to set for themselves.

Lastly, could it be done alternatively such that each time a coin gets used in ANY transaction it has its value decremented. That is, it is clipped and the clipping discarded. Eventually there would be nothing left of it. This would counter the inflationary impact of new coins. It also has the nice side effect that if you don't spend a coin it doesn't lose any value - it just loses value when it circulates. Essentially it has the same outcome as paying fees to the solver, but without all the troublesome  loose ends.

To avoid inflation I have another proposal: demurrage.
The bitcoins created can lose value constantly in time so that the amount of bitcoins removed from circulation this way equals the amount created to pay the proof of work.
Obviously, the demurrage would be applied after some quantity of them are circulating (¿21M?).
The demurrage would have another benefits: suppressing interest, stimulating the circulation (that can prevent crises)...
I have posted about it here:

http://bitcointalk.org/index.php?topic=3816.0

[Mike Hearn]

Ripple is an interesting concept and I discussed it with Ryan some years ago.

It tries to solve a different set of problems to BitCoin. The biggest issue I have with it, is that the benefits over the existing monetary system are not that big and it's a very complex way to handle debt. In particular the way I become transitively liable for the debts of my friends is something that's difficult to swallow for many people.

The automatic detection and destruction of circular debt was always more interesting to me, but Ripple in general is such a radical change to how money works that it's going to be much harder to get traction than BitCoin - which itself is seen as radical and risky by many folks, even though conceptually it's just another currency.

[jtimon]

Ripple is an interesting concept and I discussed it with Ryan some years ago.

It tries to solve a different set of problems to BitCoin. The biggest issue I have with it, is that the benefits over the existing monetary system are not that big and it's a very complex way to handle debt. In particular the way I become transitively liable for the debts of my friends is something that's difficult to swallow for many people.

The automatic detection and destruction of circular debt was always more interesting to me, but Ripple in general is such a radical change to how money works that it's going to be much harder to get traction than BitCoin - which itself is seen as radical and risky by many folks, even though conceptually it's just another currency.

The benefits over the existing monetary system are greater for ripple than for bitcoin. Bitcoin is way better than national currencies, but is very similar to gold. An economy based on gold have interest which I think is evil:

http://finanzcrash.com/english/aberrations.html

Bitcoin has no way to warranty stable prices. It's deflationary.
Ripple can achieve stable prices:

http://bitcointalk.org/index.php?topic=3396.msg53145#msg53145

I think Ripple should target users of LETS.
Botch projects are radical and hard to accept by most people I know. I'm going to sound like a conspiracy theorist, but I think the coming destruction of national currencies (managed by the elitists in order for the world to accept one global currency) will be an opportunity for any alternative: precious metals, barter, LETS, Ripple, bitcoin...
Bitcoin and Ripple are my favorite ones.
Even if the collapse of the inflationary national currencies is not planned, it will eventually come with the coming energy crisis.
Most people can't even conceive peak oil, so explain the need for alternatives currencies is always hard.

[dannyjpw]

To avoid inflation I have another proposal: demurrage.
The bitcoins created can lose value constantly in time so that the amount of bitcoins removed from circulation this way equals the amount created to pay the proof of work.
Obviously, the demurrage would be applied after some quantity of them are circulating (¿21M?).
The demurrage would have another benefits: suppressing interest, stimulating the circulation (that can prevent crises)...
I have posted about it here:

That is exactly what I suggested above. Bitcoins are added to the supply each time a block is solved (incentive to contribute CPU resources), but bitcoins erode each time they are transacted with. So, inflation is balanced.

The hard part IMO, is that you don't always want a balanced inflation. When the number of users of the ripple-bitcoin system is growing, you need more bitcoin liquidity. I have never believed in the built in deflation in bitcoin, it seems to me an unnecessary restriction.

So that hard part, is how the bitcoin-ripple money supply is automatically adjusted to grow with the volume of transactions, or equivalently, how a more or less fixed bitcoin velocity is maintained in this system of balanced demurrage and supply inflation.

[jtimon]

To avoid inflation I have another proposal: demurrage.
The bitcoins created can lose value constantly in time so that the amount of bitcoins removed from circulation this way equals the amount created to pay the proof of work.
Obviously, the demurrage would be applied after some quantity of them are circulating (¿21M?).
The demurrage would have another benefits: suppressing interest, stimulating the circulation (that can prevent crises)...
I have posted about it here:

That is exactly what I suggested above. Bitcoins are added to the supply each time a block is solved (incentive to contribute CPU resources), but bitcoins erode each time they are transacted with. So, inflation is balanced.

The hard part IMO, is that you don't always want a balanced inflation. When the number of users of the ripple-bitcoin system is growing, you need more bitcoin liquidity. I have never believed in the built in deflation in bitcoin, it seems to me an unnecessary restriction.

So that hard part, is how the bitcoin-ripple money supply is automatically adjusted to grow with the volume of transactions, or equivalently, how a more or less fixed bitcoin velocity is maintained in this system of balanced demurrage and supply inflation.

The only difference in what I'm saying is how the bitcoins erode.
Your proposal is

F% of the amount is lost with each transaction
or
F is lost with each transaction

I don't know, but i guess you mean the first
My proposal is:

D% of the amount is lost annually

The fee with each transaction punish the spend and therefore reduces the velocity of circulation. On the other hand, the demurrage stimulates the spend and trade with the currency, because the longer you hold the money the more you lose.
I guess time here can be measured with the block counter.
Here we got the formula we're supposed to be talking about if we want to reach stable prices(http://en.wikipedia.org/wiki/Money_supply#Monetary_exchange_equation):

MV = PQ
M is the total dollars in the nation’s money supply
V is the number of times per year each dollar is spent
P is the average price of all the goods and services sold during the year
Q is the quantity of assets, goods and services sold during the year

Demurrage increases V and make it more predictable.
Demurrage could be adjusted dynamically in function of P, supposing you have a way to measure P.
The typical approach (without demurrage)is to increase M (print money) without knowing anything nor having any control of V. When V is low, crises come.

For me the most important thing for me is suppressing interest, which is the reason I became interested in Ripple in the first place.

[rfugger]

It tries to solve a different set of problems to BitCoin. The biggest issue I have with it, is that the benefits over the existing monetary system are not that big and it's a very complex way to handle debt. In particular the way I become transitively liable for the debts of my friends is something that's difficult to swallow for many people.

Hi Mike.  I'd like to understand this concern...  If you're comfortable granting credit to a friend (ie, lending to them) on the system, why would you not be comfortable lending them your IOU to give to another one of your friends (ie, vouch for them)?  Obviously, you only have to grant credit to those people you trust to make good on their debts...  What am I missing here?  Thanks for your input.

Ryan

[rfugger]

Does ripple have working point of sale systems?

No.  Ripple only has a few non-distributed/single-server implementations that are still really proofs of concept.  We are working on a feasible distributed protocol, as well as designing marketplaces to motivate growth in the network.  I understand there is some interest in using a Ripple-type system for real-time approval of Bitcoin transactions in, for example, a POS setting, which is one of the motivators of renewed work on the protocol.

Ryan

[ribuck]

If you're comfortable granting credit to a friend (ie, lending to them) on the system, why would you not be comfortable lending them your IOU to give to another one of your friends (ie, vouch for them)?

Speaking for myself rather than for Mike...

Suppose I'm happy to lend money to my friend Fred, but not directly to Fred's friends. With RipplePay, Fred's friend Sue can get the use of my money, though it's Fred who has the ultimate liability to pay me back.

But if Sue disappears and doesn't pay Fred back, it's going to ruin my friendship with Fred when I pressure him to pay me back Sue's loan out of his own pocket. It doesn't help the friendship if I say to Fred "It's your fault because you decided that you trust Sue".

[dannyjpw]

The only difference in what I'm saying is how the bitcoins erode.
Your proposal is

F% of the amount is lost with each transaction
or
F is lost with each transaction

I don't know, but i guess you mean the first
My proposal is:

D% of the amount is lost annually

Hi JT, F% of the amount of each coin is lost each time its spent.

The fee with each transaction punish the spend and therefore reduces the velocity of circulation. On the other hand, the demurrage stimulates the spend and trade with the currency, because the longer you hold the money the more you lose.

Their are equal pros and cons in each case. but..

I guess time here can be measured with the block counter.
Here we got the formula we're supposed to be talking about if we want to reach stable prices(http://en.wikipedia.org/wiki/Money_supply#Monetary_exchange_equation):

MV = PQ
M is the total dollars in the nation’s money supply
V is the number of times per year each dollar is spent
P is the average price of all the goods and services sold during the year
Q is the quantity of assets, goods and services sold during the year

Demurrage increases V and make it more predictable.

...I hate that equation. Money doesn't have 'velocity' contrary to popular imagination. Most of the time a money token just sits in one location. Very occasionally it moves. At the moment, each dollar of base money moves about every 8 months. Thats not like velocity, like water thru a pipe, its more like electrons tunneling. So more of a stochastic, quantum type event than a flow.

I don't think that equation is that useful in the real world.

Secondly, you say you don't like interest but demurrage per year is not only interest, but it is imposed artifically.

Whereas what I propose, the fee charged when spent is a transaction fee , which I promise you will make more sense to everyday people than a negative nominal interest rate will do.

For me the most important thing for me is suppressing interest, which is the reason I became interested in Ripple in the first place.

Its a shame you feel that way. You cannot load political or ideological views on a money system and expect it to succeed. Ripple is a pure system of bilateral agreements and as such there is no business for you or I to impose a particular form on these voluntary bilateral contracts. If two consenting adults would like to charge one another interest, so be it.

OTOH, the transaction fee is perfectly understandable as a fee payable to the community who enable, via the donation of their MIPS, trade to take place.

[jtimon]

The fee with each transaction punish the spend and therefore reduces the velocity of circulation. On the other hand, the demurrage stimulates the spend and trade with the currency, because the longer you hold the money the more you lose.

Their are equal pros and cons in each case. but..

I guess time here can be measured with the block counter.
Here we got the formula we're supposed to be talking about if we want to reach stable prices(http://en.wikipedia.org/wiki/Money_supply#Monetary_exchange_equation):

MV = PQ
M is the total dollars in the nation’s money supply
V is the number of times per year each dollar is spent
P is the average price of all the goods and services sold during the year
Q is the quantity of assets, goods and services sold during the year

Demurrage increases V and make it more predictable.

...I hate that equation. Money doesn't have 'velocity' contrary to popular imagination. Most of the time a money token just sits in one location. Very occasionally it moves. At the moment, each dollar of base money moves about every 8 months. Thats not like velocity, like water thru a pipe, its more like electrons tunneling. So more of a stochastic, quantum type event than a flow.

I don't think that equation is that useful in the real world.

If the average dollar moves every 8 months, in 12 months the avarage velocity of the dollar is 1.5
With demurrage, that number would be considerably greater. Anyway, even if you don't believe in the effects of velocity and you think it all depends on the supply, demurrage can destroy money like your fee does.
The main pro is that it encourages transactions instead of punish them. The removal of the interest is a pro for me too.
The main contra is that the currency loses partially the function of storage of wealth.

Secondly, you say you don't like interest but demurrage per year is not only interest, but it is imposed artifically.

Whereas what I propose, the fee charged when spent is a transaction fee , which I promise you will make more sense to everyday people than a negative nominal interest rate will do.

I said per year for simplification. It would be per block in the block chain when you spend the money since you received it.
Is imposed artificially but the users should accept that rule. The creation and the spending fee are artificial too.

You're probably right about the sense it can make to everyday people.

For me the most important thing for me is suppressing interest, which is the reason I became interested in Ripple in the first place.

Its a shame you feel that way. You cannot load political or ideological views on a money system and expect it to succeed. Ripple is a pure system of bilateral agreements and as such there is no business for you or I to impose a particular form on these voluntary bilateral contracts. If two consenting adults would like to charge one another interest, so be it.

I'm not saying that I would remove the ability to charge interest in Ripple, but I believe it would be zero in most cases. The scarcity of money is the source of interest, I think. And Ripple doesn't have that scarcity.

OTOH, the transaction fee is perfectly understandable as a fee payable to the community who enable, via the donation of their MIPS, trade to take place.

Most people won't never get the Ripplecoins. They will be just trading with IOUs. All they need to know is that (in exchange of their services) the Nodes are creating money that they will have to accept for settling debts. Since they won't usually produce that money, they won't have a problem if that money expires gradually.
The problem is with miners. They will prefer the usage fee.

[BitterTea]

demurrage can destroy money like your fee does

Fees don't destroy money, they transfer it. When a transaction fee is incurred, the generator of the block receives that money. When demurrage occurs, the money disappears forever.

[dannyjpw]

If the average dollar moves every 8 months, in 12 months the avarage velocity of the dollar is 1.5

So what? You mean to imply a metaphor between money and water when the comparison is specious. If you have a mostly immobile  sand dune and every so often a grain is picked up by wind and moves to a nearby dune that is a more appropriate metaphor for money.

Another metaphor is is two roads. The high road moves very fast, with a small number of cars, and many collisions. This is the hot money flow.

The low road moves very slowly, and is always gridlocked. This is the saving of ordinary people.

There is an on-ramp and off ramp to the high road. This is an appropriate model. And yields a totally different way of thinking, and highlights totally different problems and solutions, than the image of water moving in pipes.

With demurrage, that number would be considerably greater. Anyway, even if you don't believe in the effects of velocity and you think it all depends on the supply, demurrage can destroy money like your fee does.

A high (or low) 'velocity' is neither here nor there. A single coin with ultra high velocity is as good, you say, as many coins with low velocity. In fact they are equivalent according to the MV=PQ.

The force you term Velocity arises from the technology associated with money, cultural norms, and imbalances like interest rate differentials. It is therefore not something that can be forced, but an emergent property of all these things.

[rfugger]

If you're comfortable granting credit to a friend (ie, lending to them) on the system, why would you not be comfortable lending them your IOU to give to another one of your friends (ie, vouch for them)?

Speaking for myself rather than for Mike...

Suppose I'm happy to lend money to my friend Fred, but not directly to Fred's friends. With RipplePay, Fred's friend Sue can get the use of my money, though it's Fred who has the ultimate liability to pay me back.

But if Sue disappears and doesn't pay Fred back, it's going to ruin my friendship with Fred when I pressure him to pay me back Sue's loan out of his own pocket. It doesn't help the friendship if I say to Fred "It's your fault because you decided that you trust Sue".

Thanks for the reply.  It's a good point.  Being a bank and issuing your own debt-backed currency -- which is essentially what Ripple enables -- can be tricky.  The hope is that participants learn to handle defaults in the same way as banks:  They accept the loss in the context of overall assets and liabilities, rather than isolating particular liabilities they allowed to be incurred by granting the credit.  It really isn't your fault that Fred decided to trust Sue, and *you* have to trust Fred to be mature enough to acknowledge that.  If you don't think he is, then you shouldn't offer *him* credit. 

We will need to design the software to guide users' through these processes, as well as giving them advice and tools to make them continually aware of their own exposure to debt and prepare them for inevitable defaults, such as highlighting inactivity on risky accounts near their credit limit, and a way to to set aside a reserve fund, possibly from transaction fees or interest charged on loans.

It's definitely not a trivial problem, but I envision solutions evolving as more and more value is transacted in Ripple and it becomes more important.

Ryan

[Benson Samuel]

http://bensonsamuel.com/bitcoin-3/a-decentralized-monetary-system-for-a-decentralized-currency/

[Vitalik Buterin]

Has the Ripple project advanced at all this past year? It seems like such a good idea in theory, it's a shame to see it getting neglected so much.