New trust lines should have the quality in/out set to zero #748

vinniefalco opened this Issue May 21, 2013 · 53 comments


None yet
8 participants

Currently when someone extends trust to two or more issuers for the same currency, the quality setting defaults to 1. This means that the user's balances can change when payments ripple through.

Instead, new trust lines should have quality in/out set to zero, to prevent this counterintuitive behavior. In the future, an interface can be added to some Advanced panel that allows the quality to be changed. But for now, no good can come from balances which fluctuate without user action. It only makes Ripple look bad.

kaetemi commented May 21, 2013

Your point of view only makes sense when you're trusting gateways for physical currencies which you don't really trust, but undermines the entire reasoning and functionality of ripple as a trading platform for virtual currencies. You should ONLY trust anyone who accepts your currency through ripple for equivalent value, NEVER ever trust anyone who just gives you money if you can not spend it with them, that's not value. "Issuers" of phony currency DON'T and SHOULD NOT exist. Examples of proper trustable parties are stores and businesses which accept the currency through ripple, for whatever amount you plan to spend there within a reasonable time frame.

I disagree. My point of view makes sense from the perspective of any new user. Fact: extending trust to more than one issuer for the same currency can cause account balances to fluctuate without user input. Fact: account balances that fluctuate without user input are confusing. Fact: setting the default quality for new trust lines created in the client to zero prevents account balances from fluctuating without user input. This might ruffle the feathers of the "community credit fetishists" but it's just a default and a future version can provide an Advanced panel where the quality can be changed. Another option is to add a checkbox to the Create Trust panel, "Allow payments to ripple through me (warning: this can cause balances to change at unexpected times)", default to unchecked.

kaetemi commented May 21, 2013

Why does it matter to you that trust balances move from one trust to another? You both trust them and it's the same currency, so it should not matter.

Of course it matters. Lets say that I have a Bitstamp account and a $1000 Bitstamp USD balance. Then I extend USD trust to Kraken, but I don't have an account there or perhaps I am waiting for verification. Now I go to bed. When I wake up in the morning, someone rippled through me and now I have a $1000 Kraken USD balance. I need the money but I can't get it because I either don't have a settlement agreement with Kraken or I am waiting for my documentation. And during this time the market moved against Bitstamp, now its too expensive to convert my Kraken balance to Bitstamp.

New user must not have account balances change unexpectedly!

kaetemi commented May 21, 2013

That's a clear case of trusting someone who's services you cannot use. That's simply a risky trust, and a risk you took. Trusting someone who's services you cannot use or who can only deliver the services in the future, is pure speculation, and only wise in so far other people you need to trade with trust them.

no, No, NO! It's one thing to say that you trust a gateway to hold some of its IOUs. Its another thing to say "...and additionally, I am okay with having one issuers IOUs swapped with the other." The default setting for new users should be not to allow account balances to change without their input. How can I possibly make this more clear? There's a reason that quality is a configurable parameter of the trust line. The client's default setting for new users should be to make the quality zero, meaning that even when a second trust line is created for the same currency and a different issuer that payments will not ripple through, causing the users account balance to change unexpectedly.

Ripple is already difficult enough, we don't need to further alienate new people by exposing them to counter-intuitive behavior.

I refuse to play automatic 1:1 currency converter just because I trust 2 independent gateways. Just imagine me being the only connection between 2 very high frequented gateways. As soon as I enter one balance for withdrawal on one side, I don't even have it any more as it already rippled to the other one and vice versa. I want my balances with gateways only to change if I send money or I am being sent money or I am explicitly trading IOUs.

Right on Markus. Ideally, the quality will be configurable through the interface if the user exposes some Advanced panel. But since there is currently no way to manually set the quality, it should default to zero.

It could even be 1:1 by default but confirmed upon adding a second trust line in the same(?) currency. The question mark is because for example "BTC" is not a ISO code for any currency and is rather likely the abbreviation for Bhutan chetrums (the "cent" of the BTN) instead of Bitcoin. If I now offer 1/100th BTN IOUs and call them "BTC" and I have a trust line with someone who also trusts Bitstamp for BTC (in the sense of Bitcoin) there will be problems.

It is reasonable to assume that same code means same currency, but unless there is a very explicit way to guarantee that 2 issuers actually mean the same currency I would also like to see the "rippling" to work explicitly.

