Bitcoin Forum

tldr: Ripple doesn't require anymore trust than bitcoin

---

I see a lot of people misunderstanding the way Ripple works so I'm going to attempt to clarify.

There are two pieces to the ripple system, XRP and IOUs.

XRP works essentially like bitcoin. No counter party risk. You can send xrp to anyone with a ripple account. No trust etc.

The IOUs are more complicated. Every IOU has an Issuer and a Currency. The Issuer is simply a ripple account. You can only hold IOUs from issuers you have agreed to trust.

A gateway is some business that has agreed to issue and redeem ripple IOUs. You take your money to a gateway and the gateway gives you a ripple IOU. You can send this IOU to other people, trade it for XRP or BTC or whatever. You can take your IOU back to the gateway and the gateway will send you money. This is essentially what paypal or dwolla or banks do now.

This is the same as sending USD to mtgox. You are trusting mtgox to the amount you have sent in. You can send that USD to another person that has chosen to trust mtgox in the form of a mtgox code.

So you can see that Ripple doesn't require more trust or counter party risk then you are already used to.

The powerful thing is that Ripple links all these gateways and that there is an exchange in Ripple where you can swap these various IOUs so you can trade between all kinds of currencies and issuers.


We hope to explain things better on ripple.com soon.

thanks for the explanations, I think this helped a bit (still need to sleep to let everything sink in).

A key for me is that XRP is not like the other currencies. They are a real "commodity", like bitcoin.

Are there XRP IOUs at all?

One question the answer to which might shed more light into my mind: Say by brother and I both use ripple and after a while we determine he owes me 10 EUR (or he owes "the world" 10 EUR and "the world" owes me 10 EUR). Would it be possible for him to give me a 10 EUR bill in meatspace and somehow reflect this "settlement" into the ripple system?

So how does the system protect against credit default swap shenanigans?  I never understood that with the original Ripple system, and I don't understand it with the current one.

In the lead up to the 2008 downturn, significant sums had to be spent to change regulations to enable the swaps and create loopholes to consolidate banking power.  But Ripple is devoid of those protections by default, so it seems the system would actually make the mortgage crises default chain several orders of magnitude cheaper to implement.

I think if he gives you a 10 EUR bill in meatspace, you use the ripple system to send him 10 ripple-Euros. From his and your point of view, everything is settled.

I don't think this is the same what paypal or dwolla or banks do. Why do you think, say USD IOU issued by gateway A will always be in par with USD IOU issued by gateway B?

Duh! Thanks for the kick. Yes of course, it's that simple.

I think I really need sleep now.

> Are there XRP IOUs at all?
nope

> Why do you think, say USD IOU issued by gateway A will always be in par with USD IOU issued by gateway B?
They might not be. there can easily be an exchange rate between them in the distributed exchange.

>I think if he gives you a 10 EUR bill in meatspace, you use the ripple system to send him 10 ripple-Euros. From his and your point of view, everything is settled.
yep


>So how does the system protect against credit default swap shenanigans?
What are you exactly worried about? I have a feeling it isn't credit default swaps since that is a complicated financial instrument that doesn't really apply to ripple.

Thank you OP for the explanation, because I was pretty confused until now.

So the level of trust required to use Ripple is the same as I need to use, say Mt Gox.  Is that correct?

Is it possible for one of these gateways to run off with a bunch of currencies?  Or to get hacked?

How are XRP's accounted for?  How are they prevented from double spends?

of course: BitStamp is currently holding BTC 1 of mine (blockchain real BTC). They could just run with it.

cannot give you a qualified answer, but maybe this: https://ripple.com/wiki/Consensus is involved.

See this post: https://bitcointalk.org/index.php?topic=145558.msg1545061#msg1545061

This is the key part:

So I can't transfer 10 ripple USD issued by gateway A to a merchant that is pricing their products in ripple USD issued by gateway B without exchanging them first? That will lead to doubling the fees for every transfer. 1 XRP for the exchange and 1 XRP for the actual transfer?

