Ripple SOUNDS nice but there are some MAJOR problems

[casascius]

Nope, the fidelity bond is not the same. For example a Nexus could post a fidelity bond, this would allow customers to feel confident transacting up to below the value of the bond in total value. Over time the Nexus could securely handle many times the value of the fidelity bond, as long as at no given time it extends total credit whose value exceeds the bond.

Allowing customers to "feel confident" is not the same thing as customers balances being sound and secure.

This is like the FDIC... your bank account insured to $250,000!!!...by a $19 billion fund "protecting" $5 trillion in deposits (link).

tl;dr:

I don't mean to be the one to spoil the party.  By all means, let's let Ripple be built.  Who am I to say someone shouldn't be free to expend their own efforts as they see fit?  But I foresee it being no more revolutionary than a screen door submarine, certainly nowhere comparable to Bitcoin.

[JoelKatz]

I see that there is a second line of criticism here that claims that the concept behind Ripple is unsound. Let me distance myself from that - Ripple the concept sounds great (more on this below). But Ripple the implementation / specification seems lacking. The impact of a finite amount of XRPs seems hard to determine. Does this mean that eventually it will be impossible to produce new transactions? Again why are 80 billion XRP kept on reserve? Perhaps I just need to re-read the wiki a few more times to have a clear picture but it is not obvious how to analyze the system for correctness given only the published docs.

If ripples become scarce in the future, the transaction fee can be lowered by consensus. Ripples are quite finely divisible, but if it came to that, their divisibility could be increased in the future, just like with bitcoins. That couldn't even come close to being a problem in less than 100 years though.

Whats to stop someone from creating a bunch of accounts and using them to spam the network by creating new bogus currencies?  Is this what the XRP are for? What prevents someone from making a new currency that has the same name as someone else's currency?

Currently, currencies are just a three-letter code and a sequence number (in case a currency is re-issued). We have plans for custom currencies but they're not supported yet. If someone created a new currency, you would never see that currency unless you elected to transact in it. You can't hold an IOU you didn't agree to hold, and the currency is part of what you have to agree to.

Who controls the master list of Nodes? How does a node add itself to the list? How do you prevent someone from spamming the list of Nodes?

I'm not sure if you mean nodes you might connect to or nodes you might trust. The list of nodes you can connect to is managed just like Bitcoin does it. Nodes keep lists and offer those lists to their clients. We don't currency have a DNS anchor, but will probably add one. You can have a list of known node IPs in your configuration.

As for nodes you might trust, anyone who wants to can maintain a list of such nodes. Servers can choose root trust points and then those root trust points can list additional trust points.

For clients and servers not trying to actually process transactions, you only need to use trust to determine what the current consensus ledger is. From that point on, you're just walking hash chains.

Where is the "order book" (global list of bids and asks for all currencies)? How does someone place orders in the book? What happens when an order is filled? What prevents someone from spamming the order book? Is it guaranteed that everyone has a global view of the order book? How does this scale? etc... These are the kinds of questions that the wiki doesn't answer. There's no way to do an attack analysis because fundamental algorithms are not described.

The order book consists of entries in the ledger. There are entries that hold actual offers and index entries used to track the "tips" of the order books. Since the order book is in the ledger, the same scheme that ensures everyone operates against the same ledger does the same for the order book.

To create an offer, you have to do two things. First, you have to consume XRP for the transaction that places the offer. Second, you have to have sufficient XRP in your account to cover the increase in the reserve. The reserve drops when the offer is removed or fully taken.

It seems that the authors of the Ripple software have developed a fully decentralized distributed database that has read, update, and write capabilities (is this true?) Furthermore they have designed it to be resistant to spam, in a way that doesn't require proof of work. This is what's known in computer science as a hard problem. Just solving this problem in a straightforward and robust fashion would be a significant advance (look at the complexity of Freenet, which still has issues). I find it hard to believe that this difficult problem was solved in such a short period of time.