kaetemi commented May 21, 2013

I still don't see the issue, as both gateways you trust would provide you equivalent value in exchange for your ripple currency. And you can use both gateways from any of both trusts, provided that everyone in the network trusts both and there is a sufficient buffer of value, which is why it should stay at the current default, otherwise you undermine the entire functioning and purpose of the network entirely, and your currency issuer speculation use case should be an advanced option.

Markus: Overlapping currency codes is another issue, that does need a proper solution, but this is not the optimal solution for that problem at all.

Re-read Markus' first post.

kaetemi commented May 21, 2013

Established gateways should trust each other for a fair amount, so that's a non-issue.
Also, name-calling is not an argument. You're using ripple, not a bank. It's not counter-intuitive, it simply works different from the bureaucratic banking conventions.

No, gateways should NOT trust each other, because that exposes them to counter-party risk. I don't think I would trust a gateway that freely exchanges its own IOUs for the IOUs of another gateway just to create liquidity, unless I could confirm some publicly auditable escrow of cross gateway balances.

You might be attached to the old Ripple concept, but new users should not be forced to "play 1:1 automatic currency converter." Your motives are to encourage the "community credit" concept but this is detrimental to Ripple adoption.

kaetemi commented May 21, 2013

Banks trust each other as well for a certain buffer amount, you know.

Your motives are to encourage turning this into yet another generic payment system, of which we already have a thousand, which is detrimental to Ripple adoption.

So your answer to users account balances changing unexpectedly is to expect that gateways will issue each other credit "like banks?" Alright I think you've made it clear that you do not intend to add any signal to the conversation. Perhaps we can just default the quality to ZERO (meaning "don't ripple through me") instead of expecting gateways to expose themselves to other gateway's credit rating. Which one seems easier to you - don't answer that, I already know that you're a community credit fetishist.

kaetemi commented May 21, 2013
I'm being nice right now, you now.

I meant:
Gateway1 <-- me --> Gateway2 (<-- indicating "trusts") not Gateway1 <--> Gateway2.

I have no problem playing liquidity provider if I'm asked. I don't like to give implicit consent though. I can understand the benefits for Ripple itself but doing this implicitly creates huge scam potential, is not really intuitive and can lead to bad user experience (balances shifting while trying to redeem IOUs).

Markus: "balances shifting while trying to redeem IOUs." Exactly. kaetimi up there seems to think it's okay.

Regarding Ad Hominem, yeah you're right it was, no denying that. But we need to kill the community credit meme in its crib because the counter-intuitive behaviors only alienates users. If you are so enthusiastic then submit a pull request with an Advanced interface panel that lets you change the quality on a trust line.

kaetemi commented May 21, 2013

Or, you could do that, and leave the default to what ripple means. This has the potential of becoming a hybrid of trust-based value with physical money, which in my opinion is the most sensible way to adopt the system. Turning this into a bank transfer system is kind of pointless.

^^ Exactly the definition of "community credit fetishist."

kaetemi commented May 21, 2013

Or that and set the default value to the average of everyone else's.

Just because you have a fetish for community credit doesn't mean that normal people should have to endure their account balances changing unexpectedly because they are new to Ripple.

kaetemi commented May 21, 2013

Join the dark side.

By defaulting to averages for implicit conversion rates you just open the door to people creating fake accounts to inflate/decrease the standard conversion rates to scam even more (e.g. I issue BTC IOUs and create a second account offering 1 million Bitstamp BTC for 1 of mine - pushing up the average really high and making it able for me to leech out any amount of BitstampBTC even if someone just trusts me for just 0.01 BTC "for fun"). Medians might be possible (as they filter out these extreme cases) but that also just means that I have to create and fund a couple dozen/hundred/thousand fake accounts and pull off the same stunt.

I'd really prefer either 1:1 (or something close to it, like 1:0.999 both ways) and the client explicitly asking for my consent (and being able to change this later) when setting up trust lines or no rippling at all and explicitly turning it on. Implying 1:1 exchange of up to my whole trusted balance just because the currency code is the same or because I typed in a number and address in the "trust" UI is not something I personally like to happen and which is why I commented here.

kaetemi commented May 21, 2013

Yes, that average was just a joke. (You spotting the implications of that means I can trust your opinion.)

