Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JoelKatz

  1. Gatehub doesn't have an exchange. Their wallet uses the XRP ledger's built in distributed exchange. It's difficult to support that for hosted wallets, so I suspect they only support it for native wallets. If Bithomp shows your wallet activated, then you should be able to use the exchange. Is that wallet the account holding the BTC?
  2. This was kind of how the original Ripple Pay system worked. There are a few problems with this approach. IMO, the two biggest are: 1) Each issuer's IOUs are only as reliable as that issuer's transaction processing equipment is. 2) Cross-issues atomic payments weren't possible. (Though now you could do this with ILP.)
  3. Mostly because Bitstamp is an exchange and Gatehub isn't. The rates you're seeing for Gatehub are coming from the XRP ledger's built in distributed exchange which usually doesn't have as much liquidity as most exchanges.
  4. The same way people who run bitcoin full nodes are compensated, by having a server they can use for their transactions or to which they can sell access. As an extra bonus, they get a say in the evolution of the XRP ledger.
  5. I guess Poloniex is just taking their time.
  6. I am not 100% certain, but this is my understanding: There are three keys. Two signatures are needed. 1) The BitGo key. Only BitGo holds the corresponding private key. BitGo signs transactions with this key when they meet your security settings, are signed by the user key already, and profer 2FA is completed. 2) The user key. This is the key that BitGo stores encrypted with your password, which BitGo does not store. Normally, the client signs transactions with this key before submitting them to BitGo. 3) The recovery key. This key is known only to the user and keyternal. The page you printed out when you created the wallet contains both keys 2 and 3, encrypted with your password. Keyternal stores both keys 2 and 3. I hope someone will correct me if this is incorrect. I too was surprised by the keyternal email. The setup flow should have at least told you about that and, ideally, offered you to opt out (but then warning you that you could lose access to your funds if you lost your recovery key).
  7. The shortest possible answer is probably this: They're already using something now, probably dollars. And if we're talking about inefficient corridors, it's not working all that well. Ripple is willing to pay its own money to make XRP work better for that corridor than whatever they're using now. Ripple just has to expend enough to make XRP work just a little bit better and remember, XRP can already be moved more easily (with certainty in just a few seconds) than things like USD can. Ripple has their choice of corridors to work on. So we just have to find a few choice corridors where payments are flowing over a modern payment system but settlement is slow and/or expensive. Then we just have to make XRP work slightly better than whatever they're using now, which might not be all that difficult given XRP's inherent efficient transfer properties. If you can find a pile of gunpowder, you only have to light the fuse.
  8. I think most likely there will be convergence on one protocol as there was for IP and HTTP. But it shouldn't be terribly difficulty for the protocols to interoperate if they only handle the escrow/transfer portion and don't intrude too much into transaction setup.
  9. Let me say a few things: I had a great experience creating an XRP wallet from a Chrome browser on my laptop. The only problem I had was that so many people at Ripple were creating wallets at the same time that we triggered BitGo's rate limiting. It's always sad when someone has a bad experience. But I can think of a few things that could have caused your bad experience that don't reflect any kind of massive design problem or anything like that. For example, your account may have gotten stuck in their database in an in-between state due to something like a server-side crash or fault. I've gotten locked out of Facebook and Twitter accounts, often for ten or fifteen minutes, several times due to similar issues. The BitGo team is top notch technically. They know this business very well and they take security very seriously. Their primary product involves enterprise storage and movement of digital assets. Many exchanges use them. Yes, Bitfinex used BitGo and Bitfinex had a massive hack. You can believe whatever you want about BitGo's responsibility for that hack and I don't want to rehash that here. That could have easily been a business-ending experience for BitGo. But instead, BitGo learned from it and emerged strong. One thing I do know is that the Bitfinex theft, at a minimum, involved the compromise of Bitfinex's keys. BitGo has made it structurally not possible for them to produce the two needed signatures. Their core architecture is 2-of-3 multisign. The customer can hold two keys, so they can perform transactions even if BitGo cannot or will not sign them. The design takes security very seriously and gives the user/customer control over what transactions BitGo will sign. Their account recovery process seems quite sound to me, requiring involvement of a third party to recover one of the customer's keys for BitGo. Of course I can't promise you'll have a perfect experience. This whole key management thing is new and everyone's learning by doing. But I have very high confidence that BitGo will keep producing a high quality product. I am also hopeful that BitGo's enterprise support for XRP will lead to more of BitGo's enterprise customers deciding to support XRP. And that sounds like a really good thing too.
  10. One of the things we hoped to get from our BitGo integration is XRP support from companies that use BitGo's enterprise product. Looks like it's working!
  11. The validators you are using has no effect on whether your transactions succeed or fail. With a good validator set, you are guaranteed a correct view of the network that agrees with everyone else. With a bad validator set, you are not guaranteed to agree with everyone else on the state of the network. But what validators you choose to use isn't going to have any significant effect under any reasonable circumstances over what transactions succeed or fail on the whole network. With a bad enough validator set, you might be unable to determine that your transaction succeeded. But if it's valid, unless the system as a whole is broken or your server isn't connected, it will actually succeed on the ledger everyone else agrees on. If not, the network is broken. BitGo could, of course, refuse to submit your transactions to the network if they had some reason they thought that was not a good idea. But that's their business model -- they exercise business judgment over which transactions to submit to protect their customers with there customers holding sufficient keys to bypass them should their be a disagreement. They don't have to monkey with validators to not submit a transaction that they don't want to happen.
  12. I'm not working on any wallet provider part time yet. I expect that I will begin working part time on a set of projects that might include an open source wallet "kit" that would permit others to easily provide full-featured Ripple wallets. The project in this set that I'm most interested in and excited about isn't a wallet.
  13. I think they're roughly two months out from general deployment.
  14. Clients can support demurrage by decreasing the presented value based on the ledger date. The gateway can support demurrage by adjusting the ratio of amounts on the ledger to amounts off the ledger at issue/redeem time based on the date. Supporting such a thing on the ledger is extremely complicated. We considered it and couldn't find a scheme that was reasonable to implement.
  15. I hope it's not a secret, but today, I setup my Bitgo multisign XRP wallet, sent XRP to it, send XRP from it, all worked smoothly, no issues. I'm very impressed with the product.
  16. That can happen if the price changes due to an XRP order being placed. The ledger only looks at perfect crosses when XRP offers are placed and can't search for every autobridged order book that might be affected.
  17. Yes, that's correct. Then people who didn't resubmit their own transactions might see a lower quality of service. It's hard to sustain such an attack because of rippled's internal rate limiting and it's unlikely someone would bother because the consequences are so small. If you submit to only one rippled server, you're protected. If you pay the open ledger fee and don't send lots of transactions close in time, you're protected. If you resubmit your own transactions, you're protected. If you use your own rippled server, you're protected.
  18. You can click on the price at coinmarketcap and drill into the individual markets. Markets with less volume are less meaningful and for some reason the prices on Korean markets seem unusually high. It often makes sense to look at the prices at the markets you are most likely to actually trade on.
  19. The issuer of the low limit and the issuer of the high limit indicate the two accounts the trust line is between. Any non-zero limit indicates a side is extending trust. It is possible, though not common, for each side to extend trust to the other. The balance is relative and can exceed the trust limit (either because the limit was lowered or because the asset was acquired with an offer).
  20. The issuer should set "default ripple" on their account before any trust lines are created. If you set it later, the issuing account needs to turn off "no ripple" on all trust lines created to it. See: https://ripple.com/files/GB-2015-04.pdf
  21. Yeah, you would need a tool that lets you use any private key to sign a transaction. I think rippled will do it if you set the index field.
  22. That means that your seed will never be able to generate your private key using standard tools. Fortunately, you can generate the private key using non-standard tools and you can sign the transaction with the private key even if there is no corresponding seed. You'll have to do a lot of this manually though -- I don't think there are any convenient tools for doing this. Fortunately, to get XRP out of the account, you only need to assemble one payment transaction.
  23. I think you could do it by the seller extending a trust line for USD to the buyer and offering to sell XRP for his own USD. The seller would have to hold USD issued by a gateway the seller trusts. The buyer would then create a payment path like this: 1) Buyer sends XRP 2) XRP goes to order book to USD/seller (consuming the seller's offer) 3) Seller receives USD from himself which ripples through 4) Seller returns USD to gateway 5) Gateway issuer USD to buyer Circular paths are allowed so long as the same account is not visited twice in the same currency. So this *should* be legal. The payment is atomic, so there's no risk to the buyer.
  24. As the term is being used here, "rippling" is when a transaction causes an intermediary's asset or obligation to switch to another counterparty. The simplest way to understand it is to think about a gateway, since gateways (as far as the ledger is concerned) are basically rippling hubs. Suppose Alice has one bitcoin, issued by Gatehub, on the Ripple ledger. Suppose Bob has no bitcoins issued by Gatehub, but accepts them as payment. And now suppose Alice sends 0.1 bitcoin to Bob. Gatehub will wind up owing Alice 0.1 bitcoin less and owing Bob 0.1 bitcoin more. From Gatehub's point of view, 0.1 bitcoin of their obligation has "rippled" from Alice to Bob. Gatehub doesn't need to do anything but allow rippling for this to happen. Obviously, gateways want to allow rippling. Allowing rippling is their business model. Now, imagine if Alice holds one bitcoin issued by Gatehub and one bitcoin issued by Bitstamp and is willing to hold more of each. If she is completely indifferent to which gateway owes her the bitcoins, she could allow rippling. If she imposed no quality fee, she could allow someone who held bitcoins issued by one gateway to pay someone who only accepted bitcoins issued by the other gateway to ripple her payment through her account. She would then wind up being owed more by one gateway and less by the other, but no better or worse off. The downside to allowing rippling is that if one gateway goes out of business or has some kind of problem, other people will automatically use you to convert to the asset they prefer. You will wind up maxed out on whatever asset is the worst. So it can increase your risk significantly, even if you really don't care which asset you hold. Note that rippling cannot occur across currencies.
  • Create New...