I do too. And what's stunning is how simple our solution is. However, there is a lot of subtlety underneath the simplicity.

For example, one key thing we did was organize the ledger as a hash tree so the entire ledger can be stated with a single hash. This makes it easy for all participating validating nodes to sign a statement that they believed that the entire database had a particular state at a particular time.

Another thing we did was organize the ledger so that simple proof chains can be extracted from it using only hashing operations. So a client that sees signed receipts to convince them that the ledger had a particular hash can be shown a chain that proves a particular entry is or isn't in the ledger.

My beef is not with the concept, but with the lack of details about the implementation. And it is exceptionally frustrating that a lot of people are jumping on this bandwagon and singing its praises when we don't have any sort of analysis to determine if the required algorithms are workable or scalable.

That's a fair point. I agree that we need to put much more effort into documenting. There just are only so many hours in the day.

[JoelKatz]

With all due respect, I think you misunderstand what it means to "make" someone owe someone money.  You can't just make someone owe you money, only they themselves can make themselves owe you money by agreeing to pay you.  There is a legal concept of assignment of debt, but a legal system also decides how that is to be done.  Absent a law saying that the Ripple system is how it's done, nothing in the Ripple system has the legal authority to effectuate an assignment of debt, or to make anybody owe anybody anything.

Absolutely. And I should try to be clearer about what I mean.

Someone can owe you money in the sense that the system records a particular balance between you and them. Here, the words "owe you money" don't really refer to an actual legal or moral obligation but to a particular status in the system. That status has an effect though, because the system has that status, the system will act in a certain way when it receives future transactions.

Where it gets real is when people have an actual "withdraw on demand" agreement. You could have such an agreement with a friend of yours. You could agree that the ripple system says they owe you dollars, they'll pay you dollars on demand in exchange for you cancelling out that debt. More likely, you could enter into such an agreement with a "gateway", an entity that makes it their business to enter into "withdraw on demand" agreements with lots of people.

We should make it very clear that absent an agreement that says otherwise, there is no inherent obligation to settle "debts" recorded in the ripple system. The system gives those "debts" power, and you can't stop it from doing that. But that's strictly within the system until you get to a case where you have an enforceable withdraw on demand agreement (or people are willing to settle on an ad hoc basis).

If I extend you 10 USD credit, you are under no obligation to ever pay me any actual US dollars. However, I can then acquire your IOUs within the system various ways and I can use them as a medium of exchange with anyone who can accept them. I can also give them to you and obtain other IOUs you hold within the system. This is all automated. But to get actual dollars in my hand or bank account, there needs to be an agreement outside the system.

[casascius]

Where it gets real is when people have an actual "withdraw on demand" agreement. You could have such an agreement with a friend of yours. You could agree that the ripple system says they owe you dollars, they'll pay you dollars on demand in exchange for you cancelling out that debt. More likely, you could enter into such an agreement with a "gateway", an entity that makes it their business to enter into "withdraw on demand" agreements with lots of people.

I could actually see myself doing this - something I have represented from the start in my various criticisms of Ripple.  For example, I have maintained for a long time that if I were to issue some sort of standing agreement with other big players in the Bitcoin world agreeing to settle any debt I issue as recorded on Ripple, thereby giving Ripple's data some sort of legal teeth, then Ripple would greatly complement my ability to do business.  If this became commonplace, it would add an enormous amount of fluidity to the entire Bitcoin economy.

The easiest way for me to describe how I see the benefit of using Ripple would be to take the whole concept of "MtGox USD codes" - which work in practice but are subject to the theoretical risk that MtGox may at any point choose not to honor a code and pretend it's invalid - and replace it with an open system like Ripple, where the system of swapping MtGox debt is sort of an open book to the world, forcing a certain level of integrity on the way MtGox liabilities are accounted for.  MtGox could still choose to dishonor their debt, but then at least people would be able to see that and call them out on it.