You are correct that the client should clearly state the implications of the 1:1 and ask for consent, and suggest alternatives and state their implications. It should not silently default to 0 as the OP suggested. It should not silently default to anything.


JoelKatz commented May 22, 2013

Setting the quality in to zero would defeat the point of having the pathway in the first place. Nobody could use the pathway to pay you (no balance received on that pathway would be considered to have any value). Setting the quality out to zero would mean that you are willing to give the balance away for free because you think it has no value. What you actually want to do is set the quality in and out rationally based on how you actually value the pathway.

kaetemi commented May 22, 2013

MarkusTeufelberger: On the point of the overlapping currency names for entirely different currencies, I believe that the most logical solution for that would be to introduce a renaming scheme into trust lines, that allows the user to add a namespace prefix to the currency on his account. In that situation, if both Jeff and Tim have a currency called LOL, but they're really different currencies, I could have the trust line trust Jeff for LOL and let the trust line be prefixed to become JEFF:LOL, and similarly for Tim. In which case anyone who'd trust me for Jeff or Tim's LOL would need to know the prefix I use for their currencies though, but they'll be able to use it in their account without prefix or with their own prefix, whatever works for them. Does that sound like a sane solution?


JoelKatz commented May 22, 2013

@kaetemi It doesn't seem like a good idea to work on making money less fungible. In your scheme, what would happen if someone wanted to pay you 10 LOL? What would happen if you had to pay out 10 LOL?

Basically, if people are using the same currency code in incompatible ways such that the exchange rate will fluctuate, you can't use both such currencies with the same account.

kaetemi commented May 22, 2013

In that scheme, if someone paid me 10 LOL, it would be whichever one he sees as LOL without namespace on his account, and the trust lines would rename it to whatever namespace I use on my account. If I paid someone LOL, it would be, similarly, what he sees as LOL without the namespace, and basically whatever trust path works. The only thing that the namespaces would really do is avoid transfer between the namespace within one user's account, from a technical point of view. There will be overlapping currency codes, it will just happen.


JoelKatz commented May 22, 2013

So if you named in the same namespace, then transfers would be permitted? This seems like an incredibly cumbersome solution if all you really want is a flag on a trust line that prevents it from being in the middle of a path.

kaetemi commented May 22, 2013

Yes, it may be a complicated solution. Although it makes sense to me that some trust lines for the same currency code could be grouped together (especially in the case where they're really different currencies). Technically the namespace would be local to the account. Either in such way that if I'd then send LOL to someone, it would just pick whichever LOL works. Or, if 'd send LOL to someone, I would need to explicitly specify my local namespace with the currency name.

But indeed it's probably wiser to just use separate accounts, that may make more sense and doesn't need any additional work on the system. Maybe a client that allows to use different wallets simultaneously, in the future.

Could we move the namespace issue somewhere else? It was just an example that there is exploit potential by allowing 1:1 trades by default. There might be better solutions than local tags or a centralized (currently it seems to be hardcoded into the client) currency/IOU list...

Back to the in/out quality:
Maybe this is the wrong functionality in Ripple to address this issue? I would agree that 1 BTC from Bitstamp I receive is worth 1 BTC to me and also that if I send a BTC from them I want to send max. 1 BTC per BTC. I wouldn't agree however that it is fine to exchange them automatically for 1 BTC from WeExchange for example, even if I trust them as well. Maybe one of the 2 has a better interface that I like more, better customer support (I'm looking at you, WeExchange! 👎 ) or I just happen to browse there more often.

I also use PayPal for example sometimes, but I wouldn't feel too comfortable if I automatically for some reason (preferences of other people in the network that I don't have any influence over) have to withdraw money from there suddenly all the time compared to every few months/years if I sell something on eBay. Still in my mind I keep a certain "trust line" towards PayPal - but if I would be forced by third parties to rely on this more than I plan to would make me feel uncomfortable with this system. I'm happy to use them every once in a while to receive a payment and then forward it to my bank account, but I certainly don't want to have my bank balance suddenly shifted to PayPal, even though both are denominated in EUR and I trust both somehow.

One issue might be that I would trust PayPal for holding my money maybe one day or so while I trust my bank to hold it for much longer - a quality that is to my knowledge not mirrored in Ripple (and it seems also difficult to create).


