Bitcoin Forum

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.

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:


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.

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.


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

Does ripple have working point of sale systems?

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.


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.


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

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


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


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

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.

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.

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

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

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

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


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


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



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.

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.


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.


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.


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.

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.

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.


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.

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

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

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.

It has Vitalik.
There has been a lot of discussion and work.
I am currently awaiting a few comments from Jorge Timon who is an authority on Ripple & Bitcoin.
Will post after they come about.

As of now, there are 4+ ways to integrate Bitcoin and Ripple.

The Bitcoin economy has always had a major problem with trust.
The fact transactions aren't reversible, the heavy inclination for anonymity in the community, and the track record of scams, make lending a very risky activity.
In turn, this makes it difficult for businesses to raise funds, which prevents the growth of the economy.

A system like Ripple could be of great help to facilitate lending.
The chain of trust acts like a path to recall the funds, making the transactions somehow reversible.
Anonymity is preserved in a way that reminds of TOR. Each intermediate knows who is his immediate debtor and creditor, but doesn't know who are the end points, or if the immediate creditor or debtor are endpoints themselves or just forwarding the debt along.
Scams are not practical because defaulting on one's debt is going to wrong a close acquaintance and no one else.

Beside, there is another major quality of a system like Ripple: debt can be distributed. Instead of owing a huge amount to a single creditor, one can instead contract tens of small debts for the same amount on tens of paths that involve tens of direct friends. This reduces greatly the risk borne by each creditor, and gives flexibility to arrange for selective default in case of difficulty (family or closet friends will likely be more flexible and understanding). Debt can be distributed even further. You may accept to lend a large amount to a friend, and distribute the debt on 5 more friends.
That can even be combined with a system of interests that would be proportional to the number of levels involved. If you have many friends, and you borrow a small amount to all of them, you will get away with very low or no interets. If you borrow to friends of your friends, you will have to pay interests to your friend's friend as well etc. The huge advantage is that, while the interest rate grows linearly with the distance, the sum that can be raised grows exponentially.

Has this gotten anywhere? I just found it now and thought that there truly is a need for an open-source, decentralised implementation of the Ripple protocol.

I would suggest looking into what is going on with Open Transactions and its recent integration testing with BitMessage.