The ability to swap debt around - when done properly - would be a huge benefit and would increase Bitcoin market confidence immensely - I am convinced that the true Bitcoin market is FAR deeper than what is currently represented on MtGox, and what we see is greatly hampered by the rightful fear of people to put "good money" in MtGox knowing it can be seized or misappropriated without accountability.  If instead, people could put "good debt" into MtGox, we'd be at the multi-billion-dollar mark in market cap yesterday.  Good debt for this purpose is almost as good as money, but comes with a big benefit: it can't get seized without due process because only by due process can its repayment be forced.

Now as for Ripple... swapping debt is already possible without it.  I can draft a contract, put it in a PDF, digitally sign it, and plausibly have that digital signature recognized by a court, which the only tool I need to start creating and swapping debt.  That is, a pen, paper, and some way to add the digital stamp of approval that allows everyone to confirm that I really agreed to what I agreed to.  Courts aren't all that familiar with PGP, but they are plenty familiar with PDF as they use it daily, and the PKI for signing PDF's has been maintained well enough that they're likely to recognize a properly signed PDF as legit.

Yes, Ripple will make a fantastic open ledger for managing and settling debt among parties sophisticated enough to form the proper agreements and be trusted with issuing and making good on their debt.  And it will also be a fantastic open ledger for work buddies to trade their lunch money around.  But between these two groups, there will be this HUGE donut hole of people in the middle who will erroneously presume that because Ripple works for lunch money and the babysitter, and because they hear it also works for bigshot rich people to settle monstrous sums, that they should feel OK using Ripple to manage large undocumented debts for things like cars, vacations, bad investments, gambling losses, and all kinds of things... people are going to get their financial backsides seared and blackened repeatedly until they learn the hard way that they should not accept any "debt" as payment that they won't mind being 100% defaulted on... at which point it ceases to be revolutionary and they may as well just use PayPal.

[JoelKatz]

Yes, Ripple will make a fantastic open ledger for managing and settling debt among parties sophisticated enough to form the proper agreements and be trusted with issuing and making good on their debt.  And it will also be a fantastic open ledger for work buddies to trade their lunch money around.  But between these two groups, there will be this HUGE donut hole of people in the middle who will erroneously presume that because Ripple works for lunch money and the babysitter, and because they hear it also works for bigshot rich people to settle monstrous sums, that they should feel OK using Ripple to manage large undocumented debts for things like cars, vacations, bad investments, gambling losses, and all kinds of things... people are going to get their financial backsides seared and blackened repeatedly until they learn the hard way that they should not accept any "debt" as payment that they won't mind being 100% defaulted on... at which point it ceases to be revolutionary and they may as well just use PayPal.

To fill the donut hole, we need reliable gateways. If we don't have that, you're absolutely right, it's not usable for medium-sized transactions denominated in fiat currencies. (At least not without real community credit which, if it ever happens, is certainly far off.) We have a lot of things built into the system to encourage the creation of reliable gateways, we'll see if it works.

As for the benefits of Ripple versus something like PayPal, see the list I posted previously. Key advantages are lower fees, cross-currency transactions, the inability of a single entity to freeze your funds, higher speed, no chargebacks, the ability to easily change who handles your money without changing payment arrangements, and so on.

The big advantage of Ripple here, I hope, is competition. It would be like if you could choose PayPal and I could choose Dwolla and we could still pay each other seamlessly, with me putting money into Dwolla and you pulling money out of PayPal. We could choose the service that best covers our needs or our location. And if PayPal decides they have a problem with me because someone stole my identity a decade ago and they give me a lifetime ban (long story), I can move my business to another service without disruption.

[Anth0n]

Destruction of RXP for each transaction is bad economics. The number of transactions will continually decrease since the supply of RXP will continuously decrease, meaning RXP value will increase. People will begin to value their RXP more than they value their transactions, so the RXP fee per transaction will have to be manually adjusted to get people making transactions again. Ultimately what you will have is an economy dependent entirely upon a centrally-managed currency. It's exactly the opposite problem of inflationism in the real world.

