Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JoelKatz

  1. There are probably a lot of factors at play. One of them is that there are a lot of transactions that seem, at least to me, to be basically junk. With transaction fees so low, there's no real disincentive to submit lots of junk transactions, and people do. The legitimate volume is somewhat lost in that junk. To get more useful numbers, you can limit yourself to just Payment transactions or OfferCreate transactions that crossed other offers. And then you can filter out Payment transactions that just seem to be moving assets for no particular reason (we used to see a lot of those, but not so much anymore). Our XRP Charts site and XRP site has metrics like that, and they're probably more useful than raw transaction volume.
  2. And, to be clear, this is what xRapid does today. There are lots of obvious, and not so obvious, other ways you can do this. And different ways of using XRP liquidity to settle payments is high on our priority list. This is the first working scheme.
  3. So the blockchain just improves security. And it's faster and cheaper because ....?
  4. Off-ledger trading is the majority of trading today. I think the largest on-ledger XRP market is XRP to USD/Bitstamp and it's the 41th largest XRP market.
  5. This kind of question comes from the thinking that blockchains are magic and that if you just add them to things they get better. I think there are a lot of banks and related organizations madly trying to figure out where they're suppose to stick the blockchain to make things better.
  6. Nope. As you buy up more and more XRP, the price goes up. So you have to spend more and more money to do it, making everyone else who holds XRP richer and richer. It just isn't a realistic attack.
  7. I agree with you. Unfortunately, I don't know the exact details of how the transactions are timed or how the spreads are computed. The third party market makers we've employed understand that we don't want to kill rallies or engineer the price and that our desire is to choose sale targets and approximately reach them having as little effect on the price as possible. To prevent me from gaming the system either for personal benefit or to benefit Ripple, or inadvertently giving others the ability to do so, I am not given access to any details. Every suggestion I've made to them got back "we're already doing that", so I think they know what they're doing. They might adjust it to a long term median. They might back off when volume is above normal. Those things I don't know.
  8. Unfortunately, that blocks offline account creation flows. Since you don't know the starting sequence number for the account, you can't compose the transactions to configure it. That might not be fatal, but it is disruptive. But having your light account turn into a regular account after you wiped it out might be disruptive too.
  9. I guess it depends on the rules we decide to go with. If the rule is that sending less than 20 XRP automatically creates a light account, then it would succeed. That's probably what we'll do, so it won't fail. But if the account was removed and 20 or more XRP is sent, then a regular account will be created and 20 XRP will be locked as the reserve. That might annoy people. We could change it so that the Payment transaction always creates a light account by default. The account owner can promote it to heavy account if they wish. But we'd need a way to create a regular account with a Payment transaction because otherwise, existing flows for offline account creation will break. (Because you don't know the new account's starting sequence number and so can't prepare transactions offline.)
  10. Yes, that's right. However, there are still issues with funding the account after it's been removed. For example, suppose you know that an account once existed and you try to send 1 XRP to it. If it was a light account that was removed, that will fail. Say you know that an account once existed and you send 20 XRP to it. If it was a light account that was removed, you'll create a regular account. So it's not perfect. Our recommendation will be not to remove a light account unless you're relatively certain no more funds will be sent to it. We thought about making a distinction between account types, but the problem with that is that all tools would have to change for light accounts to work properly. Everyone would have to understand the new account format.
  11. Yes, that's my point. Of course it's great that Mexicans like XRP. But to the extent that's true, that makes the price/volume anomaly of XRP on Bitso less likely to be due to xRapid and/or Cuallix. This is the problem with making an inference from only one data point.
  12. Not without an awful lot of work. We'd need some way to reliably ensure that they weren't referenced anywhere in the ledger and many complex code paths would have to be audited. It's not impossible, but adding it to the initial design would make it much less likely that the the change would actually happen. If the light account proposal is adopted, it could happen that over time it gets expanded. Already, with the proposal as is, all ledger users will have to be careful that their code doesn't make the assumption that an account they saw on the ledger, sent XRP to, and received XRP from will necessarily always be there.
  13. A light account is guaranteed not to have any owned objects and hence no owner directory. As a result, it can have a lower reserve. A regular account can't be completely deleted because other people might have created trust lines to it and because that's needed to protect against transaction replay. Light accounts can have any trust lines created to them and they use a different mechanism to prevent transaction replay. Trust lines just increase the account's reserve by 5 XRP. They only charge the side that puts the line into a non-default state (unless both do). A gateway can easily have an owner count of zero because it doesn't have to put any trust lines into a non-default state! The 20 XRP base reserve covers things like the owner directory and costs associated with attaching offers. A light account can be promoted to a regular account at any time. The idea of the light account proposal is to allow people to have their own accounts on the ledger and send and receive XRP without losing 20 XRP they can never get back.
  14. Say I had USD and I wanted to send someone MXN and I had an account on Kraken and they had an account on Bitso. I could deposit USD on Kraken, trade it for XRP, send the XRP to the recipient's Bitso account, the recipient could convert the XRP to MXN, and then the recipient could withdraw it. Sourcing liquidity works exactly like that, except the recipient doesn't need an account at Bitso because Bitso would convert the XRP to MXN and make a conventional domestic payment to them automatically and the whole thing would be coordinated as a single transaction that either fully succeeds or never moves any funds at all.
  15. We're trying as hard as we can, and we've had some success. But the future is never certain. Also, to address the question about delivering payment to end users, the point of products like xRapid is to connect XRP payments to traditional payment endpoints. Say Amazon wants to pay a vendor. Amazon would deliver XRP to a market maker, and the market maker would transfer funds directly to the end recipient. The XRP and fiat movements would be made atomic at least up to the domestic payment system used to pay the recipient. If the recipient's bank account is at a bank that supports RippleNet, it can be atomic and instantaneous all the way to the recipient. We do have some work to do to make all these pieces work seamlessly together, especially in some of the more complex cases where multiple institutions are involved. We're prioritizing based largely on what will get us the most volume the most quickly.
  16. It could have been someone's attempt to flood the ledger. There also could have been some kind of momentary disruption that caused transactions to back up and then they cleared all at once. But most likely, I agree that it was probably a glitch in the monitoring.
  17. This has a kind of "surely there must be some way we can use a blockchain to do something" feel to it.
  18. I find that my TA is nearly 100% accurate when I can see both to the left and to the right of the forecast time. But when you try to tell whether or not there's consolidation without knowing whether it was followed by a rise or a fall ... I never seem to be able to do it.
  19. The theory is that people are taking profit (if this is after a rise) or cutting losses (if this is after a drop) are keeping the price from rising while bargain hunters are keeping it from falling. If this is after a rise, the average holder's buy price is going up, likely reducing selling and setting up for the next rise. If this is after a drop, the average holder's buy price is probably going down. But then a lot of people think all this analysis is pseudo-science.
  20. We all know that eventually the world will be taken over by cryptocurrencies. But, today, for some reason that nobody has ever been able to figure out, there's still a multi-trillion dollar market for legacy fiat currencies. So it doesn't make sense to ignore them just yet. Companies like Western Union and MoneyGram have the ability to take in and pay out cash all over the world and it will be a long time before that stops mattering. Imagine you're a company that has 5,000 cash in and cash out locations around the globe. But no matter how many cash locations you have in the United States, if you aren't in Mexico, you can't capture any USD/MXN business. With XRP as an intermediary, it becomes unbundled. If you have a cash in location in the US and someone, even if one of your competitors, has a cash out location in Mexico, you can get that business. So this can significantly increase the value of these cash in / cash out networks. And that would also mean that someone doing a USD/MXN remittance doesn't have to be the party that actually converts USD to MXN. Maybe they don't get good conversion rates and somebody else does. Maybe somebody has a counter flow because they own a grocery store in Mexico and live in the US. With a system connected to an open network, you can take advantage. This is exactly what the Internet did for information. I can use AT&T to reach Gmail and you can use Comcast to reach Apple's iCloud, and we can email each other.
  21. We've thought about offering such hedges ourselves. We already have effectively infinite exposure, so a little more wouldn't hurt us and it could even be a small source of revenue. We've also talked to partners about forming their own entity with the same ownership but not technically a bank. That entity can hold their XRP or hedge it. This is especially helpful for FIs whose transaction banking portions can't own speculative assets. It can always be structured so the entity that holds the XRP can be expected to make a profit. However, if XRP is too volatile, that can result in the transaction banking entity not finding XRP competitive. So low holding cost is important to targeting higher volume corridors.
  22. Did anyone who updated to the new version but didn't change the way their validator list works see problems? I wonder if it's due to the validator list change or something else in the new release.
  23. I don't want to see what happens if Ripple is pressured to do evil things. I would hope that organizations like exchanges would simply stop following us and XRP would survive and I expect that this would happen. But I'd like to be quite confident that this will happen, and I think our 2018 decentralization roadmap will get us to that point. You're correct that this biggest threat would be the amendment process. The code already imposes a two week minimum delay between when an amendment is deployed and when it is activated. During this time period, exchanges (and other participants) have to upgrade their software with software that includes the amendment. This ensures at least a reasonable time period for the public to inspect the new rippled code and, I would hope, advise exchanges and other participants *not* to adopt code that supports the amendment. This could even be enough time to choose new validators given that everyone who currently runs rippled can turn their server into a validator just by issuing a single command. Some community coordination would be necessary do this, just as it was when bitcoin had to do a similar thing and manually choose one of two competing histories. I hope the community around XRP is robust enough to accomplish this, but obviously I'd prefer a situation where Ripple can blow up and XRP continues without even a glitch. There are two reasons I prefer this: 1) It completely takes the "you have to trust Ripple" argument off the table. 2) If it wouldn't work anyway, there's no incentive to try to corrupt Ripple. I also think it's important to point out that currently there is no code in rippled to reverse a payment, prevent a payment, or freeze XRP. Ripple has no intentions of ever adding any such code, and I would hope that if we did, exchanges and others would refuse to run it.
  24. I agree that it looks like the video is real in the sense that it hasn't been edited or faked with camera tricks. However, the big question is whether the code that generated the displays we are seeing is real Coinbase code or someone else's fake/modified version. Also, someone asked about "confirmations" with XRP. You could track which ledger a transaction completed in and consider the number of ledgers that are fully-validated at or after that point as a confirmation count. I could see why someone might do this to provide a number that bitcoin people are used to, and even though one confirmation is enough, it would get to six within a minute anyway and make bitcoiners feel at home.
  • Create New...