Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JoelKatz

  1. There is no difference if the order gets placed on the books without first crossing any existing offers or only crosses existing orders exactly. But there is a difference if the offer executes (or partially executes) against a crossing offer at a better rate before being placed on the books. An offer to buy that executes at a better rate buys the same amount but costs less. An offer to sell that executes at a better rate sells the same amount buy gets you more in return. For example, say that there's someone offering to buy an unlimited number of apples for $1 each. An attempt to sell 100 apples for $50 would sell 100 apples for $100, since an offer to sell 100 apples for $50 is implicitly for $50 or more. An attempt to buy $50 for 100 apples would buy 50 apples for $50, since an offer to buy $50 for 100 apples is implicitly to buy $50 for 100 apples or less. Or say the only offer on the books is to buy 10 apples for $10. An attempt to sell 100 apples for $50 would cross that offer, selling 10 apples for $10, and still have 90 apples left to sell for $45. An attempt to buy $50 for 100 apples would cross that offer, buying $10 for 10 apple, and still have $40 left to buy for 80 apples. Both attempts would place an offer on the books at the same rate, but one would be 90 apples for $45 and the other would be 80 apples for $40.
  2. We are still investigating why fewer transactions than expected are making it through the fee queue to the validated ledgers on the live network. You can run your own rippled server and see that they're not even remotely close to overloaded executing transactions. The transactions aren't passing one of the gates that control the flow of transactions through the consensus process into the final, closed ledgers.
  3. You'd have to generate about a million, billion, billion keys to have a 50% chance of even finding two keys that collide. That means if you had a million computers each of which able to try 10 million keys per second, you might find a collision in a few thousand years. Now remember, that's just finding two of your own keys that collide. Trying to find a collision for someone else's key is much more difficult. Say at some point there were a billion keys that secured enough funds to be worth stealing. You'd then need to generate about a thousand, billion, billion, billion, billion keys to have a 50% chance of finding a collision for a key with enough funds to be worth stealing. If you had a billion computers each able to test 10 billion keys per second, you'd still need over a million years. You might as well worry about getting attacked by a polar bear and a regular bear at the same time while you both win the lottery and are struck by lightning.
  4. Thank you, jn_r. We'll figure out what's going on.
  5. For those of you who find you are paying high fees, can you explain what method you use to choose what fee to pay? Are you just paying the open ledger fee with a cap?
  6. It's not a configured property, it's an emergent property. The current algorithm is not very well tested under real load and we'll probably have to continue to work on it. Fortunately, there is no problem with different servers using different variations of the algorithm -- it will not effect the system's security and usability properties so long as most servers have a sane path to most validators. To date, the behavior has been too complex to simulate and getting a robust, stable fee market to emerge from a decentralized system is still an unsolved problem. You can always pay enough to get an important transaction in quickly. But that's not the same as smooth, predictable behavior for varying fee levels correlating to varying service levels.
  7. There is a fixed minimum fee which is 10 drops (a drop is one millionth of an XRP) for most transactions. If there are more transactions than the network can accommodate at its current safe rate, transactions are queued in fee order. It does appear that something odd happened here.
  8. Google's search engine didn't become the de facto search by the masses before the Internet was built. I agree with your middle sentence. Obviously, I'd love to see a higher value, but current value is probably almost entirely speculative, as (at least, I believe) it is for pretty much every digital asset today. If that makes XRP a scam, then pretty much every digital asset is a scam. Ripple has explained, as have I many times, precisely why we think there will be an intermediary asset, why we think it will be a digital asset rather than digitized fiat, why XRP has a good chance of being that asset, how Ripple plans to keep XRP positioned to be that asset, and why that could be expected to increase demand for XRP. It's certainly fair to argue against any component of that or to make arguments about how likely Ripple is to succeed at that. But is that what's happening here?
  9. I don't think anyone can say right now. It may be that Ripple closes its doors and has no more reason to exist. It may that Ripple finds other revenue models inside the new payment ecosystem. It is interesting to note that as Ripple owns less and less XRP (which we expect) and possibly finds other revenue models (which may or may not happen), Ripple's interests will gradually diverge from that of XRP users and holders.
  10. Google is a scam because their search engine is not necessary for the Internet to work. Well, umm, yeah. Google works to build, preserve, protect and promote the Internet, even though the Internet works just fine without Google, because without the Internet, there's no market for a search engine. So why does Google even bother with a search engine? Because that's where their revenue comes from. Similarly, Ripple's payment network and things like ILP and the "Internet of value" are not major direct revenue sources for Ripple. But without them, there's no need for XRP. Ripple promotes its payment network and ILP and a universal way to make payments to create a market for XRP. XRP is, we hope, the major revenue source. This isn't a secret, it's the strategy. In order to say something like "XRP is a scam because it's not necessary for Ripple to work" you'd have to think that Twitter should be building its own network that requires you to use Twitter rather than promoting and growing the Internet. It's incredibly short-sighted, small-minded thinking.
  11. Doing so would be a provable protocol violation. In bitcoin, miners explicitly have complete freedom to choose which transactions to include in a block. This is not the case in Ripple. Deterministic rules control what transactions a validator includes in its consensus set and failure to follow these rules is a provable, protocol violation. (There are still a few weird legacy exceptions to this rule still in the code back from before it was implemented, such as validators being permitted to impose a local limit on the number of paths in a payment so long as the limit is the same for every payment.) I will not claim that Ripple's solution to this problem is perfect. But it does have several significant advantages over bitcoin's solution: 1) There are deterministic rules for which transactions to include. That is, we know what's supposed to happen and what's not supposed to happen and can tell which. 2) Validators sign their proposals. If someone is not following these rules or attempting to censor transactions, we know it. Even if the validator is pseudonymous (which we might want for various reasons) we still know which identity is the bad actor and can stop listening to them. 3) Users are free to change validators and, if validators are breaking the protocol rules, I would expect that they would do so. Users are not held hostage by miners or the need to incentivize sufficient proof of work to keep the chain secure. If validators do bad things, users can instantly pull the plug. 4) Unless the system as a whole is broken, there are no short periods of unfairness. The system as a whole decides the contents of each ledger, not a randomly selected dictator of the moment. That said, bitcoin's solution seems to work well enough. So it's hard to argue that a better solution isn't good enough.
  12. So the interesting question is -- what do you need the link encryption for anyway? If all the data is signed, and servers only trust data they can independently verify no matter where they get it from, why do the links need to be encrypted at all? Well, one answer is that it's very easy to do, has no downside, and does increase your resistance to some types of attacks. But there is one reason you actually need it: Suppose server A connects to server B. And suppose that also server B happens to connect to server A. This might happen because server A has a list of IP addresses to connect to and server B has a list of IP addresses to connect to and they might wind up with two connections. (This is particularly likely if a server has more than one IP address.) Without some kind of link-level security, we now have a problem. One of the two links is worthless and redundant. But if server A drops its link, then it is trusting that its other link really is to server B (which it would have no secure way of knowing). And if server B drops its link to server A, it would not be sure it was connected to server A at all because it would have no way to authenticate the inbound connection. So you have two painful choices: 1) Keep redundant links between servers, just to be safe. 2) Allow an attack vector where an attacker might be able to convince A that it's connected to B when it's really connected to the attacker and vice-versa and then there would be no connection at all between A and B and they wouldn't know it. Link-level security solves this problem. Typically, a rippled server has no idea what the identities of the servers it talks to actually mean. But they do allow it to know reliably whether two connections are to the same server, regardless of who initiated each connection. They prevent attackers from making servers think good connections are redundant and prevent attackers from selectively editing communications between servers. A man-in-the-middle cannot convince two servers that they have ends of the same connection unless they actually do, and if they do have ends of the same connection, the MITM cannot understand or modify the data. The only thing he can do is slow or drop the data, which of course anyone with control over a network path can always do. IMO, the network would still be quite secure without it. But it's a nice extra layer of security.
  13. You can summarize the rules as "able to claim a transaction fee", but that really just prompts someone to re-ask the question -- what is required for a transaction to be able to claim a transaction fee? And, as Nik said, they come down to a long list of rules. The rules are in the code, particularly in the "preclaim" and "preflight" functions that determine whether a transaction is rejected or executed: First are universal checks: fee, signature and sequence. The fee must be sufficient, the account must be able to pay the fee, and so on. https://github.com/ripple/rippled/blob/fc640504ba90ef4323f8e845e8c264b81e2054b5/src/ripple/app/tx/impl/applySteps.cpp#L67-L101 Second are transaction-specific checks. Generally speaking, they make sure the transaction doesn't have illegal amounts, options, or combinations of options. For example, for payments: https://github.com/ripple/rippled/blob/fc640504ba90ef4323f8e845e8c264b81e2054b5/src/ripple/app/tx/impl/Payment.cpp#L47-L202 There is a few odd edge cases. For example, say a transaction specifies a fee that is sufficient but the account doesn't have enough XRP to pay the fee but does have some XRP. In this case, the transaction is invalid unless it's already accepted into the consensus set, in which case it executes but only empties the account's XRP to zero. This handles a case where an account had enough XRP to pay the fee when the transaction was received but before the transaction got accepted into the consensus set and executed "for real", some other transaction deprived the account of the funds to pay the transaction fee (say by taking an offer that account placed). A key goal of the design is to ensure that transactions are not relayed unless they are very likely to claim a fee such that you can't make the network relay unbounded transactions without paying unbounded fees.
  14. Let me start by saying that I think that the risk of routing attacks is somewhat overblown. All you need is one remaining path between the two halves somewhere and the attack will fail. If both halves are of any significant size, it's almost impossible to ensure that there will be no path between the two halves. There are VPNs and multihomed hosts all over the place. Ripple also uses an overlay/broadcast network to relay transactions. But I don't think we're really all that worried about a denial of service attack but much more about an attack that can actually result in forks or double spends. Let's imagine such an attack against bitcoin. Say we accept large payments after 4 confirmations. And say someone can split the mining power in half. Four confirmations would be expected to take 80 minutes with half the hashing power. So someone would have to maintain a 50/50 hash power split for over an hour to get a double spend. That's possible and worth improving, but I wouldn't stay awake worrying about it. Ripple is better defended against this kind of attack because you know which validators you are getting validations from. If you're only seeing 50% of the validations, you won't ever fully-validate a ledger. However, Ripple has to be, because without such defenses, a mere 10 second split could lead to a double spend. 10 second splits are not that uncommon as routers get rebooted, links fail, or ordinary Internet noise happens. You could easily imagine importing some of Ripple's protections into bitcoin. For example, mining pools could publish what block they're building on top of through a web-based service. If you could confirm that, say, about 80% of the network's hashing power was building on top of a block that held a transaction, you could accept it with fewer confirmations and maintain equal safety.
  15. So they claim that they're sharing revenue from something other than token sales. The question is -- is there evidence of this? Because the obvious thing to worry about is that they're actually sharing revenue from the token sales. If they're sharing revenue from the token sale to prop up the value of the token under the guise of sharing real revenue from some other source, that's a scam.
  16. Banks that are part of RippleNet are buying software from Ripple to process live transactions. Ripple is signing contracts with the transaction processing folks at these banks and getting our software in the datacenters that process their international payments. At the same time, the innovation folks at many banks are experimenting with and investigating all kinds of future technologies. There's a huge difference between "we think this is interesting and are experimenting with it" and "we bought this and are integrating it into our payment flows".
  17. That's kind of a terrifying sign. Do we have any solid evidence that they actually have any significant revenue other than people buying their token?
  18. The orders are taken starting with the one that provides the best quality (most output per unit of input). When that offer is completely consumed or becomes unfunded, we repeat the algorithm again choosing whatever provides the best quality. Computing the quality of a bridged order book is as simple as multiplying the tip quality of the two order books. So if the BTC->EUR order book is 3,000 EUR per BTC, the BTC->XRP order book is 16,000 XRP per BTC and XRP->EUR is 1/5 of a EUR per XRP, the synthetic BTC->XRP->EUR quality is 16,000 times 1/5 or 3,200. Since 3,200 is greater than 3,000, the autobridged path would be preferred until the order book was bought down to a synthetic quality of 3,000 or less and then the direct path would be taken. The two paths can alternate if the payment or crossing offer is large enough.
  19. This is no different from what banks do today and the settlement amongst themselves takes days. Banks have not been willing to loan people money to cover the settlement time at no cost. I don't see why or how calling it a coin or putting it on a blockchain changes anything. Also, what's the revenue model? Tokens pegged to fiat can't appreciate in value. So if their plan is to charge their customers for the liquidity or make their customers provide it at their own expense and ours is to fund it from the appreciation of the value of the token, I don't see how they can win. They'll say to a bank, "spend millions to build liquidity to and from our token" and we'll say, "we'll pay you (or others) to provide liquidity". In what world do they win? If they have something new or revolutionary, we haven't seen it yet.
  20. And yet nobody has ever explained how these internal clearing tokens will work. If I receive a payment and my bank has one of these internal clearing tokens, what does my bank do with the token if I want to make a conventional, domestic payment? Payment already is effectively by internal clearing tokens with settlement requiring correspondent banks and several days. What seems a pipe dream is thinking that doing the very same thing on a blockchain that's still a walled garden will fundamentally change anything. If they have a clever, new idea, they haven't shared it yet. What are you imagining? That Ripple suddenly finds an entirely new multi-billion dollar business out of nowhere? Ripple's XRP has a notional value of something like $10 billion. Ripple doesn't have anything else that comes anywhere close to that. If XRP goes up by a penny, Ripple has a potential profit in the hundreds of millions of dollars. I don't see how you think Ripple could sell payment software on that kind of scale.
  21. I can't speak to UBS and Santander about this specific issue. But I can say that banks have innovation groups that experiment with all kinds of things. Those are almost never the people that Ripple is engaging with. We're usually talking to the people who handle their actual transaction processing. As for this project overall, keep in mind that the details of doing something like this are very tricky. If this is going to be an open, decentralized token, then it could compete directly with XRP. If this is just going to be a walled garden, then great. we can target bridging it to other walled gardens with XRP.
  22. If it's not an open system, I don't see how it's any different from what we already have. There's absolutely no explanation for how the conversion between this token and fiat at a bank will be accomplished or who will pay for it. Banks could fund their customer's payments today and then they wouldn't need nostro accounts. They don't because they don't want to pay for providing their customers' liquidity. What about this would be expected to change that? At least from what's publicly disclosed, this seems to be based on the assumption that just adding blockchain to an existing system somehow makes it better. But if it's not decentralized and open, the blockchain is just extra cost and effort.
  23. The complicated issue is with the destination asset. Say, for example, you're looking at BTC->EUR. There are three order books involved, the direct path is the BTC->EUR order book. The bridged path is BTC->XRP then XRP->EUR. The complication occurs in that both the BTC->EUR and the XRP->EUR order books require the account that places the offer to supply EUR. To properly figure out the funding levels of a bridged order book, you have to track the amount of XRP and the amount of the destination asset as you traverse the order books in tandem. It's a pain.
  24. 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.
  • Create New...