[JoelKatz]

Destruction of RXP for each transaction is bad economics. The number of transactions will continually decrease since the supply of RXP will continuously decrease, meaning RXP value will increase. People will begin to value their RXP more than they value their transactions, so the RXP fee per transaction will have to be manually adjusted to get people making transactions again. Ultimately what you will have is an economy dependent entirely upon a centrally-managed currency. It's exactly the opposite problem of inflationism in the real world.

The cost of transactions is managed by consensus much the same way as which transactions get into the ledger is managed by consensus. The system has a 'base_fee' that all other fees and reserves are based on. A node can introduce a transaction to change the base fee. If a trust-weighted majority of nodes vote "yes" on the transaction, it will be incorporated into the ledger and the fee will be changed.

Even without this, if there's a consensus that the transaction fee is too high, nodes could just propagate and vote "yes" on transactions with lower fees.

[DeathAndTaxes]

OP is totally wrong.  Ripple doesn't even sound nice.

[misterbigg]

A node can introduce a transaction to change the base fee. If a trust-weighted majority of nodes vote "yes" on the transaction, it will be incorporated into the ledger and the fee will be changed.

Now this is exactly what I am talking about. You go and claim this enormous feature, and there is no algorithm given.

You're saying that you have already implemented a secure system for generalized decentralized consensus and deployed it to Ripple? I find that extremely difficult to believe. Claims like this are abundant throughout the Ripple framework. But there is a dearth of explanation.

[JoelKatz]

A node can introduce a transaction to change the base fee. If a trust-weighted majority of nodes vote "yes" on the transaction, it will be incorporated into the ledger and the fee will be changed.

Now this is exactly what I am talking about. You go and claim this enormous feature, and there is no algorithm given.

You're saying that you have already implemented a secure system for generalized decentralized consensus and deployed it to Ripple? I find that extremely difficult to believe. Claims like this are abundant throughout the Ripple framework. But there is a dearth of explanation.

Feel free to ask any specific questions. I thought I already pointed you to where the consensus process is explained in the wiki.

It's basically this:

1) Nodes announce the hash of the last closed ledger. To keep things simple, I'll assume we start from a consensus.

2) Nodes propose the hash of the tree of transactions they think should be applied to the ledger in this consensus window.

3) Nodes acquire the transactions other nodes have proposed.

4) Nodes form disputed transaction entries for transactions so long as at least one node they trust included that transaction and one didn't.

5) Nodes avalanche to a consensus on each disputed transaction by going with the majority weighted based on their trust.

6) If avalanche stalls, the agreement rate requires to get a transaction into the consensus set is raised.

7) As nodes detect that the nodes they trust have reached a consensus, they apply the consensus transaction set and publish a validation of the next ledger.

8 ) Validations push other nodes towards consensus.

9) Nodes acquire sufficient validations from other nodes they trust of the new ledger and consider that the next accepted ledger.

10) If any new transactions occurred during the consensus process or any valid transactions didn't get in, a new consensus process starts immediately.

This trust is just trust not to collude. See the wiki page on consensus.

The main reason it works is:

1) Every honest node wants a consensus. They will wait as long as it takes in order to get one. We have no fixed amount of time in which a consensus must be reached.

2) There is no moving target during a consensus window. With respect to establishing that consensus, the world is frozen. There is a fixed amount of information to be known about the state, and more information is always gathered by nodes. They don't forget anything. The ratcheting up of the agreement level required ensures a consensus will eventually be reached.

3) Dishonest nodes cannot stop transactions from propagating to the vast majority of honest nodes. A node would have to have every single one of its connections to a dishonest node. (And we imagine 'core' nodes agreeing to directly connect to each other as a safety.)

