Jump to content

JoelKatz

Ripple Employee
  • Content Count

    883
  • Joined

  • Last visited

  • Days Won

    82

Everything posted by JoelKatz

  1. I have no idea if this is authentic or not, but I did notice one thing. One of the transactions had a memo that decodes to: {"id":"1941caa0-1650-4c92-9867-18439ef6a42a","sig":"f5b8f1958b010cafe1287842b216d3c4ee3779ef26b07b9b4b48090acb4be335"} That ID is in a similar format to Coinbase's transaction IDs. For example, I have a Coinbase transaction whose ID is: 868XXXbd-55XX-XX19-a0XX-86e7XXXX46d5 The X's are hex digits I anonymized. That said, this looks like a GUID, so maybe other companies use this format too.
  2. I said that a particular valuation method would cap XRP at roughly $20. But I then went on to explain why that valuation method could miss two types of value: 1) Value that comes from use cases other than bridging payments. 2) Value that comes from capturing payments that don't currently exist because there's too much friction for them to be possible today. But I realized later that I actually missed the biggest thing that valuation method missed -- value that comes from demand for XRP as a payment funding source. If XRP bridges lots of payments and holding cost is low (two big ifs, of course) then it makes sense for companies to acquire XRP at below market price by providing it to others who need it to bridge a payment and then holding it until they need to make a payment and using the XRP to save them to cost of the "from XRP" half of their payment. If that materializes, it could provide value to XRP that's difficult to calculate but potentially siginficant.
  3. Me too! I was stunned that it made sense in a corridor that I would have assumed was fairly high volume and liquid. Part of it is that the volatility works in your favor as often as it works against you.
  4. What they care about is holding cost, not really volatility directly. So long as the upside exceeds the downside, the holding cost can be low or even negative. Banks don't actually have to hold XRP. They can use market makers who hold XRP and market makers can actually profit from volatility. In the short to medium term, it doesn't matter all that much. We're going to be choosing corridors that are so inefficient that XRP holding cost won't be a significant factor. But over time, as we try to tackle larger and more efficient corridors, lower holding cost will make XRP more attractive.
  5. Korean exchanges tend to have higher prices due to liquidity issues with KRW. If you click on the price on coinmarketcap, it will break it down by exchange.
  6. You don't have to. You can go to secondary markets like EquityZen and SharesPost at any time. People who want to sell stock also go to these secondary markets and they bring buyers and sellers together. They also take high commissions.
  7. If the price falls, some people will stop mining because the bitcoin they make won't pay for the power. This will (eventually) cause the difficulty to drop which will return the block time to normal. However, it can take a long time to mine enough blocks for the difficulty to drop.
  8. Unfortunately, you can't do that. To form a group specifically to buy an unlisted security, every equity holder in that group must be an accredited investor. https://www.sec.gov/files/ib_accreditedinvestors.pdf
  9. If you want to pick one or two questions, I'd be happy to answer them here. I did see a list of possible questions ahead of time, but there was no rehearsal, nor did I run my answers by anyone else. I also played no part in choosing which questions to answer. I believe the questions were chosen based on what we felt would be effective for that forum and what was on the most people's minds. But I'm pretty much always running a continuous AMA everywhere I post. And by p2p loans, I did mean personal. Have a look at my pinned Tweet:
  10. I also think he's wrong about how important liquidity is. There are so many corridors that are so inefficient that there's a huge space to dominate before even the existing liquidity becomes insufficient. He concedes that we can spend money to build liquidity but he worries that that will eventually run out. Well nobody's spending money to build bitcoin liquidity and yet it's growing. How does he explain that? You know what really creates liquidity? Demand for liquidity.
  11. There are a few technical errors, but I think the key thing is to look at his thesis. He seems to concede that Ripple is building a better payments system that banks will use. That will mean huge volumes of payments on the network. And he doesn't see any technical obstacles to XRP being used as an intermediary asset. Nevertheless, he's arguing that despite being able to build massive payments volume, having influence over almost every aspect of the system, with a phenomenal team, a warchest with a notional value in the tens of billions, and every incentive to make it happen, we still won't be able to get XRP to be used as a settlement asset. Why? Because it will magically happen for BTC all by itself.
  12. That will do the same thing if no seed is supplied on the command line. You've just removed the ability to specify the seed. I like having that because it enables me to confirm that I've written down a seed correctly by specifying it on the command line and seeing if I get the correct address back.
  13. That line takes the seed from the command line if one was supplied. Otherwise it calls "keypairs.generateSeed" to generate a random seed. The randomness comes from an internal source that is seeded by the system and should be sufficiently secure. If you're truly paranoid, you can modify the script to pass an Array<integer> to generateSeed to be used to help seed the random number generator. I'm not a JS programmer, so I can't help you much more than that. (For incredibly silly reasons, I must point out that I am speaking only for myself here and am not acting on behalf of Ripple.)
  14. We have payment channels that provide support for off chain scaling. We have escrow for atomic swaps. As for the 1,500 transactions per second, we are always working on throughput and performance improvements. We have a lot of cool stuff that we're working on.
  15. I don't know anything at all about that transaction. I haven't even read the article, though I probably will now.
  16. I don't think it's absurd. I think a crash is possible and I always advise people that they are dealing with assets that are volatile and whose value is largely based on speculation and sentiments that can change unpredictably. There are also systemic risks from things like government crackdowns. That said, I don't think anyone can predict a crash with any sort of confidence and most of their so-called predictions are really explanations recast as predictions (or predictions with open time windows), which is not legitimate.
  17. No. The escrow problem was just a defect in the transactions we used and we issued new transactions to fix it. The upgrade to 0.80.2 fixes a different bug having to do with receiving a transaction from a peer that you have already received. A fix for a previous bug that would cause the transaction to be aggressively suppressed caused a chain reaction that resulted in network instability. Rippled uses a structure called the "HashRouter" to track objects it has received from peers. When it receives an object that it needs to share (such as a transaction or a validation) it dispatches it to be checked for validity. While it's being checked, the HashRouter ensures that it's only checked once and also keeps track of any additional peers we receive that same object from. If we do decide to relay it, the HashRouter tells us which peers we have not received it from and relays it to just those. If the object is invalid, we punish the peer that made us dispatch it. If it's valid, we reward the peer that gave it to us first. Duplicates of recent objects are just ignored -- if they're bad, we already punished someone, and if they're good, they just gave them to us late and that's okay. The HashRouter has a five minute entry expiration to keep it from tracking more and more objects as time goes by. This time can be extended if an object is received again. For everything but transactions, this is great. You would never want to process something like a proposal or validation more than once -- it's only useful to the server if it's fresh. Not so for transactions. A transaction may be invalid now but the exact same transaction valid three minutes later, for example, if the account issuing the transaction is created on the ledger. We used to just use the same HashRouter logic for transactions, and this made it hard to "resurrect" a transaction like this. The fix for this problem resulted in a new problem -- excessive dispatching of identical transactions close in time. This not only filled the transaction dispatch queue (resulting in dropped transactions) but, worse, it caused excessive peer punishment for sending invalid transactions. (If we dispatch it and then discover it's a duplicate, we punish the peer because if it's a duplicate and not recent, the peer should not have sent it to us. But it was recent, we just didn't realize it.) Long story short, the fix is to suppress dispatching transactions received from peers if, and only if, they haven't been dispatched in the last ten seconds. The only change (other than to change the version number) is this one. The change information is here: https://github.com/ripple/rippled/commit/fbfb4bd74ecfffcf3d77f28aade0b0fcebeebcbb There are also some tuning changes to improve network stability given the higher volume we've seen recently and a change to reduce resource consumption. There are no changes to any ledger or transaction behavior other than the dispatch change.
  18. If others created escrows intended to be used as time locks that set the release time in the "CancelAfter" field but have no "FinishAfter" or "Condition" field set, they will have the same issue. When I get a chance, I'll search the entire ledger for any such escrows and post a list.
  19. Yes, except I wouldn't call it a backdoor. It's a consequence of the documented behavior of the escrow feature. That's why we replaced them with new escrows that have no way to release XRP early.
  20. During an internal audit immediately following our escrow process, we discovered a defect in the implementation that could cause XRP to be released from escrow prior to the intended release dates. While no funds were at risk, we wanted to correct the defect to ensure the implementation is airtight. We then used the defect on all of the escrows created to release the funds back into Ripple's accounts and then lock them up with new escrows that are not vulnerable to the defect. We are confident that there is no ability to release the escrowed funds prior to the intended release dates. We invite anyone interested to investigate the code, the transactions, and the ledger entries. We published a technical paper describing the lockup process, which you can read here: https://ripple.com/dev-blog/explanation-ripples-xrp-escrow/
  21. They used to return these to sender automatically. But their support should be able to fix it for you .. at least eventually.
  22. 1 and 2 are non-issues for people who know what they're doing. The only thing which, if true, would shake the foundations of these systems is 3. And there's a very, very good reason to think it's not three -- despite the fact that finding such a collision would bring instant fame, nobody has yet produced such a collision. There is no known account for which there are two private keys. Until such time as someone presents such a collision or any good reason to think that they're more likely than we expect, there's absolutely no rational reason to worry about this particular attack. We have a safety factor of several orders of magnitude and we are only relying on a well-documented property of the hashing algorithm.
  23. I don't think you could. But I definitely don't think you could even be taken seriously if you were offering less. I guess it would come down to whether those deals would hold and whether that's really worth the valuation of the company. I think the easy answer is that almost no matter what you imagine, those deals aren't worth what it would take to acquire Ripple. But, wow, if they are, Ripple is seriously undervalued! (Since we also hold XRP with a notional value of over $10 billion.)
  24. You have to remember, the vast majority of Ripple's value comes from the XRP we hold. So any deal that didn't have a central place for XRP just wouldn't make sense. You'd have to imagine some scenario where the combined company could better execute on some XRP strategy than Ripple could alone. Personally, I can't think of one, but that might be due to lack of imagination. If you're not getting the XRP strategy and upside, what are you acquiring Ripple for? The team? The team is great, of course, but since the team could leave if there was a pivot away from XRP, I don't see it being worth the $1.5 billion or more it would take. That said, possible mergers/acquisitions are one of the few things that would be kept very, very quiet. And since I'm not on the Board any more, I wouldn't have any advance notice. So, for all I know, such a deal could be in the works right now.
  25. Sorry to disappoint you guys but we're actually just buying a pizza. Brad Garlinghouse insisted I put a wink on this so everyone would know that i wasn't serious. So.
×
×
  • Create New...