Jump to content

JoelKatz

Ripple Employee
  • Content Count

    883
  • Joined

  • Last visited

  • Days Won

    82

Everything posted by JoelKatz

  1. I think it's been changing and it's different things for different banks. Right now, there is a lot less resistance from FIs than you might think and it's going to come down to us being able to put together a package of products and services that works for them. We're finally at the point where we are starting to do that with XRP.
  2. Fortunately, it's not nearly as hard as you might think. The payment looks like this: 1) Originator 2) Originating FI 3) Exchange that does the "to XRP" part 4) Exchange that does the "from XRP" part 5) Destination FI 6) Recipient 1, 2, and 3 are already in the same region. So there are no issues with them doing business with each other. 4, 5, and 6 are already in the same region. So, again, no issues there. 2 and 5 already know how to put together a compliant payment flow that crosses the two regulatory regions. They already ensure that 1, 2, 5, and 6 meet the regulatory requirements for both regions. So no issues here either. 3 knows that 2 is compliant with the regulations in its region. 3 knows who is receiving the fiat and who is supplying the XRP. 3 knows that 2 has ensured the compliance of 5 and 6. 4 knows who is receiving the XRP and who is supplying the fiat. 4 knows that 5 is compliant with the regulations for its region and has already ensured the compliance of 1 and 2. This leaves shockingly few regulatory issues left. It turns out not to be nearly as difficult as you might imagine.
  3. I bet that there are people checking the balance in our storage accounts constantly and the second those balances drop significantly, they'll dig out the transactions and write about it everywhere.
  4. I thought so too, but looking at bitcoin, I'm becoming more and more confident that no incentive is necessary. One might be necessary in the short term just because XRP hasn't reached the mass bitcoin has. But I'm pretty confident one isn't needed in the long term. Now, I know what you're thinking, how could I have learned this from bitcoin -- bitcoin incentivizes miners with bitcoins. But think about it. Is bitcoin governance 100% in the hands of miners? Are they even the best agents in the space? Users, developers, exchanges, wallet providers, and many other groups are participating in bitcoin governance too. And they don't get any special incentives. In fact, you could argue that the incentives provided to miners is a negative and makes community governance more difficult as the incentives become more and more misaligned. So if people even go to the trouble to stand up to miners and push against their tremendous financial incentives without any special incentive, why should people need a special incentive to do the cheaper, simpler task of just running a damn validator?
  5. Say you need to prove to me that your credentials are correct. You do it by giving me the 6 digit code. At the same time, I claim to be you. When asked for the six-digit code, I give the code you gave me. The code, of course, checks out. So why is your key fob useful despite that trivial vulnerability? Because there is one, and only one, central authority that verifies that six digit code. But, of course, we're designing systems that don't have central authorities. So we need a scheme that provides a verification that cannot be separated from the data it verifies and can be confirmed by any number of third parties that you don't trust.
  6. Right now, we don't have a good quantum-resistant digital signature algorithm that's suitable for our use case. We could pick the least awful of the existing ones, but we'd be sacrificing a lot to get quantum resistance. And once we add an algorithm, we're pretty much stuck with it forever as removing it would lock people who were using it out of their accounts. So we'd prefer to wait as long as we safely can or until a new quantum-resistant digital signature algorithm is released that works well for our case. If anyone knows of any quantum-resistant digital signature algorithms that they think would be suitable, please feel free to let me know. We care about signature verification time, signature size, public key size (unless the public key can be reliably derived from the signature), and reusability (same key must be safe to use for many signatures).
  7. I would argue that you should store private information that only you care about in a database, not on a public ledger. But you could use the 8 least significant bits in the Expiration for this purpose. Presumably, you don't care about precisely when your offers expire.
  8. I don't agree. Laws are clubs, not scalpels. Trying to enforce truly de minimis violations of laws just erodes respect for the law. And given how bad and complex some laws are, this kind of enforcement (if universal) would lead to a dystopian society. It would also frustrate the specific object of the laws. Imagine, for example, if everyone who sped was pulled over and ticketed. How could you drive safely in a 60 zone without either driving much less than 60 or spending half your time staring at your speedometer? Enforcing every law violation would lead to disaster. See articles like this one: https://mic.com/articles/86797/8-ways-we-regularly-commit-felonies-without-realizing-it Perhaps you're imagining some utopia where every law is a good law and everyone is familiar with all the laws they are likely to violate. But that's not the world we live in by a long stretch.
  9. The sequence number of the transaction that created the offer is encoded in the ledger in the offer object. Here's what an offer object looks like on the ledger: Notice the "Sequence" field. That's the sequence of the transaction that created the offer. Also, encoded into the "BookDirectory" (last 64 bits) is the rate at which the offer was placed. You can retrieve these with the "ledger_entry" RPC command. You can specify an "offer" object with an "account" and "seq".
  10. Why use a memo for this? If this is solely for your own internal use, why not just use a database?
  11. You can expect Ripple to aggressively defend its trademark "Ripple". Also, I have a huge problem with sites that insist I disable my security to access them. And make no mistake, AdBlockers are security software. Unless you're going to police your ads to ensure that they don't serve me malware (or pretend to be part of your site), and take responsibility if you fail, don't ask your site visitors to shut off their security to use your site. http://www.latimes.com/business/la-fi-equifax-social-security-numbers-20171012-story.html
  12. I don't think XRP is particularly vulnerable to these kinds of threats. XRP is just so far ahead of every other asset except a few major ones, and those major ones are too diffusely held for anyone to have an incentive to promote them for this use case. Someone trying to target Bitcoin or Ethereum at this use case would have no revenue model. Someone trying to do this with a minor asset would have a long way to go just to catch up to where XRP and Ripple are now.
  13. I have no idea if this letter is authentic or not, but I do think I know what it means. What it's saying is that either Gatehub notified the UK Registrar that it was no longer doing business or (much more likely) failed to respond to two notices from the registrar. I don't think these notices are routine and I think they're typically sent if the registrar has some reason to think the company is no longer doing business. If I had to guess what the most likely meaning of this is, I'd guess that that Gatehub is closing a company called "GATEHUB LIMITED" and is doing business under a different entity. I believe this particular process process (the 1000(3) process referred to in the letter) is only used for companies that have stopped operating.
  14. I don't think that's a threat to XRP's use case. Ripple is trying to position XRP as an open, jurisdictionless asset that can bridge different currencies. If these assets are pegged to some country's fiat, I don't think they threaten this use case. Where they might be a threat is if they introduced an asset that behaved like XRP and targeted a similar use case. Every enterprise is vulnerable to someone else who tries to do the exact same thing but somehow manages to do it better. That is, of course, much easier said than done. I don't think that being a government or bank would be as asset here though because that would make it harder to position your asset as universal. If individual regions do make their own currencies flow more quickly and easily, that could be a benefit to Ripple. Fast payments and fast domestic settlement all help drive demand and provide the infrastructure for international settlement.
  15. You didn't specify "build_path" and you didn't specify any paths. So the transaction was submitted with no paths. A USD payment with no paths will only work if the recipient accepts USD issued by the sender or the sender owes USD to the recipient. No intermediaries, such as gateways, will be used since there would be no way to know which gateways to use. But there's another problem. The recipient you're trying to send to doesn't accept any USD as far as I can tell. The network has no idea what USD is (remember, no central authority), so unless you're trying to send USD to someone who has told the network something they consider to be USD, there is no way to pay them USD. The network won't take your word for it, only the recipient's word will do. (Otherwise you could pay someone worthless junk and claim it was USD. Then what are they supposed to do with the useless junk?) Also, if you don't specify a maximum amount to send, the payment will only work if it costs the exact face amount or less. Since the sender doesn't hold any USD of any kind, that's also an obstacle. You can pay using a different asset (such as XRP) assuming there's sufficient liquidity. But your payment is too simple to allow that. For payments other than XRP-to-XRP or direct issue/redeem transfers, it's strongly recommended to use a two-step process. First, use "path_find" to find paths. Then submit a payment based on the paths you were offered.
  16. I clarified with Santander. They were discussing the usefulness of Ripple by analogy with a telephone. The first telephone is useless. Once there is a second telephone, the first is useful. By analogy, when they were launching their pilot, Ripple didn't have enough bank adoption to be useful enough to them. So EarthPort was their second telephone. Endpoints have been added to RIpple since then, of course, and continue to be added. For us, and for them, the EarthPort partnership was extremely valuable as it allowed them to get the benefit of Ripple to many endpoints without banks at those endpoints having to adopt Ripple directly.
  17. Also, keep in mind what I said about the difference between the innovation folks and the transaction processing folks. Typically, the people at a bank that we're working with are the people in the actual banking operation processing live transactions. The innovation people are usually in a completely different part of the organization and their mission typically involves experimenting with all kinds of new technology.
  18. When you stop trusting an exchange, it is imperative that you tell Ripple this. Turning off Rippling alone is not sufficient -- you need to drop the trust amount to zero.
  19. Is there some place that I can find the context? They might be saying that Ripple was so good that they were willing to use it even though they had to use Earthport for the last mile due to a lack of adoption of Ripple by banks. And thus as Ripple is adopted more widely, it will become even more useful as they can substitute direct paths for Earthport. I've heard this sentiment expressed before. But I can't tell if that's what they're saying here. It absolutely true that the value proposition of Ripple to banks depends on the number of banks that have adopted Ripple.
  20. The idea that something becomes valuable just because it's difficult or expensive to make is just bogus. What gives something value is simply two things: 1) Demand. The more, the more it's worth. 2) Supply. The more, the less it's worth. We're used to things whose difficulty of creation affects the supply. But this is not the case with bitcoin. The supply of bitcoin is wholly determined by the agreed consensus rules.
  21. Is that really how non-profits are supposed to work? And who knows who holds lumens, beyond what the SDF holds.
  22. Almost every company is vulnerable to someone else who attempts to do exactly what they're doing and manages to do it better. This is much easier said than done.
  23. If it makes you feel better, just think about "megaXRP". Only 100,000 MXRP will ever exist and each one is worth about $202,000 today. Take that, bitcoin!
  24. There is one other possibility I can think of. I don't know how likely it is, but it is possible. Someone might have an agreement that's keyed to the price of a particular asset at a particular exchange at a particular time. In that case, they may be able to game that agreement by manipulating the price at that particular place and time. It would have to be a pretty big, and pretty dumb, agreement to be worth gaming. But it could be the case.
×
×
  • Create New...