Jump to content

JoelKatz

Ripple Employee
  • Content Count

    883
  • Joined

  • Last visited

  • Days Won

    82

Everything posted by JoelKatz

  1. I hope you don't make this mandatory. For one thing, they don't support PCs. Also, just my luck, the first time in more than a year that I tried to use the gateway and ... Lastly, I'm ~JoelKatz and +JoelKatz, but my account can't claim the "JoelKatz" globalID that's reserved for a Gatehub user? Update: Everything's working for me again. If you fixed it, thanks. If it magically fixed itself -- umm, thanks, I guess. I logged out, refreshed my browser, and logged back in. I'm not sure if that did it. Update2: Despite my negative first impression ("oh, this is something I have to deal with when I have other things to do"), the globalID application looks quite impressive.
  2. That's one of the reasons I try to come up with a new way to explain it each time rather than just referring people to other places where I've already explained it. There are so many possible way to answer the same question and we want to get all of them out there. Different answers will click for different people because they all had slightly different things in mind when they asked the question.
  3. Here's a high level view that doesn't get bogged down in the details: Say I receive an international payment and then I want to send the money out using a domestic wire transfer. My bank either has to lend me money or wait until the international payment results in settled funds that it can use to fund the domestic wire transfer. If we want that to happen in seconds or minutes, the result of the international payment has to be that I now own some funds that were already wherever my bank needed them to be for me to send a domestic wire. So say the payment is from Thailand, and we want it to complete and settle instantly. That means someone will take ownership of the sending funds in Thailand. And someone in the United States will give me ownership of US funds that were already where my bank needs them to be. How will the person who gives up the US funds be compensated? And how will the person who takes the funds in Thailand pay for them? That's where XRP comes in. Why XRP? Because it can move in seconds, participate in conditional atomic transfers, has low fees and high throughput. But more importantly, there's a revenue model for Ripple to *make* it work for this application.
  4. Even if a transaction only takes a few seconds, as a practical matter, the funds are likely to remain at each end for some period of time before they go elsewhere. But also, if you don't know where you're going to need to send money and you're trying to be as efficient as possible, you'll hold the intermediary currency because then you only have to pay half of the cost. Say you're a company that need to makes lots of payments to lots of different places (like Uber, Amazon, and AirBnB). If some fraction of those payments wind up being bridged by XRP, it will make sense for you to hold a big enough pile of XRP to make those payments. That way instead of having to pay for two conversions, you only have to pay for one. And, on the flipside, say you have a big pile of money and you want to make money by exchanging it to facilitate other people's payments. Well, other people will need XRP to buy the currency they're trying to deliver. So you'll want to hold that big pile of money as XRP so that you can give them what they want and get what they're offering. At least, that's some of the thinking.
  5. It would also be 100% of the wrong thing. It would be like speculating if email could ever capture the volume of postal mail. Sure, if you were pitching email, you'd say that it has all the same use cases of postal mail. And someone would respond that it's not good for packages and the recipient can't physically store it. They might go on to say that maybe, at the most, 85% of postal mail doesn't absolutely require physical delivery, so maybe if email was ubiquitous it could capture 85% of postal mail's volume. But that would so obviously be very silly. To think of email as "like postal mail, but faster and cheaper" misses the extent to which being much faster and much cheaper fundamentally changes something. So, yes, at first you think of email as "if the other person has email, and you don't need physical delivery, it's faster and cheaper than physical mail", just as we think of XRP the same way today compared to conventional international payments. But I don't think any of us can predict where it will actually go.
  6. If we knew exactly what was going wrong, there's a chance we could recover the private keys. That's another reason it would be worth investigating. I wonder if offering a bounty would help or if I can generate interest inside Ripple in getting this figured out. It's a mystery. And I don't like mysteries. They give me a bellyache, and I got a beauty right now.
  7. If someone could track down exactly what's going on here, that would be extremely helpful. I've heard a few reports of this and suspect it's some incompatibility between ripple-lib and Safari. It may be an issue that affects other libraries as well, and it's a bit scary.
  8. 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?
  9. 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.)
  10. 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.
  11. 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.
  12. I guess Poloniex is just taking their time.
  13. 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).
  14. 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.
  15. 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.
  16. 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.
  17. 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!
  18. 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.
  19. 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.
  20. I think they're roughly two months out from general deployment.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
×
×
  • Create New...