Ripple and Trust

[Zedster]

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:

Hi,

Bitstamp does not accept XRP`s at the moment. Transfer was rejected and XRP`s were probably added back to your account.

Best regards
Nejc
---

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

[commonancestor]

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?

[JoelKatz]

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

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.

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?

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.

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.

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.

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?

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.

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?

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.

[SRG]

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.

[ribuck]

I've started to replace "trust" with "deposit"

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

[commonancestor]

Hi, thank you for the answers.

But you can do most of what a gateway does without being a gateway.

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

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.

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.

I think the scenario you're envisioning is this: ...

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.

... this is *not* a good idea.

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.

[JoelKatz]

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.

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.

[TTBit]

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?

[molecular]

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.

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.

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

[moocowpong1]

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?

This might be helpful: 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.

[becoin]

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.

[becoin]

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

Anyone from Ripple developers willing to comment my suggestions above?

[Arvicco]

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

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.

[misterbigg]

...some sort of "pre-mining" is the only viable monetization strategy for distributed platform such as...Ripple.

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.

[gweedo]

...some sort of "pre-mining" is the only viable monetization strategy for distributed platform such as...Ripple.

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.

[becoin]

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.

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!

[nelisky]

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?

[JoelKatz]

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.

[nelisky]

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.

[JoelKatz]

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

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.