So let's say I choose to not trust any gateway and their currencies, and instead decide to transact in the native stellar currency directly. This is a strange choice: why have support for alternate currencies if the Stellar protocol in itself can do nothing to help gateways gain trust? You might as well have, say, Amazon not even bother becoming a gateway issuing their own USD_Amazon, but instead Amazon would just accept the stellar currency directly. In this case I am still required to trust the native stellar currency. I am required to trust that Stellar --the nonprofit organization-- will correctly follow their mandate (https://www.stellar.org/about/mandate/): distributing x% to X, y% to Y, etc, properly thwarting fraud attempts from people with many fake Facebook accounts, properly thwarting fraud attempts during voting (https://www.stellar.org/about/mandate/#Stellar_creation), properly thwarting fraud attempts from people building fake nonprofits to attempts to gain a share of the 25% of stellars reserved for nonprofits, etc. And Stellar trusts Facebook, so I am even required to trust that there is no malicious employee at Facebook that will exploit APIs to attempt to gain stellars. You plan to distribute stellars through SMS? Heck I now need to trust telecom carrier employees, etc. Even if you are honest and make no operational mistake, fighting all these fraud attempts will be a large uphill battle, and there is way too much trust required, way too many possibilities for mistakes to happen.
Contrast this with Bitcoin: all Bitcoin requires is trust in three cryptographic algorithms which fit in a few thousand lines of code (ECDSA w/secp256k1, SHA-256, and RIPEMD-160).
I appreciate the attempt of building a different payment technology, but Stellar should not mislead people into believing they are similar to Bitcoin ("Stellar is decentralized [...] owes a lot to Bitcoin"). Stellar threw away the most fundamental element of Bitcoin: complete decentralization (including decentralization of the issuance of units of currency.)
So I'm with you — there are real tradeoffs here, and I'd encourage everyone interested in this stuff to mull them over (and I'm also happy to discuss: [email protected]). But one thing I really respect about the Stellar organization is the very deliberate approach they've taken to these choices, and how they've found a happy middle that feels like a translation of the existing physical world into the new digital one. If it works, I think it'll make Bitcoin and other digital currencies even more successful.
The fact that this weakness does not appear in the BitCoin protocol, but is rather implied by the human desire for convenience and marketplaces, doesn't make it less of a flaw. One can sneer at everyone who lost money with MtGox for "choosing poorly", so to speak, but on the other hand exchanges are the driving force behind BitCoin's success.
If this takes off, then you could use this to build the killer "spot me $5" app. A few weeks ago when some friends were describing the spreadsheet they used to track who owes what to who, I proposed a micro-virtual currency limited to just the circle of friends that all trust each other, whereby exchanging the virtual currency you can transfer debts, and trivially find out who owes money and who is owed just by looking at the current account ledger. Seems like Stellar enables that on a massive scale, without everyone needing to trust each other, because the coins are all tagged with the issuer.
Stellar uses real-world currencies to denote the held values. Does it limit these currencies to actual known entities, or could I become an issuer and start issuing credits in a fake currency? If I can do that, then it seems like there's an opportunity here to use Stellar to track things other than monetary exchanges. As a hypothetical example, if I had several kids, they could all trust each other to issue units of a fake currency called "Chore". If I ask one of them to do something, they could instead pay 1 Chore to their sibling to have them do it instead. This can of course be redeemed later if I ask the sibling to do something. Since it's a fake currency, it has no real value and can't be traded outside of the small group of kids (as nobody would accept it). This sort of thing can't be done with e.g. USD because the proxy money could be traded to someone else who doesn't realize that I won't actually accept it back for money.
Another solution would be to allow gateways to declare that their coins are only redeemable by a limited set of accounts. That way I can be a gateway and issue USD-stellar that everyone knows is worthless if it leaves the circle of friends. I could do this ad-hoc just by refusing to redeem any issued coins by someone outside the group, but as mentioned above that leaves open the possibility of people not realizing that these particular coins are worthless (outside the group). Of course, this also has the problem where someone may now look at their balance and see that they have $500 USD, but not realize that $50 of it is actually debt issued by me, because the software they're using doesn't distinguish restricted coins from others.
Perhaps the fake currency approach really is the best. This has the benefit of letting an extended group of friends trade around debt issued by people they're not actually direct friends with, but they trust transitively through a shared friend. If I decide to accept debt issued by Alice, and Alice refuses to pay up when I go to her, I can then talk to our shared friend (but hopefully Alice would agree that the debt I bought from Joan is still valid and pay up). The downside is, of course, that everyone has to be using the same centralized shared currency. And that won't scale past a small group of friends (if it did, it wouldn't be a fake currency anymore). Although if you have several smaller circles of friends each with their own currency, and there's overlap, they could decide to trust the other currency and treat it as equivalent to theirs. I guess this is a continuation of Stellar's philosophy that the trust is granted by the person accepting the coin, rather than being dictated in any fashion by the issuer.
Of course, all this is predicated on the fake debt-currency not spreading far. As you try to scale to larger groups of friends, it ultimately ends up being simpler just to switch to USD.
I guess the real challenge here is figuring out how to let Stellar wallet clients display contained balances in a way that doesn't confuse coins issued by generally-trusted gateways vs coins issued by small gateways that most users probably won't trust. If I can somehow either categorize myself as a gateway, or each gateway I trust, those categories could be used to display balances appropriately. This way I can categorize Alice, Joan, Bob, Fred, and Jane as debt-issuing friends, and they can issue USD, and I won't accidentally think I have $500 USD when I really have $450 USD and $50 friend-debt. This doesn't really solve the problem of trading debt to people who don't realize it's worthless, but I don't know if that's a legitimate worry.
Check out https://www.stellar.org/api/#api-payment. By setting Amount.issuer to be the recipient's address, the protocol will find a path from the sender's gateway to the recipient's gateway.
Speaking more broadly, I anticipate many gateways will also become exchanges, to make their credits more valuable, aka more "liquid". For instance, in the last example, what was required to make this work was a "market maker", someone in the middle buying London EUR and selling San Francisco USD. If no direct exchange existed (highly unlikely in this example), there may be a EUR -> XYZ Currency -> USD. To avoid this external dependency (and also offer a cheaper exchange rate), it would be in the London and SF gateway's best interest to trust (https://www.stellar.org/api/#api-trustset) each other. Then, the exchange from her EUR credits to your USD credits would happen directly.
Yep, that's baked into the protocol :) https://www.stellar.org/api/#api-accountset - require Auth flag
Note that your friend would only be able to trade your fake currency to someone who is willing to trust you, so there's no obvious need to have more technical enforcement preventing trades.
Unless this is totally different than Ripple, this can't happen unless there's a trust pathway between the recipient and you.
"Hey, take my credit from X gateway" "Sorry, I don't trust X"
I'm also wondering, since the amount of Stellar is capped (100 billion, right? Can this ever change?), and since 50% of Stellar is being distributed to people who sign up, it seems like a sizable portion of this Stellar will almost certainly immediately become unusable as people sign up, get their Stellar, and never come back.
Edit: Just found the bit where it says Stellar will be created at a rate of 1% annually. The fixed 100 billion cap I cited was based on earlier comments about Ripple's cap.
That's not the only way that gateways can talk to eachother. Given this is ripple we're talking about, anyone who has a mutual trust connection between gateways can facilitate a transaction, as can any market-making trader.
Looking at MIRI's gateway and my own showed dozens of such connections. Ripple has 100,000 users, any of which can be part of the connection between any two given gateways. Stellar is planning on growing that large and larger, so it should be expected that this will happen there, too.
Isn't the worst case that the gateway goes belly up?
But more seriously, a gateway you trust going under is indeed a risk. That's part of why you can specify not just "I trust this gateway" but also "I trust this gateway for up to 100 CAD" — you can explicitly specify your exposure.
This means there needs to emerge a good system for users to decide which gateways to trust, but a malicious gateway can only directly harm the users who have decided to trust it.
The beauty of this model is anyone can become a gateway at any time. See for example the gist linked at the end of the Stellar blog post: https://gist.github.com/thejollyrogers/b114b5a98fa11a5a4ad0 — becoming a gateway is just two API calls.