If there are 1 million gateways issuing ripple USD how many currency pairs will we have in ripple USD being both base and counter currency? There are also euros, pounds, yen, franks etc. This will be speculator's heaven and a price chaos?!

Welcome to the free market. :)

-MarkM-

They won't always be on par, but if the gateways are doing their jobs, it should almost always be very close. Every failure is a profit opportunity.

Yes but no. A payment will take from offers if that's the best payment path. When making a Ripple payment, this is the typical payment mechanism:

1) The client gets the destination account and destination currency from some source. ("Pay Jeff 50 Bitcoins.")

2) The client looks at what the user holds and picks one or more source currencies to use.

3) The client asks the server what its options are. The server forms payment paths using the various possible source currencies taking into account what the destination will accept. These payment paths can ripple through accounts that hold and accept multiple IOUs but also offers. No transactions have been performed yet, so this is all free.

4) The client tells the user something like "You can make this payment for 50.03 bitcoins or 125 USD."

5) The user picks a source currency.

6) The client assembles one final transaction, incurring one fee. The transaction can include multiple paths (so long as they use the same source currency). The transaction can include a "maximum to spend" and the transaction will fail if it would cost more than that.

7) The client submits the transaction. The servers process it. The transaction is accepted. (The servers will take incrementally from more than one path of the paths explicitly specified in the transaction to get the best result.)

Notice that only one transaction is needed, even if you ripple through multiple accounts, take from multiple offers, and so on. The one and only transaction is basically "get Jeff 50 bitcoins he'll accept and don't charge me more than 50.03 Bitcoins to do it."

Possibly. But I don't see why that will be bad. Since there will be many possible paths for the same transaction, costs should typically be low. We'll see.

A possible suggestion/thought:

On the one hand I think it's a good idea for the client to hide such complexity as explained above from the user (displaying just the maximum cost and stuff).

On the other hand it would carry much "educational value" to actually show the complexity in the client (differenct payment paths, lot of work I'm sure).

This also goes for other things like the balances (these could be split by different issuers, right?)

There's nothing in the ripple system to stop evil gateways.

Suppose I have various lines of trust with other people and organizations, including with Pirate's gateway. I have "deposited" $50 with Pirate. In return I have an IOU from Pirate valued at $50.

At some point, I start to feel uneasy about Pirate, so I remove the trust that I extended to Pirate. Am I correct that the $50 owed to me by Pirate then automatically becomes $50 owed to me by others, specifically those whom I trust and who in turn trust Pirate themselves (and who have not "maxed out" their Pirate balance)?

Then when Pirate defaults, I try to collect from those people. Not surprisingly, they don't feel like paying me and they default too. It could turn ugly fast. Those who are quick to spot the scam will modify their lines of trust fast enough to ensure that everyone else is stuck with the worthless Pirate IOUs.

Or am I missing something here?

When you stop trusting Pirate his IOUs you hold are not automagically traded away. You need to trade them away yourself by looking for offers, or over time as others happen to Ripple through you, assuming anyone actually does Ripple through you, they should gradually get exchanged away / used.

-MarkM-

OK as I understand it Bitstamp is one of the only functioning gateway atm. 

So Bitstamp lists Ripple as being possible to deposit.  So I "trusted" them and I deposited 1000xrp.  Now they seem to be gone.  No balance listed on Bitstamp anywhere.  I have contacted them 3 times with no reply.

Am I missing something or was I too quick on the trigger?

Gateways hold fiat, not XRP. There is no reason to deposit XRP with a gateway. We're working with Bitstamp to make sure XRP sent to them by mistake are returned.

Thank you very much sir.

EDIT: Bitstamp wrote me an email:


It has not been returned as of 24 hours.  Not real worried about anything just curious where they went.

Hi there, it seems like a nice system. I have got couple of questions though.

1. Are there implemented any special rules for gateways, or is this just something that everyone can do?

2. Is BTC issued by A and B the same currency? As they may have different exchange rates, I think they are different. But it seems that when a payment goes through the system, they are treated as the same BTC, right? Or are users supposed to set exchange rates between various BTC? Probably they should; e.g. if I think that BTC issued by me are much safer than BTC issued by my friend, then as a payment goes through us, I would only agree to issue 0.9 BTC for receiving 1 BTC issued from him. What are the intentions about this?

3. What happens if there is a debt but no trust limit? I managed to buy some BTC but without extending a trust limit to the seller issuer first. Also it appears that some orders could be created with similar results. Other way to get into this situation is possibly to remove the limit after the debt exists. Shouldn't this be restricted somehow? Or should it be not restricted and the trust limits would only be informative? Actually why should I pressure friends about settling their debts at all? It may be something about that they can't pay me anymore, but hey, I could extend their trust limit further coz it's just a number?

We call an entity a "gateway" if it has certain characteristics. If you have these characteristics, we'll call you a gateway. If you have some of them but not all of them, some people may call you a "gateway" and some may not. You can do whatever you want.

Generally, we call a company a "gateway" if:

1) They offer a reasonable "redeem on demand" agreement to a large group of people.