If this is packaged well then I think it could well be the "next big thing" (and it doesn't require XRP).

What is Open Transactions, sorry?

To quote from the github project:


https://github.com/FellowTraveler/Open-Transactions

Oopps, I missed some action in this thread.

@blablahblah

LETS and other local currency systems work perfectly well, there's more than 4000 local currencies in operation. It's interesting to note that many complementary currencies advocates often say exactly the same you said about LETS, but about Bitcoin: "Bitcoin deflects attention away from social currencies and other real alternatives."
Goldbugs, greenbackers, "local currency hippies", gesellians, bitcoiners, trade clubs, etc are all on the same boat, we're all monetary reformists that recognize that that out monetary system is the root of most evils. Even if we have different opinions on what's exactly is wrong with the current system.
We should try to understand each other better and fight together against the banking cartel, usd, eur, etc instead of fighting each other.
We bitcoiners are just the last faction of a much bigger movement.
All local currencies, time banks and "barter" clubs combined have far more users than Bitcoin.
It would be huge for Bitcoin to integrate with those trade networks.

@CIYAM Open
OT is useless for many use cases because you can't even trade two assets in two different servers atomically.
Ripple.com has a lot to do with this proposal, replacing proof of work with their new consensus mechanism. I don't know if that will work, but it's worth trying.
It is currently free software although the network is not p2p yet.
I think it has several design flaws though, and it doesn't look like their developers want to fix them.

@Everyone interested
For me Freimarkets (https://bitcointalk.org/index.php?topic=280292.0) is the continuation of this proposal.
I also wanted to integrate this proposal with Ryan's Two phase commit ripple distributed protocol and "private chains" are the way we decided to do that.
Well, not exactly with Ryan's design, but we also use the two phase commit and support more scalable and private off-chain transactions.

Some advantages over Ripple(tm):

- Support for off-chain assets/transactions.
- Support for interest bearing assets.
- Open orders (and trust lines, which in this case are emulated using regular orders) are off-chain.
- More scalable KYC support (and more flexible for some local currencies related special needs).
- Compatible with Bitcoin's design, code and scripting language (it's just an extension).
- Unspent outputs instead of accounts (no sequencing, better privacy).
- Although miners are likely to prefer the hostcoin, fees can be paid in any asset type.
- Support for unique non-fungible assets (better for some smart property use cases).
- Auctions, options...

Currently I'm busy finishing Freicoin Foundation's website, maaku is busy with the "ultimate UTXO compression" implementation (https://bitcointalk.org/index.php?topic=88208.0) and we're both busy building a crypto-currency business together.
In addition we haven't received much funding for this yet and we would also appreciate more feedback from core bitcoin developers that have also thought about smart property and off-chain transactions.

Anyone interested in seeing this happen please review the design and/or fund the development.
We cannot promise you to get rich like mastercoin or bitshares, or any return in your donation at all, but we think this would open the door to many entrepreneurship opportunities.

Can someone explain in laymen why I would need a ripple if I already have a Bitcoin?

thnx

Ripple advantages:
 * Instant Transactions
 * No hashing / mining
 * No block chain
 * Ability to have balances in multiple currencies

Bitcoin makes no compromises enabling trustless trade in a fungible unit of account.

Ripple lets you use any units but does not protect you of colluding servers.

Ripple might work just as secure as an SPV node of Bitcoin and it is likely more user friendly.

I guess Bitcoin remains the choice for ultimate settlement, while Ripple adds features we also need.

These advantages are specific to Ripple labs (previously opencoin) implementation concept, but I think he's asking more generally.
It doesn't have a block chain but it has a ledger chain, not that different really.
The transactions aren't instant, but their confirmation takes seconds instead of blocks.
The lack of proof of work as an advantage is arguable. Bitcoin is 100% trust-less because of that and Ripple has some trust involved in the construction of the UNL. We don't even know for sure if this will work when the network is p2p instead of under Ripple lab's control. Now that it is free software, people can create their own networks to experiment on forks, sibil attacks and other security aspects of this new proof of consensus.
We will see, but I'm glad they're experimenting with new global consensus mechanisms different from proof of work.


In general, Ripple-like systems like freimarkets allow the trade and transfer of more things than just a currency. Typically the balances represent IOUs, but they can represent many other things like shares, bonds...
The balances can be denominated in any currency.
The more interesting thing of the Ripple concept is the ability to perform transitive atomic transactions. That is, you can exchange the IOUs transitively and pay the recipient in a different currency from the one you spent.
An example:

Merchant D only accept localD_USD (a local currency in his community) as payment. Customer A holds BTC and wants to pay to merchant D.
In a single transaction, he sells his BTC for issuerB_EUR, which then sells for issuerC_USD and then for localD_USD and then sends them to merchant D.

Maybe you don't want to pay anyone and just want to buy localD_USD for BTC at the lowest price you can find and this path results to be the cheapest.
You could make another example where the payer pays USD and the merchant receives BTC, of course.

This feature is ideal for a p2p exchange.
And Bitcoin could have p2p exchange and transitive transactions too (among many other things) if we modify the protocol as proposed in Freimarkets.

As said there's no technical reason impeding Bitcoin from having those multi-currency and transitive transactions features.
Providing more privacy than Ripple, since Bitcoin uses unspent transactions and Ripple uses everlasting accounts (you cannot destroy them right now).

I think you're right that proof of work remains the choice for ultimate settlement but Ripple also has limits to sclability and we ultimately need off-chain transactions in one way or another. Whether those off-chain transactions will happen on Freimarkets-like private chains or in Open Transactions centralized but trust-less servers we don't know yet.
I think that the ability to atomically trade in-chain and off-chain assets is critical, but I could be wrong.

I think of Bitcoin as ultimate digital settlement, like gold over IP.

Bitcoin transactions are however rather expensive (including block reward) and slow to be final.

For higher abstractions or fast micropayments OT and Ripple seem better suited, but proof are outstanding. I actually prefer OT over Ripple for its capture of contracts and focus on auditability of the server actions.

Ripple transactions are (or will be) expensive too because all nodes in the network have to proccess them, they're still in-chain transactions (just another chain without proof of work).
Will Ripple scale to 1M tx/s ? I highly doubt it.
This thread was proposing to have multiple assets and transitive (ripple-like) transactions on Bitcoin's chain (or an altcoin), but that doesn't help with scalability, just adds a lot of new interesting use cases.
That's why integrating with something off-chain like Ryan's 2PC was critical and that's why we have "private chains" in Freimarkets to account for off-chain assets.
OT is more interesting than Ripple for scalability because its transactions are off-chain but its main limitation is the lack of transitive transactions between different OT servers.
I think that's a huge deal. Freimarkets has contracts (with scripts) and could be extended further but OT will never have ripple-like transitive transactions between different servers.