4) So long as a transaction can be applied to the ledger and the vast majority of nodes see it before the consensus window, there's nothing dishonest nodes can do to stop honest nodes from including it. (Nodes will extend the consensus window if they aren't getting votes or acquiring transaction sets from trusted nodes that have voted.)

5) If a transaction does not get into a consensus set, but is valid, every honest node that has seen that transaction will vote to include it in the next consensus set.

6) No honest node particularly cares what's in the consensus set, provided it includes transactions that were seen well before the consensus window started. There is no way a dishonest party could get something into the transaction set that shouldn't be there and have that cause any harm. Invalid transactions will have no effect, even if they get in the consensus set.

I'd be happy to answer any further questions you have.

[misterbigg]

6) If avalanche stalls, the agreement rate requires to get a transaction into the consensus set is raised.

What if one node believes the avalanche has stalled, but another node doesn't?

Where's the part where base_fee is negotiated up or down and finally changed?

[JoelKatz]

What if one node believes the avalanche has stalled, but another node doesn't?

Then one node will raise the agreement rate and the other won't. It doesn't particularly matter. The ratcheting up of the agreement rate is only to keep the rate from "puttering" around 50%. If we just used strict majority, and the starting position was about half the nodes saying yes and half no (say because a transaction was introduced just as the ledger closed), you could stall around 50% for a long time, some nodes seeing say 53% and some 46%. To prevent this, nodes have an internal bias that increases over time towards excluding a transaction. This prevents the long stall.

Essentially, the entire system has a huge bias towards excluding a transaction. So long as a transaction remains valid, every honest node that saw it before a consensus window starts will try to include it in that consensus window. So unless the network is heavily overloaded or most nodes trust mostly dishonest nodes, the transaction will get in during  the next consensus window anyway.

This is the key trick to the way our system works. If a transaction should unambiguously no questions asked get in, then every honest node will vote yes on it. If it shouldn't unambiguously no questions asked get in, then nobody particularly cares whether it gets in or not, and not letting it in is perfectly fine. If enough nodes disagree about a transaction for it to stall the consensus process, then honest nodes just switch to no. They value consensus over getting in a transaction that lots of trusted nodes think doesn't belong.

Where's the part where base_fee is negotiated up or down and finally changed?

Any node can introduce into its consensus set a transaction to raise or lower the transaction fee. I think we have a rule that only certain ledgers (like one every 256) can have a fee change transaction in them. This is to prevent needless momentary disagreement on every ledger while some nodes want one fee and some another. A fee change transaction either gets voted into the consensus set or it doesn't. If it gets voted in, it is applied and the fees change from that point on.

The current server just votes no on all transaction fee changes. We plan to add a configuration element to set what you think the fees should be and then your server will introduce and vote yes on transactions to change the fee to the fee you set.

We also have a mechanism, I forget whether it's implemented for fee changes specifically, where a node can introduce into specific validations what it thinks the fee should be. This also is done on specific "flag" ledgers. So on flag ledger X, you can put in your validation that you think the fee should be Y. Then on ledger X+2, everyone looks at the validations for the flag ledger to see if there's a super-majority for fee changes. This also helps to void a needless momentary disagreement and it allows nodes to use a more sophisticated algorithm to decide what fee to propose Say the fee is 10, and you think it should be 12, and half your weighted trust wants 11 and half wants 12, you might want to vote yes on 11.

[misterbigg]

...

Do you realize that this explanation is rather lacking? Saying "nodes have an internal bias that increases over time towards excluding a transaction" offers no clear insights in writing out an outline of the algorithm. Compare your explanation with an excerpt from the original Bitcoin paper:

The steps to run the network are as follows:
  1)New transactions are broadcast to all nodes.
  2)Each node collects new transactions into a block.  
  3)Each node works on finding a difficult proof-of-work for its block.
  4)When a node finds a proof-of-work, it broadcasts the block to all nodes.
  5)Nodes accept the block only if all transactions in it are valid and not already spent.
  6)Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.