2) People have good reason to value their IOUs at close to face value.

3) They make it their business to issue IOUs.

But you can do most of what a gateway does without being a gateway. For example, you can sell Bitstamp IOUs to people face to face. You can buy Bitstamp IOUs from people face to face for cash.

In some cases they are treated as the same currency, in some cases they are treated differently. The system does allow you to value IOUs in the same currency but different issuers differently, but this is a very tricky feature to use correctly. The main difference is this: To change the issuer of an IOU but not the currency, you can ripple through someone. To change the currency, whether or not you change the issuer, you must take one or more offers.

I think the scenario you're envisioning is this:

1) I deposit 10 BTC at a gateway using a Bitcoin transaction.

2) I don't extend trust to that gateway.

3) I try to withdraw the 10 BTC to my ripple account.

What happens depends on the gateway's policy. First, they can't give you their own IOUs since you don't accept them. And if you don't accept any BTC IOUs, the operation is impossible and will fail. But say you accept BTC IOUs from some other gateway. They could make the withdrawal work. There it's up to their policy. Possible policies are:

1) They just don't allow it. You must extend them credit to withdraw, period.

2) They allow it so long as it won't cost you more than 1%. So you may wind up with 9.9 BTC in your account.

3) They allow it at any loss level, provided you agree to accept the loss.

You can drop a credit limit below the level of IOUs you hold. This indicates you don't want to hold those IOUs any more. People can now take them from you but not give them to you. If you're an attractive path for them, they should fix it for you over time.

If you extend them trust, you're allowing them to take IOUs you hold and to give others your IOUs! Unless you don't hold any valuable IOUs in that currency and don't care if other people hold your IOUs in that currency, this is *not* a good idea.

I've started to replace "trust" with "deposit", coupled with each of us, and each gateway, essentially functioning like an unregulated bank (IOUs = banknotes) and it all makes a lot more sense.

Of course, this is only half of it, the other half is the currency part which is also interesting.  I like the idea of giving everyone enough to last their lifetime, too bad the giveaway is suspended until Monday.

Yeah, "trust" isn't the right word. It would be better to replace it with "risk".

Instead of saying "I trust the PayPal gateway for $100" we should say "I'll risk $100 with the PayPal gateway".

Hi, thank you for the answers.


So bitstamp doesn't have any special privileges in the system. Ok.


So if I get it right, when making payments the system values my 1 BTC IOU the same as my friend's 1 BTC IOU. Not ok.
It's meant be the complicated way so when a payment goes through the users, they get exchanged also debts in the same currency at arbitrary rates.


No, I just placed an exchange order for buying BTC, it got executed, and I received BTC - without any trust to the issuer. I didn't really mind but it seems it goes around the limits.


But somehow I can image some people doing so, thinking like how they are gaming the system.

Anyway, as we discussed elsewhere, there is this XRP currency which is an element outside of ripple, and which ripple traditionalists can't wrap their heads around.

Placing an offer to buy an IOU implicitly extends trust to hold the IOUs that result from people taking the offer. We had to do it one way or the other and neither is exactly what you want in all cases, but this is probably what you are more likely to want most of the time.

