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.
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.