JoelKatz

Ripple Employee
  • Content count

    580
  • Joined

  • Last visited

  • Days Won

    63

JoelKatz last won the day on June 25

JoelKatz had the most liked content!

About JoelKatz

  • Rank
    Veteran Member

Contact Methods

  • Website URL
    https://gigabitether.net

Profile Information

  • Gender
    Male
  • Location
    Oakland, CA
  • Occupation
    Chief Cryptographer, Ripple
  • Country
  • Ripple Name
    ~JoelKatz
  1. I agree. But if we're successful in getting ILP broadly deployed, wherever we're able to create the liquidity, the volume will follow immediately. Take a look at steps 3 and 4 here: We also have other strategies to bootstrap liquidity and volume in targeted corridors and strategies for selecting corridors. But we're not ready to make that public yet. No. ILP is a protocol like HTTP or TCP. You can run as many instances of it as you want all over the place and they don't affect each other. It has horizontal scalability.
  2. That is our hope. We would love to see broad adoption of ILP across all kinds of payments systems and stores of value. That would create a massive level playing field for XRP to compete on. The idea is to knock down all the technical obstacles to XRP bridging payments.
  3. Possible, but difficult to achieve. It would be amazing if that kind of thing happened. Another reason to make XRP part of an open system is to allow other people and other organizations to pursue their projects and visions. We hadn't been getting much transaction on that front until recently. We're seeing a lot more cases where people would use Bitcoin, but can't because on-chain transfers are too expensive. They test our XRP and see that they can fully confirm a transaction in less than ten seconds for less than a penny. And they wonder why anyone would use anything else.
  4. You're effectively asking why Ripple is building an open network rather than a closed one. I think the simplest way to see why an open network is better is to look at the Internet. You can't get broad cooperation with others to build a closed network. Also, the competition that an open network fosters produces a better end result for everyone.
  5. I think you're confusing two different things. The 0.2% gatehub transfer fee is charged when you try to transfer an asset gatehub issued. So if you have 100 Euro, you can only deliver about 99.8 Euro to someone. However, how much XRP that person gives you for your Euros is up to them. To get a better rate, you have two options: 1) Make a payment to yourself, delivering XRP but paying with Euro. This will use the network's pathfinding system to draw from multiple pools of liquidity and generally gets you a better rate than a direct exchange which only uses two liquidity sources. 2) Place an offer to trade Euros for XRP and wait to see if someone else takes it. Make sure to cancel it if the price of XRP changes sigificantly.
  6. He says this: Either he doesn't understand the difference between payment and settlement or he's deliberately trying to mislead people. Also: Actually, we've done precisely the reverse. Just a few months ago, we didn't even have a link to XRP on our home page. Now, it's up front in all of our messaging. Lastly: This really makes no sense at all. We hold over 60 billion XRP with a notional value of over $20 billion, which we can sell over time at near zero cost (assuming the price and liquidity holds). You think our bank software business will be anywhere close to that any time soon? How many banks do we have to sign to get as much revenue as a 1 cent increase in the price of XRP? 100? 300? But, of course, we don't have to choose because they both go together perfectly. Every bank that adopts our services and network is one more endpoint whose payments can settle over XRP the instant the liquidity is there. As for it being "potentially impossible", I would just say that it's very unlikely that we won't ever have instantaneous global settlement. If there's a technology or product in existence that can do this better than XRP, please tell me what it is. And if you're talking about something not in existence, why would you think we'd find it impossible to compete with something that doesn't even exist yet? And remember, right now we hold more than half the XRP that will ever exist. If getting banks to buy XRP was the bottleneck, we could easily just give it to them.
  7. We went to a lot of trouble to design Ripple as a system with no privileged accounts or administrative functions. If you want that to be changed, why use a public ledger system?
  8. All of the software that runs the public ledger system is open source. This is roughly analogous to the bitcoin source code. Ripple's "secret sauce" software is what adapts banking systems to protocols like ILP or public ledgers. This software handles things that have nothing to do with crypto-currencies or public ledgers such as end-to-end payment negotiation between FIs. Anyone is free to build anything they want on top of XRP's public ledger or any other public ledger. They are free to make it open source or closed source as they wish. It's not inconceivable that we might make the banking software open source at some point in the future. I don't think it would accomplish all that much though since it really is targeted exclusively at integration with FIs.
  9. Where you hear "x current", think Ripple Connect.
  10. Yes. We use beast for a variety of small things, for websockets, for HTTP parsing, and (of course) NuDB for servers that store lots of history. Vinnie and I designed NuDB together (he did almost all of the coding).
  11. If you're not keeping that many ledgers, you don't need to use SSDs. The issue is, believe it or not, one of RAM. RocksDB works great on spinning disks, but it must cache its indexes in RAM or performance is terrible. NuDB does not require any significant amount of RAM for caching, but performs terribly on spinning disks. Figure RocksDB will want RAM roughly 1/100th the size of the database.
  12. Ripple holds something like 60 billion XRP with a notional value of something like $12 billion. To say that Ripple's profit is based on software sales is just not true. I expect that what you're suggesting will happen. XRP will compete with those kinds of solutions as well as with other crypto-currencies on a level playing field. The problem any banking network token would have is that without deep pools of liquidity, it can only be used for payments, not for settlement. Say I receive an international payment for $1 million and my bank receives some new banking network token. Now, say I want to wire that money over a conventional, domestic payment rail. What does my bank do with the token? So, two solutions: 1) Banks launch a token pegged to fiat and finance the pools of liquidity themselves. Well, this is not going to be a neutral, international asset because it's pegged to some particular fiat. Also, banks will have to pre-fund all payments out of their own pockets or they'll still have multi-day settlement times. 2) Banks launch a token very much like XRP and seek to finance the creation of liquidity through the appreciation of the token. I think this is a very unlikely scenario for many reasons, but even so, we're *way* ahead of them in establishing the value of the asset, getting financial institution buy in, assembling a qualified team, raising capital, and many other areas. But, yes, if a new company or consortium tried to do exactly what we're doing, we'd have to compete with them. By the way, solution 1 is potentially awesome for us. Those islands of fiat-pegged, banking tokens will need some way to settle with each other, and we think XRP would be a perfect way to do that.
  13. No. It's not. But you can throw away the older 500K ledgers when you have 1M ledgers.
  14. This is exactly what we fought with for our first few years and one of the main reasons we changed our strategy. Initially, we offered banks a product that only handled payments and settlements over our ledger. Banks liked the speed and convenience, and one could imagine that being a great solution if everyone was using it, but how could you ever get to that stage? So we changed strategy. We made the software agnostic to how the money moves. You can use our software for payments and still use correspondent banking to move the money. Now, why would you do that? There are a few reasons, but the main one is simply that traditional inter-bank payments push money and information together optimistically. If there's a problem, say the recipient information is incorrect, the payment won't fail until the money is on the way. And then that mess has to be sorted out, and banks hate that. Also, they can't tell their customers how much money will be delivered or when the funds are received. So we built software that solves all those problems. And banks are paying for it and working to integrate it into their systems. They're working on compliance, business rules, and all the other things needed to make faster payments work. And all this is a win for the banks even if all of their payments still move through correspondent banks. But now we have the framework to settle on a blockchain ready to take advantage of. We will have broken the chicken and egg problem. See here for more:
  15. The only risk with that scheme is that if you submit a second transaction with the same sequence number before the first one has definitively failed, it's possible for the transaction to go through twice. If that's a payment, that's really bad. Consider there are two things you want to do, A and B. 1) You submit A, it gets sequence 5. 2) You submit B, it gets sequence 5 too. 3) You submit B again making the sequence 6. 4) You really can't be absolutely sure which of several outcomes will occur. But B(5), B(6) is possible. It's unfortunate that we kind of punted on the problem of robust transaction submission. We really should have done a better job of documenting best practices and included at least a reference implementation in ripple-lib. We're working to get resources to improve ripple-lib and handling concurrent transactions better should definitely be on that list.