Perhaps you could provide an outline similar to the one from the Bitcoin paper that provides a step by step explanation. You said "the entire system has a huge bias towards excluding a transaction" - what does that even mean, in formal terms? What's this "agreement rate" and what is the algorithm for increasing it? Does it go up by 10% each time?

Where's the beef!

[JoelKatz]

Do you realize that this explanation is rather lacking?

Yes. It's an outline.

Saying "nodes have an internal bias that increases over time towards excluding a transaction" offers no clear insights in writing out an outline of the algorithm.

I'm not sure I follow you. If you want more details, I can provide them. The basic idea is very simple -- a node looks at how long the consensus process has in progress compares to how long the previous consensus round took and adjusts the threshold for a yes vote up from 50% based on that time period.

Perhaps you could provide an outline similar to the one from the Bitcoin paper that provides a step by step explanation. You said "the entire system has a huge bias towards excluding a transaction" - what does that even mean, in formal terms?

It's a summary description of a lot of things, for example, no votes on transactions are implicit, you just don't vote yes on them. And, as I mentioned above, nodes increase the number of nodes they require to vote yes to keep their own vote at yes oevr time.

What's this "agreement rate" and what is the algorithm for increasing it? Does it go up by 10% each time?

Actually, that's still being adjusted. The current algorithm is as follows:

1) Until 50% of the time the previous ledger's consensus took has passed, 50%.

3) From 50%-85% of the time the previous ledger's consensus took, 65%.

4) From 85%-200%, 70%.

5) From 200% on, 95%.

That is, initially, if 50% of your weighted trust list (including yourself, if you believe you are synchronized) votes "yes" on a transaction, you vote yes on it. Once 50% of the time the previous consensus process took has passed, this goes up to 65%.

A two second minimum is enforced on a consensus round to ensure that well connected nodes have enough time to get an initial proposal in. In addition, nodes won't let a consensus close significantly more quickly than the previous round, for the same reason.

This algorithm actually is about to be adjusted. It has a slight defect  -- the first round of dispute resolution could occur after 85% of the time the previous round took has passed, resulting in transactions getting excluded without reason. Though harmless, this effect wasn't intended. Most likely, it will instead slide gradually up rather than in steps.

There is no harm in conflicting transactions both getting voted in -- a deterministic algorithm ensures only one of them will actually get applied and nodes will agree on which. The same applies if two conflicting transactions each bump each other out -- a deterministic algorithm determines which one all honest nodes will vote yes on in the next round.

[justusranvier]

The basic concept of trading debt along a social network graph seems straightforward enough to me, but I have difficulty seeing how it will actually work in practice. This could be because I lack imagination in this area or because the idea has major problems; I'm open to both possibilities. These are some of the questions that came up for me after experimenting with the site for a while:

At first glance it doesn't look like Ripple is useful at all until a critical mass of users sign up and assign trust. How do you bootstrap the network especially since the concept seems to be even harder to explain than Bitcoin? Have existing major players in bitcoin commerce already bought in to the concept and plan to use Ripple as soon as it's ready? In terms of actual usage Ripple most closely reminds me of #bitcoin-otc or localbitcoins.com. Is Ripple a replacement for, or an enhancement to these services? Are there any plans to link Ripple to them in any way so that existing trust relationships could be incorporated somehow and/or Ripple data exported to them?

Can you document somewhere how Ripple can be used in situations that people are already familiar with so that it's easier to understand how the concept can be expanded to more advanced transactions? For example, how could a group of coworkers use Ripple to keep track of whose turn it is to buy lunch?

Let's say I owe a friend $20 due to some pre-Ripple interaction. Once we both get accounts, is there any way to import this existing IOU into the Ripple ledger?

Finally, why is it so difficult to find out where to get XRP? I only managed to be able to use my Ripple wallet because I was lucky enough to find someone in #bitcoin-otc who would sell me a small amount. I don't have enough to give to some friends to test out the concept and I can't find out where to get more.

