Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JoelKatz

  1. 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.
  2. The amount of XRP you can send is the amount of XRP you have, minus 20 XRP, minus 5 XRP for every object you own (such as an offer or trust line). If you post or PM me your Ripple address, I can tell you how many objects you own and what they are.
  3. Usually a "market maker" is someone who offers to trade one asset for another. There is no need to trust them since all on-ledger exchanges execute atomically. Pathfinding will find market makers. If you mean gateways, new gateways can make their assets liquid by acting as there own market makers. That way, even if only one person has a trust line to them, that person can still make and receive payments in a variety of assets. While there is some increased benefit to using a gateway that lots of others use, it's more important that the asset be liquid, and the gateway can do that by itself. Users will likely choose gateways based more on how convenient for them their issue and redeem policies are and also how reliable they believe the gateway to be. Gateways don't need trust lines to or from any other gateway. Generally speaking, you'd prefer a gateway that doesn't trust any other gateway because that reduces the risk they will become insolvent due to another gateway failing. Though a small amount of such exposure, assuming the gateway could cover the risk from their own funds, would likely be acceptable if it made the asset more liquid. For example, say I started a new US dollar gateway. If I had $100,000 in capital, I could deposit $50,000 with Gatehub Fifth and $50,000 with Bitstamp and permit people to freely exchange, on ledger, between those two USDs and the USD that I issued. That would make my USD about as liquid as either of those two.
  4. I posted a response. Here's what I wrote: This is just total gibberish. Trust lines have nothing to do with either XRP or how consensus works. Taking it point by point: 1) XRP works exactly like bitcoin, it trades on a public ledger and acts like a native token in a public payment system. 2) With bitcoin, you don't just have to trust only the mathematics of proof of work as recent experience shows. You also have to trust governance when there's a chain split or a disagreement over evolution of the network. You also have to trust the majority of miners. For example, right now the Chinese government could pass a law prohibiting mining blocks on top of UTXOs they deem "bad", and those bitcoins would become unspendable. 3) Ripple does not issue any assets on the Ripple ledger. There are no trust lines that end at Ripple. Trust lines are used only for assets other than XRP such as bitcoins, dollars and Ether, which can trade on the Ripple ledger if someone bridges them. If you use XRP, you don't have to do anything with trust lines. 4) Servers also have nothing to do with trust lines. Consensus is about how the double-spend problem is solved on Ripple. It's roughly equivalent to mining on bitcoin except there's no reward -- transaction fees in Ripple are destroyed, not rewarded. And much like mining, it just decides which transactions go in at what time to solve the double-spend problem. Just as you don't have to mine bitcoin, and you can still hold and spend them, you don't have to participate in the consensus process on Ripple to hold and spend XRP. 5) There is no sense I can think of in which XRP is akin to a PayPal account. For example: You don't need anyone's permission to hold XRP. There is nobody who can disable or cancel your account. XRP are not an enforceable obligation on anyone's books. You don't need anyone's approval to transact. You create a new XRP account just by sending XRP to it. I have no idea what point you're trying to make here. You are confusing currencies with assets. XRP (on the Ripple ledger) is an asset. Dollars are a currency in which assets can be denominated. There is no way to use dollars for settlement, because dollars cannot be teleported. If you're going to imagine some private token denominated in dollars, you'd have exactly what they're doing now, and you might have noticed that they don't have rapid settlement now precisely because they don't have a settlement asset. You can disagree with the validity of the use case we've explained over and over, that rapid payment systems will drive demand for rapid settlement systems. But to ignore it or pretend we haven't made it is, at least in my opinion, inexcusable. (I am an employee of Ripple, but I am speaking only for myself.)
  5. If you just need payment, you don't. But if you need settlement (you need to actually move money), you need some asset that flows to the person who is providing the recipient's funds where the recipient needs them.
  6. Yes. Additional algorithms can easily be added, just as we added Ed25519. Existing accounts can be re-secured with a new key if desired. So you won't need a new ripple address. We haven't actually added any quantum-safe algorithms yet because none of the ones available today are perfect for our use case. And any algorithm we add we'll have to support forever. So we'd prefer to wait as long as we safely can so that we'll have the most information to make the choice of algorithm(s) to implement.
  7. This is basically just saying that if unless you assume that network connectivity cannot be disrupted forever, you cannot produce a guarantee that the system can make forward progress. But if you assume that any disruption in network connectivity will eventually end, then you can get a system that guarantees that you will make progress.
  8. There is a huge advantage to having one entity that holds a significant fraction of an asset. Ripple could spend $100 million on something that has no conventional way of creating revenue, but if it pushed the price of XRP up by one penny over the long term, Ripple would massively profit. Nobody has that kind of concentrated interest in any coin distributed primarily by mining. The money that would have gone to pay for ASICs and electricity to mine the asset instead goes to building the liquidity and technology to make XRP attractive for the use case Ripple is focused on. There are things an asset that isn't mined can do that an asset that's mined cannot do because of this difference. Let me give you a stark example. The Bitcoin foundation has been trying to raise funds to combat New York's BitLicense regulation. On April 10, 2017, they announced that they needed to raise between $100,000 and $200,000 and that the first hearing was May 4. Likely these efforts would benefit many bitcoin users and holders, but nobody has a concentrated enough interest to pay the bulk of the funds. This a clear example of a public good free rider problem -- everybody is worse off if nobody contributes, but nobody has a strong individual incentive to contribute. Everyone wants to be the only one who doesn't contribute. As of today, more than one month past that hearing, they've raised about 3 BTC. How much do you think Ripple can (and does) spend on regulatory issues critical to using XRP for its use case? The reason is obvious -- keeping the regulatory way clear for XRP's use for settlement makes a huge difference to Ripple, the company, specifically.
  9. If you aren't trying to keep more than a month of history, you may wish to switch to RocksDB. It does a better job of handling IOPS reductions at the cost of requiring more memory. The amount of memory RocksDB depends on the amount of history you're keeping, so if you aren't keeping very much and your IOPS are variable, RocksDB might be a better choice. Because RocksDB uses a collection of files, you do want to make sure your file descriptor limit is fairly high. You can check (and possibly raise) the limit with "ulimit -n". [node_db] type=RocksDB open_files=512 file_size_mb=16 file_size_mult=2 filter_bits=12 cache_mb=256 path=/path/to/database/rocksdb
  10. I guess I'll have to read the paper more closely. One thing seems to be a misunderstanding. I'm saying there has to be universal agreement on the participants, that is, on who is in the set that is trying to agree. I don't mean that all of those participants need to agree for the system to make progress, just that each of those participants must be in agreement on who all of the other participants are. I'm not sure what the difference is between the problems being solved. Aren't both algorithms trying to get a defined set of participants to agree some set of binary decisions where some fraction of those participants might be absent or malicious?
  11. Are you using spinning disks, SSD, or some kind of network disk? Are you using NuDB or RocksDB as your back end? Your server statistics look pretty good, at least at the instant you performed that server_info.
  12. I've now had a chance to skim their paper and it appears that fundamentally, it does the same thing PBFT does. Its primary advantage over PBFT is speed. PBFT, as specified in the paper, is unoptimized (they're trying to make it easy to understand and implement) and you can trivially improve its performance by a factor of 3 or so. This paper claims to provide improvements well beyond that. There are a number of applications it might be suitable for (such as ILP consensus and private blockchains) but it doesn't seem possible to design a public blockchain around it. This is because it requires universal agreement on the participants in the distributed agreement protocol. I guess you can trivially relax it to not require strict agreement just by considering any node not in everyone's list of participants to be a failed node. In that case you could probably use it for a public blockchain, but you would require a higher degree of UNL overlap than Ripple's consensus algorithm requires. I don't know that there would be much point though with transactions like Ripple's. Its only advantage over other algorithms seems to be performance. And the performance of the distributed agreement algorithm is not a limiting factor in the network. The limiting factor is the time it takes to actually execute the transactions. In fact, the vast majority of inter-ledger time (typically 4 out of the 5.3 seconds) is the two mandatory delays to ensure that nodes can keep up with the transaction execution process. If you were trying to design a new semi-public or private ledger and you wanted very low confirmation latency for very simple transactions, this would likely produce better results than anything else out there. It might be useful for ILP validators as well where latency is important and all participants are known.
  13. Their tech is explained here: http://poseidon.it.usyd.edu.au/~concurrentsystems/doc/ConsensusRedBellyBlockchain.pdf I haven't had a chance to look at it yet.
  14. If anyone has the transaction ID for a transaction that they believe has been lost, I'd be extremely interested to see it. Obviously, that is supposed to be impossible.
  15. By the way, I had no idea who I was sending it to. This was just the first request I saw on Twitter and I had an extra.
  16. You likely wouldn't use XRP this way until you could hedge the volatility risk. Instead, you would make your payment without XRP at either endpoint. XRP would be used internally to settle the payment using a protocol like ILP. At no time would you hold any XRP. But once the volatility is more manageable and you can hedge it, then it makes a lot of sense for you to hold just one pile of XRP rather than a whole bunch of piles of different fiat currencies in all the corridors you need to pay into. Even if XRP is three times as volatile as fiat currencies, if you can keep one pile of XRP rather than ten piles of different fiats, and your exchange costs are halved, it starts to look like a pretty good deal. But we're not anywhere near there yet.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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?
  24. 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.
  25. Where you hear "x current", think Ripple Connect.
  • Create New...