JoelKatz commented May 22, 2013

I think your question is "What if I want to value them equally, but I don't actually value them equally?"

Maybe "What if I see equal value in the IOUs themselves, but different value in the way to redeem them?" would be more precise. This can not be automatically determined by the system by the way (well, there can be statistical analysis...) as I might prefer a gateway simply because it displays cute kitten pictures when withdrawing.

Hey listen up let's not get sidetracked here. I don't know all the nitty gritty of the implementation details but the client behavior when extending trust lines to multiple gateways for the same currency should be to not allow Rippling through without explicit user action. As I stated already, account balances which fluctuate without direct user actions are counterintuitive.

Ripple could be the best system in the world, be mathematically awesome, and have theoretical perfection but joe blow Bitcoin idiot user will never understand why their balances change and neither will my grandmother. So unless you want to sit down and try to convvince every grandmother in the world of all the wonderful technical, financial, and cryptographic reasons why a universe where account balances change without user action is the "correct" one - fix it!

Markus: Right on brother. "I don't mind holding IOUs from either of these gateways as long as it is the result of a payment either directly to me or directly from me."


JoelKatz commented May 22, 2013

@vinniefalco It's worth teaching people that this happens and why because the alternative is to make your IOUs worth less, which hurts you. If you set this flag on a gateway path, that means I can't exchange your IOUs for that gateway's IOUs, which makes your IOUs worth less. The less your IOUs are worth, the less people will pay for them. That hurts you directly. The issues described above seem so minor, and the reduction in value so great. If we make this option, we have to explain to every grandmother how it hurts them, and that's even harder.

@JoelKatz When I count the number of scenarios where grandmothers are issuing their own IOUs I come up with zero. I'm talking about a very specific scenario, which is where someone has extended trust to two different issuers for the same currency. The default behavior should be to NOT allow "rippling through." If you want to present it as a checkbox (default to unchecked) so that advanced users can enable Rippling through when creating the trust line, then that is fine.

You say that "the issues described above seem so minor." In my opinion this is incorrect. The issues are minor only from the point of view of someone who perfectly understands Ripple which unfortunately consists of exactly two people of which you are one. For the other approximately 7 billion people on the planet, account balances which change without user input are counterintuitive.

There is no way that you're going to be able to paper over this problem with logic or reason. Money is one of the most intimate and deeply personal subjects on the planet. No amount of explanation regarding how IOUs are valued depending on "ripple through" settings is going to make the pill any less bitter when someone's account balance changes.

To make things even worse, the Ripple client pretends that all IOUs for the same currency are equivalent. You have to dig deep to realize that your Bitstamp BTC was traded for WeExchange BTC. The scenario that Markus describes is the perfect example. Someone extends trust to both gateways and within seconds their BTCs are swapped out, but the client offers no visual indication. You see the same BTC balance buy you're holding Weex instead of Bitstamp.

Now the user gets cold feet and they decide to send the BTC back to their Bitstamp account and wondering why the hell they can't recover exactly the original amount? You think you are going to win over their heart by explaining that an invisible change in account balance took place because they extended trust, and now due to the reduced liquidity of the path in the opposite direction (plus gateway transfer fees) they have to take a haircut when redeeming back to Bitstamp?


JoelKatz commented May 22, 2013

The same thing can happen if people pay them through WeExchange and they try to redeem through BitStamp. So we still have to explain it to people.

It seems all these explanations are needed when the second and subsequent trust line is created for the same currency. The client should detect these additional trust lines and present a special interface to educate the user.

Explain it by doing so in the confirmation panel that appears in the client when you create the second trust line. Provide a checkbox for setting the quality to 1 ("rippling through"), default to unchecked, along with an explanation of the benefits and consequences of allowing the balances to change.

kaetemi commented May 22, 2013

Both gateways provide the same service. It does not matter which trust holds the balance. Preferably gateways should trust each other (not only by pressing some buttons, but they should actually trust each other and have the necessary agreements contractually set up) and transfer physical currency between each other to keep the balance between them neutral. That would make everything work smoothly, and make your entire point a non-issue.

A short explanation when adding trusts would be enough. Those who don't read, learn the hard way.