Touching on a point made earlier - currently, BTC-E rates are about 97% of MtGox rates (29.00 BTC-E vs 29.75 MtGox)

If both become active ripple gateways, would the bitcoin/usd exchange rates merge, or would BTC-E USD trade at a 3% discount to MtGox USD?

Ah! This is in interesting piece of info. Joel, thanks for taking the time to explain everything to us. Someone has to do it ;)

This might be helpful: https://ripple.com/wiki/Transit_Fee (https://ripple.com/wiki/Transit_Fee)

The people who provide liquidity between them might end up putting them at different qualities, which would do exactly what you described. All put together, there'd be a complicated equilibrium between the various Ripple BTC/USD exchanges, the transit fees and debt qualities of the liquidity providers, and countless other effects. In any situation where they're not trading 1 for 1, there's potentially a profit opportunity for arbitrageurs. Whether that's profitable in at any given moment ultimately depends on the fees for moving real-world funds between the various exchanges and gateways, as well as the amount of risk associated with holding funds in any particular gateway.

I suspect in practice Ripple would have the effect of removing a lot of the friction in moving funds between exchanges, making the exchange rates closer on average than they are now.

Okay, from what I see in Ripple here is my suggestion:

1. The principal mistake with XRP, it might be a result of the commercial nature of the project, is that it is created as a currency. XRP has to be a bond, not a currency!
2. The bond issuer must not be a single company but the pool of Ripple severs that maintain the shared Ledger. The bond holder should be every Ripple customers that is willing to transact on Ripple network. This is why customers must purchase these bonds in advance.
3. XRP bonds will represent transaction reference/numbers reserved on the General Ledger for future transactions. Bonds are redeemed if they are attached to a transaction. Until used (redeemed) they can be freely sold to new owners at market rates using Chaum's blind signature mechanism to transfer ownership and later verified by the issuer when redeemed by a digital bearer.
4. XRP bonds will have expiry date (the needed demurrage effect), say 3 months or 6 months after they are issued by the issuer. After this period they are considered null and void. This is why bond holders will have incentive to sell them if they think they've more bonds than they'll need to pay with for their transactions. The number of currently issued and not redeemed XRP bonds as well as their respective expiry dates must be absolutely transparent to the entire system in every single minute!
5. Very convenient tool to issue XRP (as tn bonds) is offered by colored bitcoins project. Actually, XRP bonds will be colored bitcoins! After they are redeemed or expire XRP bonds are just ordinary bitcoins.
6. Different transaction types on Ripple network must require different number of XRP to be paid (redeemed) by the user. It must be a dynamically defined number depending on current server load as well.
7. The IOU's must have expiry date as well. Never forget, Ripple servers will have to maintain the network irrespective of customers' activity! If used in a transaction that changes the record kept at the corresponding gateway then their expiry date is automatically extended. In other words, if IOUs are used as cash-only they must have maximum life span like bank bills are worn-out while changing hands.
8. A mechanism for internal competition between Ripple servers issuing XRP bonds must be set in place to ensure maximum value for bond holders.
9. A proof of work must be implemented before a server is allowed to become a part of the pool issuing XRP bonds!
10. Very strict economic model must be developed for all the participating groups maintaining Ripple network so that they all have equal potential for profitability.

Ripple server is the key indeed and more can be suggested only after its source is opened.

Anyone from Ripple developers willing to comment my suggestions above?

My understanding is that developing XRP into a more or less functional currency is a monetization strategy of OpenCoin founders. They were very careful not to discuss it in public, and Joel Katz even mentioned that he is prohibited from discussing it here on Bitcointalk.

The fact of the matter is, OpenCoin has very little choice in this respect, some sort of "pre-mining" is the only viable monetization strategy for distributed platform such as Bitcoin or (potentially) distributed platform such as Ripple. Bitcoin-based premined altcoins tried this strategy and failed, but they did not bring any essential value to cryptocurrency ecosystem to justify pre-mined bonanza for their founders.

