Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JoelKatz

  1. When viewing a single order book, the funded amounts take into account funding consumed by better offers. So in your example, the offer that would get taken first is fully funded, 4 BTC. The next offer is only partially funded because the owner could only supply 1 BTC to pay it. This is one of the reasons it's so difficult to support paging of offers in an order book -- the server has to keep track of remaining funding levels from previous offers being consumed in order to compute the funding level of subsequent offers. A person with, say, 10 BTC can make 10 BTC of offers appear funded in as many different order books as they want. But they can only produce 10 BTC of funded offers in any one order book. We don't consider an offer funded if there's no possible way funds could be available for that offer without other things on the ledger changing. But we do show them as funded if a transaction that draws down that order book could take from that offer.
  2. For bit payments, you want to use atomic mode and validators. That way, so long as a quorum of the validators aren't malicious, those failure modes aren't possible. The validators don't have to know the details of the payment either. They just have to know what the commitments look like and when the payment is supposed to expire. Ideally, a number of well known companies would run ILP validators (they can charge for their services) so the risk of this kind of collusion would be tiny. And you can pick validators that you have contracts with or are in a jurisdiction that would allow you to sue them. Essentially, all the validators do is agree that they either did, or did not, see a particular thing happen (based on cryptographic evidence) by a certain time. It's the proof of absence that you can't reliably have in universal mode that forces you to rely on a timeout.
  3. ILP has two modes. They're both atomic under almost all conceivable circumstances. One is just atomic even under many almost inconceivable circumstances. Consider a simple ILP payment where Alice has XRP and wants to pay Bob USD. Charlie is the middle-man. Alice sets up a transaction to pay Charlie if and only if Charlie pays Bob. Now, Charlie can safely pay Bob knowing that his proof of payment to Bob will allow him to complete Alice's transaction to him. But remember, Alice doesn't trust Charlie. She's worried Charlie may not make a payment to Bob. So she doesn't want to lock up her funds for a very long period of time, in case Charlie doesn't make the payment to Bob and she has to look elsewhere. But what if Charlie makes the payment to Bob and something goes wrong and he's not able to get the proof of payment to complete Alice's payment before it expires? So Alice wants the payment to be valid for as little time as possible in case Charlie fails to pay Bob, but Charlies wants the payment to be valid as long as possible to protect him in case some network or ledger failure prevents him from getting confirmation that he paid Bob delivered to the ledger in time to claim funds from Alice. For low-value payments, this is not a big deal. Charlie can just price the small risk into whatever he charges for his service. If the odds of such a failure are one in ten thousand, he can just add one more basis point to his rates. The solution to this problem is atomic mode. In atomic mode, you have an m-of-n setup of validators that collectively agree that Charlie did or did arrange to pay Bob on time. If they agree he did, then that receipt of agreement completes every payment. If they agree he did not, then that receipt of agreement cancels every payment. Now, Alice can set a tighter time window and Charlie doesn't have to worry that he'll pay Bob but not be able to release Alice's payment on time. The tighter time window is imposed by the validators, not Alice's ledger. Atomic mode doesn't require the ledgers to do anything differently. They still make a conditional payment. It's just that the condition that releases the payment comes from the validators, not from the destination ledger.
  4. To be fair to Stellar, when they initially launched, they had the best tech in the business. Shortly after they launched, I was asked about Stellar in an interview. I said exactly that, and the interviewer said something like, "Oh, really. I wouldn't have expected you to say something so nice given their relationship to ..... Oh."
  5. I don't know of any exchange that requires a destination tag when you're not sending to an account that requires one. But you can use any destination tag if you're sending to a native wallet. 1 is perfectly fine.
  6. Well, we have proposed a solution to incomplete or invalid payment instructions -- the origin and destination institutions connect to each other directly over the Internet and confirm the validity of the payment instructions. And the whole point of using XRP as an intermediary is to ensure that the beneficiary has use of the funds by atomically transferring ownership of funds to the beneficiary at the time of the payment. He's right that there are a lot of structural obstacles to 24/7 payments and many of them are inherent in the financial institutions. Faster payment and settlement infrastructure, whether it comes from Ripple, Swift, or someone else will pressure FIs to improve.
  7. Hmm, what does that remind me of? https://www.finextra.com/newsarticle/29512/ripple-rudely-gatecrashes-sibos-party
  8. You're welcome. I certainly hope you're right.
  9. So, what is settlement risk? Wikipedia explains it thus, "Settlement risk is the risk that a counterparty (or intermediary agent) fails to deliver a security or its value in cash as per agreement when the security was traded after the other counterparty or counterparties have already delivered security or cash value as per the trade agreement." The classic example was a bank that received the funds for a large collection of international payments and was supposed to pass on the outgoing funds to other domestic banks. The bank simply failed to open, disappearing with the money they received in exchange for the funds they never delivered. This is called "Herstatt risk" after the name of this bank. You can read more about it on the wikipedia page. CLS provides netting of payments. It eliminates Herstatt risk by using a combination of simultaneous exchange (to protect from people spending funds they don't have) combined with insurance (to ensure the underlying funds are custodied reliably). Ripple's solution IS a CLS-like system. Specifically, ILP does provide for atomic, simultaneous movement of a number of assets. However, it is vastly superior to CLS because it can accommodate assets that live on very different ledgers with very different semantics without loss of atomicity. It does not require the parties to trust the ledgers the intermediary assets live on. It does not require a single, trusted central authority. It does not need to be a walled garden. ILP does eliminate Herstatt risk because the XRP is actually guaranteed to be delivered to the recipient with the transaction. No insurance is necessary because the XRP only exists on the ledger, so there is no counterparty to fail to secure the underlying asset. You do need to hedge the risk of XRP value volatility. But I think an open system will beat a walled garden every time. As for Swift having a natural advantage, I think they also have lots of natural disadvantages. They're not an innovation driven, agile company. Their stakeholders really have no reason to want to see Swift invest the kind of money it would take for them to build such a system when Ripple is already building it. Swift has nothing like XRP, so they have no way to get Ripple's revenue model. So we can justify spending a lot more than they can and our stakeholders are in for the high risks involved and don't mind disrupting the status quo in banking. That said, I wouldn't say there's no validity to what he's saying. I've always conceded that Ripple is swinging for the fences, attempting to change the world in a radical way. The safe bet is always against that, but the smart bet ...
  10. He may or may not be, but you have to follow even the laws you are against. That is, assuming you value your freedom and your ability to sleep at night.
  11. That account does *not* have the "destination tag required" bit sent on it. So the funds would have transferred. You should contact the recipient to track your funds. While you're talking to them, ask them why they haven't set the "destination tag required" account flag to prevent just this kind of mistake.
  12. Can you share with us the address you sent the funds to? With that, I can tell you whether the funds would have transferred or not.
  13. Yes, I was referring to me. I'm one of many Ripple employees who were granted stock or stock options that vest over time if we continue to remain employed. There are really only three ways to get Ripple stock: 1) Work for Ripple, get offered stock options, wait until they vest, exercise them. 2) Invest in Ripple during a funding round. This is not easy to do now as Ripple can afford to be quite selective in choosing its investors and, by law, you have to be legally able to buy unregistered securities. Typically, Ripple would be looking for investors that either corroborate its valuation (for example, investors legally obligated to maximize value and who have the capability to do significant due diligence) or forge strategic alliances (such as financial institutions). 3) Buy Ripple stock through a registered broker from someone who already has it. There are companies such as EquityZen and SharesPost that are registered brokers in the US who can broker a sale of an unregistered security to a sophisticated investor.
  14. I know at least one stockholder who is interested.
  15. I think it's a lot like asking what makes a service offered over the Internet better than a service offered over a proprietary network. In the early days, this one factor wouldn't make all that much of a difference. But over time, you're either going to have to take over the world or interoperate using open standards. I also think that building deep pools of liquidity is going to cost a lot of money. PayCommerce can't materialize revenue from liquidity through a token. Ripple can. Even if you assume the price of XRP stays roughly where it is now, Ripple takes a third of its XRP revenue as dividends to stockholders, needs a third of its XRP revenue for other expenses, and Ripple sells its XRP over ten years, that still gives Ripple over $300 million per year for each of the next ten years that it can spend on incentivizing liquidity. No other revenue model that I can think of can compete with that. (Of course, you probably couldn't materialize $300 million the first year because there's unlikely to be enough liquidity. But that just means you get more later.)
  16. Yes, that's exactly right. Pricing can also take into account the costs that various gateways charge and the delays in their issue and redeem processes. So, all other things being equal, a gateway that has lower redemption costs and/or higher redemption speed might produce assets valued a bit more highly. Ripple permits you to place an offer to exchange any two assets. So you may see offers to trade USD issued by one gateway for USD offered by another gateway. There are also separate books to common assets. So there's a book between USD/Bitstamp and XRP just as there's a book between USD/Gatehub and XRP. When you make a payment, the pathfinding system looks at the various order books and rippling possibilities. If you hold the same currency from more than one issuer, or the recipient accepts the same currency from more than one issuer, those can be taken into account too. The pathfinder selects some paths and the payment execution engine can draw from combinations of those paths to get the best overall rate for the payment.
  17. Well, you could still finance a war either by raising taxes or by borrowing. The former is much more difficult if the population doesn't think the war is just because they feel the taxes. But, unfortunately, borrowing money still works and is not always painful enough in the short term to act as sufficient discouragement.
  18. My hope, though I don't really have any rational basis to think this other than a hope, is that the explosion of digital assets gives everyone the ability to hold the asset of their choice. And, when they have a choice, they won't hold an asset that can be debased by inflation. That is, I think eventually digital assets will act as a significant check on government's ability to finance things (like wars) by printing more money.
  19. Try logging out, refreshing, and logging back in.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
  • Create New...