Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


JoelKatz last won the day on December 16 2017

JoelKatz had the most liked content!

About JoelKatz

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Oakland, CA
  • Occupation
    Chief Cryptographer, Ripple
  • Ripple Address

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes, that would be one way to do an intentional fork. The forked off group could then make any code and amendment changes that they wanted.
  2. By the way, if you want to make a wallet into a blackhole, the expected way is to set the regular key to a key that has minimal entropy and then disable the master key. An example of such a regular key would be: rrrrrrrrrrrrrrrrrrrrBZbvji
  3. If you haven't already, you might want to disable pathfinding on your validator. The server does quite a bit of work to maintain some ledger indexes used to find paths for cross-currency payments and validators that don't originate transactions don't need to do this. The config stanza is: [path_search_max] 0
  4. JoelKatz

    Hi! I'm Bob

    I think that any technology can be used for good or evil. Obviously, I would hate to see social credit develop in that direction. I was definitely one of those people who believed that the Internet would inherently democratize the spread of information. Until a few years ago, i was thrilled with the idea that anyone could publish a web page or start a blog and get a huge following if people wanted to hear what they had to say. Seeing the gatekeepers of information lose their power was a wonderful thing. As you all know, in the past decade or so, new gatekeepers emerged with a small number of companies not only having huge control over what information can and cannot be easily shared but also having a revenue model based on gathering massive amounts of information that it has become impractical to keep private. I'd hate to repeat this pattern with the democratizing of the flow of funds and hope we can correct this with the flow of information over the next decade or so.
  5. JoelKatz

    Hi! I'm Bob

    I presume that at least initially, the United States will consider them taxable as either payments or barter (in practice it doesn't matter which) unless they are non-taxable gifts.
  6. JoelKatz

    Hi! I'm Bob

    No, nothing like that. Community credit is about "money" arising from interactions between peers rather than between issuers and users. For example, suppose you do something for me and I allow you to "owe me one". The idea is for this to act as a currency. Someone who wants something from me (and who I don't trust enough to let them owe me one) wants me to owe them one rather than owing you one. So if they do something for you, you could give them the "marker" you got when you did me a favor and now I owe them a favor. These "markers" can function as a currency. It's kind of like a system where all that exists is balances between people. You may trust me enough to extend me credit. So when I want something from you, you may let me owe you $50 but no more. You now have a +$50 balance and I have a -$50 balance. Now if I want something else from you, I'm out of credit. So I need to find someone who either you owe money to or who will let you borrow from them and give them something for which they in return will restore my credit. So, for example, say you have Alice, Bill, and Charlie. Alice is highly trusted because she has a valuable commercial network and both Bill and Charlie are willing to let Alice owe them money. Alice needs something from Charlie and in exchange Charlie lets Alice owe her $20. So now, Charlie owes Alice $20. Alice can borrow from Bill or Charlie. Now, say Bill wants something from Alice. Alice won't extend Bill any credit because she doesn't trust him. But Bill can give Charlie $20 and in exchange for the $20 Alice owes him and now Alice owes $20 to Bill. Bill can pay Alice $20 with her own IOU. This is precisely how all assets other than XRP work in the XRP Ledger. They're always balances between accounts, either account can extend credit to the other, and balances can "ripple" through accounts. By having XRP in the mix, credit can be settled and restored immediately. For example, Alice can place an offer to give out a $10 IOU for 32 XRP. Now if someone owes Alice $10, they can buy a $10 IOU from Alice and the two IOUs cancel out. This will restore their credit. This is an implementation of Ryan Fugger's original vision of money arising out of community relationships and providing people a network of assets and credits they can contribute to and draw off of. Arthur's genius was to provide a system of gateways to allow the system to be easily connected to external financial systems to help avoid the problem of long paths or unidirectional flows.
  7. JoelKatz

    Hi! I'm Bob

    We certainly would never discourage anyone from using the XRPL's distributed exchange feature! I'm still a bit sad that our strategy lead us in a different direction and that we abandoned the nascent ecosystem we had been building. It was clear that the feature was way ahead of its time and there was no direct path to adoption then. I talk to Ethan (head of Xpring and pretty much everything at Ripple other than cross-currency payments) frequently about whether there are good use cases for the ledger's decentralized exchange now and whether that's something we can use Xpring to help develop. I have a plan that moves us in that direction that I've been working on and shown to several people inside the company. The problem I keep coming back to is that there isn't quite a great use case that I can see how to move to a product just yet. But getting more minds thinking in that direction might yield results and time has brought the rest of the world in this direction. The other thing that Arthur and I built into the ledger in the early days is community credit. That is, I think, even further ahead of its time and even harder to see a solid use case for in the near term. I sometimes feel like I work for Twitter in 2000 and I'm trying to explain to everyone that for us to really grow, people need better phones. Of course, there was no Twitter in 2000 -- it was too early. I'm trying to find ways to make it later as quickly as possible.
  8. Say xRapid users start performing a lot of USD->XRP->MXN payments. There are two things that might happen: Market makers start making more money. This attracts more market makers. Liquidity improves, spreads go down. All the liquidity gets used up. There just isn't enough "bandwidth" left in the market makers and liquidity dries up. I don't think 2 is going to happen. But I won't be able to prove that until xRapid volumes ramp up and we see what happens. We've done a lot of thinking and working on how we're going to monitor market response to learn as much as possible so that we can make the best possible decisions about future corridors and mechanisms. Brad Chase, one of the stars on the C++/rippled team, moved to the data team to help them out with this. Initially I was sad to lose him from that team, but then I realized how awesome it would be to have someone on the data team who knew everyone on the C++/rippled team and knows how the XRP Ledger works in great detail.
  9. I think my previous title was much cooler, but CTO is more impressive. Ripple is going to retire the title of "Chief Cryptographer" like a jersey number.
  10. xRapid includes a feature that sets a one-minute time limit for an exchange to fill an order to minimize the impact of price volatility. During the demo, filling the order took longer than a minute, which triggered xRapid to cancel the order and thus the payment. Across all xRapid test and pilot payments ever, this is the first instance of this occurring. The demo UI was not sophisticated enough to handle this case, designed just to get a quote, display it, and initiate the payment. So the team repeated the payment, requesting another quote and executing it against a backup xRapid server configured to mock the behavior of the exchanges. The repeated payment was a live demo of how an xRapid payment works but did not involve a live transfer over the XRP Ledger. We apologize for not making this clear during our demonstration. We recorded a live xRapid transaction at 11:28 am PST. The payment took place in just under 2 minutes and a typical remittance customer would have seen 52% cost-savings from it. You can track the payment over the ledger on XRP Charts. The transaction ID is 29E4F8E81B3E5F5E5A9A5766D1C56992E6D4F18ED62DFBEC3FBCE14189FEE871.
  11. See my comment on Twitter for my general view on this predictable failure. But I do want to add three points about how Ripple deals with backend issues: First, we've been doing this for a few years now. A major focus of development on what is now xCurrent is learning from integration issues and ensuring that they don't repeat. Second, while the backend issues may prevent particular partners from getting particular benefits, they're almost never a deal killer. If a particular partner wants a particular benefit, they'll fix the backend issues if they have to. Third, we're very very clever in how we market xCurrent to banks now (and similarly how we market xVia and xRapid). We try to make sure the partner has a specific business need that is important to them. We get high-level executive buy in to use the product in production to solve that particular business need. This means that even if it costs them millions of dollars to address the back end issue to get the particular benefit they want, they're incentivized to do it because solving that particular operational problem was their motive in using the product. This also helps to ensure pilots move to production and produce volume,
  12. My work as a developer for rippled has lately been a lot less actual coding and more meeting with the fine folks who are doing the coding. I have done a few experimental bits and handed off the promising ones to others.
  13. Once the release or cancel condition of an escrow has been met, anyone can release or cancel it. While it's not strictly required that anyone be able to do, it is important that not just the owner can do it. The point of an escrow is to take some control over the funds away from the owner. We designed it so that anyone could do so that a third party could do it if there was, for example, an escrow agent or a monitoring system. We don't always finish our own escrows right when they release. Of course, who cancels or finishes the escrow has no control over where the funds go, the set up of the escrow controls that. This also allows good samaritans to clean up expired or finished junk.
  14. Do you remember what service you used to create your wallet?
  15. No problem. If you want to narrow it down to one or two that you'd like me to look at closely, I'd be happy to do it.
  • Create New...