Actually I tried to use both Bitstamp and WeExchange with BTC: Bitstamp - no issues so far at all. WeExchange: Sent BTC to their address (including the account number added in the end) - no credit for now nearly a week, no reaction to the ticket opened in the past few days, no nothing. When I tried to enter my transaction hash in their form, that killed their web server and their whole page was down for half a minute or so. This still works after a few days, it is probably possible to DoS their page with this.

Yes, it is probably possible to redeem 1 BTC at either service when holding 1 BTC IOU in either denomination in Ripple. I do NOT see them provide the same level of service or usability by far however and given the choice I'd rather have someone else ripple over some Bitstamp IOUs for any WeExchange balance I hold.

No matter how hard you try to convince yourselves that this behavior is okay, it is not. Weex charges 0.5% to send IOUs while Bitstamp charges 0.2%. I would much rather hold Bitstamp IOUs if I want to buy something in an order book than Weex.

It should not be necessary to trick new users into having defaults that allow rippling through when there is more than one trust line in order for payments to work. Isn't that what the order books are for? If there is insufficient liquidity in the order books it seems dishonest to force unsuspecting users to act as market makers.

Additionally I find it a bit strange that these implicit orders/offers are not showing up in the order book. After all there might be quite a bit of liquidity hidden by this approach - or very little. I guess it can be exposed with some alternate clients, but a "1:1 rippling liquidity" line in bids and asks might be useful.

I think that the trust lines are only considered during pathfinding and not stored in the order book. It would be resource intensive if the Ripple protocol continuously updated order book entries corresponding to trust line balances for visual purpose.


JoelKatz commented May 22, 2013

The order book display is really only marginally useful. What you really want is a "synthetic" order book that reflects all the liquidity in the system. If you want to convert, you shouldn't do it from the trade page but do it by making a payment to yourself. You should use the trade page if you have an asset and want to trade it for an asset and you know all the specifics. Then the person taking it can use all the liquidity in the system to get to and from the trade. Taking of crossing offers is really just to keep the system sane, it's not meant as an optimum conversion mechanism.

arvicco commented May 24, 2013

You are welcome to read discussion in this thread: Unless the defaults are changed to 'no ripple-through for new trust lines', scams similar to this WILL happen all over the place and leave thousands of new users without their money and angry at Ripple. This will create huge hurdles to further adoption, and potential backlash against the whole system, rather than a "community credit" aspect of it which is still very much proof-of-concept anyways.

I know I will not use Ripple for anything serious (rather than playing with a small change in it) unless this is fixed. So, you will have essentially two types of users: ones that do not trust the system to do any serious business, and ones who do not understand what they are doing and become utterly confused by their changing balances and mounting losses due to scams. Oh yes, and also scammers who will be the happiest of all (at the expense of all others, of course). Is this the kind of Ripple system you are trying to build?


JoelKatz commented May 25, 2013

  • Document flag in ripple state node - pathway may only be used as end or to redeem own IOUs.
  • Modify server to honor this flag
  • Add transaction to set/clear this flag
  • Client sets flag by default when pathway is created
  • Client shows this flag and permits you to modify it.

This all sounds very sensible David.

@ghost ghost assigned ahbritto May 25, 2013

Instead of On/Off or additionally to it, I'd like to have a "conversion rate/fee", similar to the fee that some (currently: most) issuers charge for moving their IOUs between accounts. If I provide liquidity, I don't necessarily want to do it for free. With the amounts I hold on Ripple there won't be huge things coming out of this, but maybe I can afford an ice cream sponsored by the network every once in a while.


JoelKatz commented May 27, 2013

@MarkusTeufelberger That's already there. (Look for "downgrade".)

brianddk commented Aug 7, 2013

All, I wrote a brain dump on how to run rsign.js from a Windoze box. Anyway, while the decision of where or when to put this in client is hashed out, you can play with this stuff through the ripple-lib module. With a bit of work you can make your trust lines with the quality defines you want. My day job keeps me busy, but I might be able to write a quickie localhost page to set trust quality, but since this requires your secret, I doubt anyone would trust it enough to use it ;-).

Brain dump:

PS: Sorry for reviving such a thoroughly old thread.

Thank you! It should be very helpful if I can figure out how to set these "quality" values and play with them.
By the way, we now all have seen that IOUs issued by different trustworthy gateways can have significantly different current market values so kaetemi was wrong and vinniefalco's point is valid.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment