Jump to content

JoelKatz

Ripple Employee
  • Content Count

    883
  • Joined

  • Last visited

  • Days Won

    82

Everything posted by JoelKatz

  1. The beauty of things like Bitcoin and Ripple is that you can decentralize them even if everyone runs somewhat different code. The more things people have to agree on, the harder it is to decentralize. While there are some things that they do have to agree on (such as the consequences of a transaction that the network has decided to execute), there are lots of things that they don't have to agree on. In Bitcoin, for example, miners have complete freedom to decide which valid transactions to include in blocks that they mine. And servers have complete freedom to decide which other servers they're willing to connect to and what transactions they're going to relay. The software has mechanisms to tolerate disagreement on these issues. And the more disagreement you can safely tolerate, the easier to decentralize. In Ripple, we've explicitly declared that there does not need to be agreement on which transactions to relay or what fee levels to request in validations. The code is specifically designed to smoothly tolerate disagreement on these things just as Bitcoin's code is designed to smoothly tolerate disagreement. Disagreement over fee levels, and tolerating that disagreement, is required in Ripple to prevent the network from being as fast as the fastest validator (reducing protection against collusion or shrinking the network to a small number of superfast computes) or as slow as the slowest validator (and losing performance). This mechanism served almost precisely its intended purpose, allowing validators to raise the fee to protect themselves from being overwhelmed. Unfortunately, due to the slow response of the current fee escalation code, we had to do this before the load was seen. We've considered coming up with a more sophisticated temporary fix, but the workaround has created no issues and a fee of 10,000 drops is still essentially negligible. Torrie didn't bring this to anyone's attention, you did. (Well, actually, Yana and I did quite some time ago: https://forum.ripple.com/viewtopic.php?f=2&t=8090&p=57273#p57303 .) But unless she's said something to you about it, we have no idea whether this is what she's talking about. Her exact words were, "special backdoored versions of the software". To describe the fee knob that way would require someone to be either totally uninformed or intentionally dishonest. The fee knob produces only a single, obvious change in the validations produced, which are immediately made public. Unfortunately, the fee queuing code has hit several blockers in other parts of the code. So it's taken longer than we expected. We could probably add code to raise the fees more quickly without the full fee queuing code. But there haven't been any actual issues reported by anyone as far as I know, so it seems pointless to make another temporary fix to something that already has a temporary fix. "I signed an NDA, but not sure going along with untruths was part of it." Can you state specifically what you think is an untruth?
  2. That's true. That's the only change between the public code and the code on the validators that we've had in several years. Rippled's fee escalation code responds too slowly in some circumstances, allowing a denial of service attack where an attacker can cause the required fee to go unreasonably high for short periods of time. We've had a major effort underway to completely rewrite the fee escalation code to fix this problem and also bring a number of other improvements such as more a predictable relationship between the fee paid and when the transactions gets included in the ledger. You can see some of that work here: https://github.com/ripple/rippled/commit/9329aafe53a0faf0f4e92bb7790d815217828024 Temporarily, we've added a patch we call the "fee knob" change. This allows the fee that's advertised in validations to be adjusted manually. It is an explicit network rule that validators are permitted to set the recommended fee in their validations to whatever they think the network fee should be (and client handlers won't relay transactions whose fees are too far below this because they expect validators won't include it). We've used this fee knob to hold the network minimum fee to 1,000 drops and it will likely remain there until the fee-based transaction queuing code is deployed. This is the reason you'll see a "load_factor_net" of 1000 on the network right now. Rippled measures the network load factor by looking at the "LoadFee" field in validations. It has no effect on the results of a transaction once it is processed. And it sets the floor fee for *all* transactions equally.
  3. I was quite surprised to find out that Torrie felt this way about her time at Ripple. I always found her to be competent and professional. She deserves credit for all the improvements she describes, accomplishments achieved in just six months. One accusation requires a specific response, "Agreements within the team that special backdoored versions of the software needed to be produced as security through obscurity." I have no idea what she's talking about here. I personally approve the code that runs on the validators, and there has never been any kind of backdoor in the code that runs on our validators or other production Ripple servers. There has never been any discrepancy in the public code and the code run on our production servers that affects how transactions are executed, what transactions are considered valid, or anything of that kind. And if there ever was such a thing, it would be easily provable since every transaction's consequences are publicly published in the ledger chain along with the cryptographically-signed transaction that justified them.
  4. That's not very likely to work. Imagine doing the same thing with cash. Some money is stolen from you, so you report the serial numbers. Eventually those bills wind up at a bank where they're taken from the person who deposited them and credited to you. Well, how many problems you can find with that system: 1) The person depositing the cash is probably innocent. 2) The person who reported the theft might be lying. 3) This would make cash a lot less useful. As soon as you got cash, you'd pretty much have to get it to a bank immediately, and you would need some recourse if the bank said the funds weren't good. So the use cases for cash would shrink dramatically. So, unfortunately, freezing IOUs doesn't address this kind of theft case very well.
  5. Not really. Things will happen elsewhere and, if we're successful, eventually they'll realize that the legitimate uses make continued prohibition nonsensical. Image if the United States had prohibited use of the Internet in the early days. There would still be an Internet today, it just would have been developed elsewhere. And the United States would have had no choice but to remove the prohibitions on using it. Regulators will eventually realize that you can either regulate something or prohibit it but not both. The smart ones won't want to shut their country out of the benefits. Essentially, I suspect the same thing will happen as happened with encryption.
  6. We are basically betting on two things: 1) It makes sense to have a vehicle currency between assets, at least other than the very most popular ones. 2) It makes sense for that vehicle currency to be a crypto-currency. Given those, we're going to do what we can to position XRP to be that vehicle currency. The argument for 1 is that if you're not dealing with the most popular assets, their won't be enough people who both want to buy the asset you need to sell and want to sell the asset you need to buy. So using an intermediary asset will make sense. The argument for 2 is that other assets will be tied to jurisdictions and issuers. ILP doesn't help people hold assets. You still need an account on the ledger to hold the asset. But anyone can hold XRP easily. If you're trying to buy and sell assets, XRP is one that you're guaranteed to be able to buy and hold with ease. The Fed might issue USD on an ILP-enable ledger, and that might seem like a killer vehicle asset. But are they going to let ordinary guys all over the world hold it?
  7. The future is notoriously difficult to predict and I don't have a crystal ball. But my gut intuition is that the very smallest asset pairs won't matter and the very largest asset pairs will have heavily optimized direct paths operated by big players. But that could leave a huge, juicy center of conversions between medium popularity assets. Even if you assume that all the major assets have direct paths between them that are unbeatable, XRP can still make sense when exchanging between minor assets and major assets as long as the major assets have equally good paths to XRP. XRP won't make sense as an intermediary currency between the major pairs in that case (because you'll pay two spreads rather than one). But it will mean that if you have to exchange between a major currency and a minor currency, XRP is as good an intermediary as any as far as the major currency side is concerned. If XRP has a lower spread to and from the minor currency, then XRP will be the best intermediary for the exchange as a whole.
  8. They can be anywhere. Any exchange that speaks the ILP protocol can provide quotes and inter-operate with other connectors and ledgers. One possible path would be for existing forex exchanges to use ILP to inter-operate the same way we hope existing ledgers will.
  9. We've had a lot of talks about what use cases it can serve. In the short to medium term, I wouldn't expect to see us working on this very much because there just don't seem to be any significant, imminent use cases. The main reason to issue counterparty assets on a public ledger was that you had to in order to inter-operate with assets on a public ledger. If you don't, a lot of the main driving use cases evaporate. Of course we're not going to remove the functionality, other interested parties can work on it if they want to, and we'll constantly re-evaluate our tactics to expend effort where we think it will do the most good. I know this is probably controversial and I must admit I do feel a bit sad about it. But we can't make everything a priority. It's possible these use cases will become significant once ILP is up and these kinds of assets have better liquidity to assets on private ledgers too. The issue is not that there aren't advantages to trading counterparty assets (IOUs) on a public ledger. There are. The problem is that there are no killer use cases that these advantages enable.
  10. If the spread to and from XRP is less than half the spread to and from other popular currencies, then people who want the cheapest price will trade through XRP. And so long as volatility is tolerable, people who don't know what asset they will need next will hold XRP and people who are looking for deals on many currencies will hold XRP. This makes the spreads a powerful lever that can be pushed on.
  11. I don't claim to have a crystal ball here, but my expectation is that the most common interaction between XRP and ILP will be an ILP transaction with a source on one private ledger and a destination on another private ledger involving an intermediate XRP transaction from one market maker to another.
  12. Once you authorize a trust line, the only way you can unauthorize it is to freeze it. We could add code to allow you to unauthorize it if the balance is zero, but that feature has not been requested.
  13. The idea that a startup could be successful by reneging on its deal with its founders while those very same founders are running the company is completely absurd. We were very, very careful not to let the company ever create any XRP.
  14. This was a movement of funds from and to accounts that only Ripple has access to. The transfers have nothing to do with any court case or court order.
  15. By the way, if you want to see some of the work we've done to reduce bandwidth usage, take a look at these commit IDs: https://github.com/ripple/rippled/commit/d6df73747fa7e05d2d288dfd355226eaf471d440 https://github.com/ripple/rippled/commit/fe89c74e3b3b0330faacef1d7ea2fe0617fe7294 https://github.com/ripple/rippled/commit/61e5359231b304bd7c950c8e17e7092872df7737
  16. In that scenario, IOUs would exist primarily on private ledgers. If you have $100 in a bank account, then you have a $100 IOU on a private ledger.
  17. Here are a few things you can do to reduce bandwidth usage: 1) Run the latest develop. Right now, it has a lot of bandwidth conserving and measuring changes. 2) Limit the number of peers you allow. Most bandwidth usage scales with the number of peers you allow. 3) Limit the amount of history you fetch. Unless you need lots of history, don't set `ledger_history` above 256. 4) Limit the amount of history you offer to others. Unless you want to be very generous, set `fetch_depth` to 256. 5) Audit your bandwidth usage occasionally. With the latest develop, you can use the `print` command and search the resulting output for the "traffic" section. It will break down your traffic by category and help you understand what you're using your bandwidth for.
  18. By "ground XRP", I mean what the blockchain does for Bitcoins. While they can trade on other systems, the blockchain is the authoritative place where Bitcoins exist and where a record of who owns them is kept. While you can have Bitcoins other places, what it means to have Bitcoins is to be able to transfer them on the blockchain. In this sense, the blockchain grounds Bitcoins. RCL grounds XRP.
  19. If ILP provides everything people want from RCL and more, then RCL might become deprecated as a platform for launching private "IOU-type" currencies and may be used only to ground XRP. But that's a long way away. Today, Ripple Connect connects FIs to RCL. In the near future, Ripple Connect will support ILP as well as RCL.
  20. People said the same thing about the Internet -- no government's going to put with a way to exchange information that can't be centrally controlled and regulated.
  21. Five bells was the original internal codename for what became ILP. Five-bells-ledger was the internal name for the first private ledger that supported ILP. Five-bells-trader was the internal code name for a mock trading engine that used ILP. Instances of five-bells-ledger and five-bells-trader together provided an environment in which ILP could be tested with ILP-enabled ledgers and ILP-enabled trading engines. At least initially, the focus was on the external interfaces of these things so that parts could be developed and the system as a whole could be tested.
  22. Right. You can use the equivalent of encryption where you can still preserve the ability to verify the data. Unfortunately, that's not everywhere all the time, at least not without significant trade offs.
  23. The point of a distributed ledger is that everyone can check that the data is valid. If it's encrypted, how does that happen?
  24. And with ILP, that's no longer an obstacle to XRP being used as a bridge currency for transactions involving assets they issue.
  25. Yeah, you can do anything you want with them so long as you don't try to buy or sell them.
×
×
  • Create New...