Ripple, on the other hand, has the promise of creating fully decentralized exchange ecosystem as well as decentralized instant payment framework. Thus solving two main problems of Bitcoin community: dependency on fiat exchanges and blockchain bloat. So, they may yet succeed where others utterly failed.

BULLSHIT

XRP could easily be distributed via proof of work. Miners would then sell XRPs for IOUs of their choice on the open market using Ripple's order book. Then we would have a truly free market for XRPs, and they would quickly converge on the market clearing price perfectly balancing demand with supply. Anyone could jump into the mining game. In fact, all existing Bitcoin miners and mining pools would have a great incentive to merge-mine for Ripple XRPs. This miner revenue from producing XRPs would not only ensure that the XRPs are distributed in the most fair way possible but also improve the security of the Bitcoin network by increasing the profitability of SHA-256 based mining.

Edit: Oops...re-reading your post I see you said that "pre-mining" is the only way for the founders to enrich themselves by taking advantage of the asymmetry of information. I guess you're right. But still, proof of work would have been a lot more fair.

You do know that XRP aren't suppose to be a currency so disturbing them in that proof of work situation like bitcoin or litecoin would do no good. XRP are more like way you pay fees and get your account on the ledger. So giving them out would make the most sense since they will most likely represent another currency.

XRP is the pivotal point of ripple system. Not discussing it would be a very shortsighted strategy. Once they open the ripple server anyone can fork it and do the right thing!

I'm a little lost here. I've been trying to play around with someone I trust IRL (TTBit) and we managed to understand a bit more of the system's workings but got stuck in this workflow (value are bogus, but relatively equal to what we're doing, and we all trust each other and bitstamp):

TTBit deposited BTC to Bitstamp
TTBit sent BTC from Bitstamp to Ripple
-- at this point TTBit has 2 BTC of green line on ripple BTC trust --
TTBit sent 0.15 BTC to nelisky
nelisky tries to send 0.15 BTC to bitstamp, which fails with "Fees are insufficient"
nelisky tries to send 0.10 BTC to bitstamp, which fails with "Path could not send partial amount"

So what are we missing here?

Hmm, it sounds like that last send should have worked. When TTBit sent .15 BTC to nelisky, that was likely TTBit/BTC that got sent, since nelisky takes those. So when nelisky tries to send .1 BTC to Bitstamp, nelisky must use TTBit IOUs through TTBit to Bitstamp. Did TTBit hold a little over .1 bistamp BTC? Perhaps TTBit just didn't have enough Bistamp/BTC IOUs.

It could also be that our pathfinding found an incorrect or inferior path. We have some pathfinding issues that we're still working on. If you PM me the actual amounts and Ripple addresses, I can actually manually ask the system to compute the various paths and parameters and see if it's doing the right thing.

At all times TTBit held more than enough Bitstamp IOUs. Could TTBit have sent the BTC IOU if I didn't trust TTBit/BTC?

I will try again today and if still failing will PM you all the details.

Yes, if you trusted Bitstamp. The payment would still have taken place, but it would have used Bitstamp IOUs and cost a tiny bit more.

For TTBit to be able to send 0.15 BTC to nelisky...

1) nelisky previously trusts TTBit/BTC

or

2) nelisky previously trusts bitstamp/BTC (which TTBit currently holds)

These are the only BTC balances I have. (Bitstamp is rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B). I would think it should work, yes? Or is more information required?

https://dl.dropbox.com/u/12679676/pichost/rp34frir.jpg

I have extended a small amount of btc trust to many forum members. No open orders.

We believe we fixed the bug that was causing paths not to be found or inadequate paths to be selected. Please let me know if you're still experiencing the problem.

It's pretty much the exact same, I'm afraid. Full amount (0.15) complains about partial amounts, less (0.1) complains about fees.

I created another wallet for holding funds for one of my services, and for playing with the RPC interface. I was trying to make payments in very much the same manner, i.e:
- Deposited BTC to Bitstamp
- Withdrawn from Bitstamp to Ripple
- Tried to send from Ripple to another account that trusts Bitstamp (but not the sender)

{'Account': 'rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P', 'Destination': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E', 'Amount': {'currency': u'BTC', 'value': '0.019960', 'issuer': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B'}, 'TransactionType': 'Payment'}

{u'status': u'success', u'type': u'response', u'result': {u'tx_json': {u'status': u'invalid', u'Account': u'rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P', u'Fee': u'10', u'hash': u'097BDC7AA77F3FDF7A73D850D69F70AEF8AC7705E2616D5BB6E287EB3886B183', u'Sequence': 10, u'SigningPubKey': u'02BCB4677183FD6B5654E10AED5AD04007480950C2652852DFAE4AE4C98A9D3EF0', u'Destination': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E', u'Amount': {u'currency': u'BTC', u'value': u'0.01996', u'issuer': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B'}, u'Flags': 0, u'TxnSignature': u'30450220395913ABE851C103E72C8F29531EFF745B82C35DCE6DB1A22E8B78D24B71032B0221009 89E7089D9A0D357908DDB78C9052F74B8FB81C7F2B847677B75F02CF80E4489', u'TransactionType': u'Payment'}, u'engine_result_message': u'Path could not send full amount.', u'engine_result_code': 101, u'tx_blob': u'1200002200000000240000000A61D4071759F6F8C00000000000000000000000000042544300000 000000A20B3C85F482532A9578DBB3950B85CA06594D168400000000000000A732102BCB4677183 FD6B5654E10AED5AD04007480950C2652852DFAE4AE4C98A9D3EF0744730450220395913ABE851C 103E72C8F29531EFF745B82C35DCE6DB1A22E8B78D24B71032B022100989E7089D9A0D357908DDB 78C9052F74B8FB81C7F2B847677B75F02CF80E44898114C9122B5BAFD0FF74863351B569DF2894B 6A011FE8314A6473D67D54E36ED960CC45526D78345C96FAE5A', u'engine_result': u'tecPATH_PARTIAL'}}

The rKLw account has 0.15 btc IOU from Bitstamp, the rGwU account trusts Bitstamp for 1 BTC, the rvYA account is Bitstamp. Am I doing something wrong or is this just another case of bad path resolve?

The only BTC funds that rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P holds are 0.1 rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B IOUs. The issuer of those IOUs charges a .2% transfer fee when its IOUs are moved from one customer to another, so the most you can deliver is 0.0998003992015968 BTC.

Yes, 0.1, sorry for confusing things. 0.15 was on the other use case. Still, if you look at the transfer I'm attempting you'll see I only try to move 0.019960 BTC (that's 0.02 minus the 0.2%) and that fails. I try a second transfer for 0.08 minus 0.2% and that fails in exactly the same way. I never try to move more than 0.0998.

I'll try everything from the start in a bit and will let you know if the result is somehow different.

Everything is failing just the same, I'm afraid.

So the workflow that is failing is, in a nutshell:

walletA trusts bitstamp for 1 BTC
walletB trusts bitstamp for 1 BTC
wallet A gets a 0.1 BTC transfer from bitstamp
wallet A cannot send any BTC to wallet B - Paths are calculated but when sending one of partial path or fee insufficient will be thrown.

Are you able to run the workflow described yourself?

[edit] - above is the simplified workflow that is failing now, the original issue was slightly more complicated:

walletA trusts bitstamp for 1 BTC
walletB trusts walletA for 1 BTC
walletB trusts bitstamp for 1 BTC
walletA gets a 0.1 BTC transfer from bitstamp
walletA sends 0.05 BTC to walletB - it appears as walletA BTC IOU
walletB cannot send any BTC to bitstamp - Paths are calculated but when sending one of partial path or fee insufficient will be thrown.

Hmm, I think this confused me more to be quite honest ;) Although I do actually understand now :)

Liam

Okay, not sure if you solved this yet, but destination codes might be mandatory for sending to bitstamp.

I can't seem to get a donation and I'm trying to write up a blog post about XRP

Destination tags are mandatory when sending to Bitstamp. Without a destination tag, Bitstamp would not know which account to credit.