[sounds]

I'm with justusranvier: trading debt isn't nearly as useful or valuable as what bitcoin offers.

Ripple may have a nice rise but I predict it will succumb to a bubble once the initial enthusiasm wears off.

[JoelKatz]

At first glance it doesn't look like Ripple is useful at all until a critical mass of users sign up and assign trust. How do you bootstrap the network especially since the concept seems to be even harder to explain than Bitcoin?

That's what gateways are for. A gateway is a company who enters into "redeem on demand" agreements with large numbers of people. They serve as gateways to get money into and out of the system. As soon as enough people hold IOUs from more than one gateway and are indifferent to which gateway's IOUs they hold (or arbitragers provide liquidity at a profit), then most paths will be user->gateway->intermediary->gateway->user.

Have existing major players in bitcoin commerce already bought in to the concept and plan to use Ripple as soon as it's ready?

All I can say is wait and see.

In terms of actual usage Ripple most closely reminds me of #bitcoin-otc or localbitcoins.com. Is Ripple a replacement for, or an enhancement to these services? Are there any plans to link Ripple to them in any way so that existing trust relationships could be incorporated somehow and/or Ripple data exported to them?

We don't see personal credit as a major application for Ripple in the short term. We see it more as a competitor to things like credit cards and services like PayPal. I agree that community credit is hard to use and understand, but I personally believe that in the long term, it could revolutionize money.

Can you document somewhere how Ripple can be used in situations that people are already familiar with so that it's easier to understand how the concept can be expanded to more advanced transactions? For example, how could a group of coworkers use Ripple to keep track of whose turn it is to buy lunch?

Just decide how many lunches you want to allow each coworker to owe you. When someone buys you lunch, you pay them one lunch. They now either hold a "1 lunch" IOU from you or you've destroyed an IOU they held from you. If I owed you a lunch and someone owed me a lunch, you could take that IOU from me in payment and use it to get someone else to buy you lunch.

Let's say I owe a friend $20 due to some pre-Ripple interaction. Once we both get accounts, is there any way to import this existing IOU into the Ripple ledger?

Yes. They would have to allow you to owe them $20 on the Ripple system, and then you would pay them $20 (in your own IOUs). They would then consider the $20 debt novated by the IOUs in the Ripple system. (God bless you! I've been looking for an excuse to use the word "novated" for more than two years now.)

Finally, why is it so difficult to find out where to get XRP? I only managed to be able to use my Ripple wallet because I was lucky enough to find someone in #bitcoin-otc who would sell me a small amount. I don't have enough to give to some friends to test out the concept and I can't find out where to get more.

We're planning to begin giving away XRP shortly. We're currently releasing them slowly to manage load and use as we work through deployment and scaling issues. Stay tuned.

[justusranvier]

We don't see personal credit as a major application for Ripple in the short term. We see it more as a competitor to things like credit cards and services like PayPal. I agree that community credit is hard to use and understand, but I personally believe that in the long term, it could revolutionize money.

In that case I don't understand what problem you're solving. Personal credit seems to be the only innovation Ripple brings to the table because the others are already being solved by Bitcoin.

[JoelKatz]

We don't see personal credit as a major application for Ripple in the short term. We see it more as a competitor to things like credit cards and services like PayPal. I agree that community credit is hard to use and understand, but I personally believe that in the long term, it could revolutionize money.

In that case I don't understand what problem you're solving. Personal credit seems to be the only innovation Ripple brings to the table because the others are already being solved by Bitcoin.

Bitcoin doesn't allow people to pay each other in fiat currencies or across currencies. If you wish to transact only in Bitcoins, then I agree with you, about all Ripple offers is community credit. Think of Ripple as a way to make dollars more like Bitcoins. (With both the advantages and disadvantages that entails.)

[justusranvier]

Bitcoin doesn't allow people to pay each other in fiat currencies or across currencies.

Bitcoin payment processors and exchanges do though.