Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JoelKatz

  1. Since 2012, Ripple has been committed to advancing the XRP Ledger as an open, decentralized system for payments. We have worked together with the community to dramatically increase the decentralization, performance, and feature set over the last seven years. Ripple’s vision for the XRP Ledger is for it to continue to provide the best interoperability with Interledger. Key to this vision is for the XRP Ledger to remain best in class in security, performance, and settlement features. We’ve been working on a number of possible features and design changes that could be introduced to the XRP Ledger, and we want input from the entire community about these features. How helpful are they to the use cases that the community is currently pursuing? What changes are developers and contributors to XRP Ledger interested in implementing? Today, we are posting descriptions of many possible enhancements to the XRP Ledger. They fall broadly into three categories: Consensus: Consensus is the heart of the XRP Ledger. It’s the way the ledger makes forward progress in a decentralized way. While PoW has provided only limited decentralization and appears to be a technological dead end, distributed agreement algorithms such as the XRP Ledger’s consensus algorithm provide real decentralization and continue to improve in their performance and reliability, year after year. Several of the suggested enhancements focus on improving the robustness of the XRP Ledger’s consensus mechanism. Performance and Resource Consumption: Due to the nature of public ledger systems, every on-ledger transaction imposes some resource costs on every participant. This creates a trade-off where increasing the transaction rate and lowering transaction fees can increase operational costs and drive some participants out of the ecosystem. Keeping resource consumption down increases the set of participants who can run their own server nodes, improving decentralization. Some of the suggested improvements aim to increase our understanding of the software’s resource consumption, reduce the consumption of bandwidth and memory, and improve network reliability. Features: The XRP Ledger currently has a sophisticated feature set including account management features, powerful multisigning, a decentralized exchange, and best-in-class support for off-ledger scaling. However, there are always more things it could do. The suggested improvements in this category add new capabilities such as an XRP-collateralized stablecoin and ways to ease the burden of the 20 XRP account reserve. We would appreciate members of the XRP Ledger community looking over these suggestions and providing feedback. Suggestions for other features are welcome as well. Let’s build a roadmap to continue innovating together. You can find all of the suggestions in one place on Xpring's blog post. There are also links there to the individual forum posts for each feature for discussions.
  2. I think we did add the ledger sequence number to pseudo-transactions (to ensure that they have unique hashes) some time ago.
  3. The server provides a best effort but ultimately relies on the submitter to re-submit the transaction if they want it to succeed. Generally, if a transaction is received from a client (as opposed to a peer) it will be retried a few times in the next few ledgers if it doesn't fail definitively.
  4. When you submit a transaction and get a return code, the return code tells you what happened to that submission. It is not telling you what may or may not ultimately happen to the transaction. For example, you may submit a transaction with sequence 6 that your local server accepts, then you submit another transaction with sequence 6 and the server returns a tefPAST_SEQ because the account is past that sequence. But if that first transaction gets rejected for some reason (say it has a last valid ledger that passes before it's accepted by consensus) then the transaction whose prior submission failed with a "tefPAST_SEQ" can automatically be re-submitted by the server and can then succeed because the conflicting transaction was rejected. To get a final result for a transaction, one of the following has to happen: 1. The transaction has to be rejected as malformed or definitively invalid (like a tem* error). 2. You have to see the transaction's last valid ledger pass in a fully-validated ledger without the transaction having been included in any ledger. 3. You have to see a transaction with the same sequence number in a fully-validated ledger. Results not found in or from fully-validated ledgers do not provide guarantees.
  5. 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.
  6. 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
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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,
  16. 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.
  17. 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.
  18. Do you remember what service you used to create your wallet?
  19. 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.
  20. Programmatic literally means that they're made by a program. Ripple employs third party market makers to execute these XRP sales to ensure that we can't control the timing or volume to manipulate the markets or benefit from inside information and also to ensure that Ripple insiders (including me) can't use intimate knowledge of the sales strategy to their own advantage. These are professional market makers who understand that we don't want to kill rallies or engineer the price but want to sell with minimal impact.
  21. Yes, that's exactly it. Programmatic sales are made by market making on open markets. They don't include a lockup and Ripple has almost no control over who gets the XRP. They effectively become part of the open market. Institutional sales are made directly to investors. They might include a lockup or other kinds of deals and Ripple gets to pick and choose who they do business with. One good thing I think these numbers clearly prove is that Ripple doesn't have to sell XRP at a discount to FIs or make mass sales to institutions with no lockup to raise revenue. Sales on the open market are the majority of the volume. That means that Ripple can afford to be picky in who it makes institutional sales to and thus it's reasonable to infer that Ripple likely thinks those have strategic value. Ripple does not need to sell XRP at a discount to raise revenue, the open market clearly suffices. And Ripple is not selling large amounts of XRP at a discount to undermine the market. On the downside, if you think that Ripple is a brilliant strategist making amazing backroom deals that will incentivize the entire financial industry to use XRP, seeing that such backroom deals are a fairly small percentage of total XRP released might be thought of as a negative. Alternatively, it means we're confident we'll succeed without such deals or that such deals don't involve large amounts of XRP. The point is -- you have the data.
  22. Some of them fail for fairly obvious reasons. For example, F84CDAB9C9B846AC3F2B5158C5BC683CD0A7AA9AFC296C21CAC263A684CF59A6 tried to offer USD issued by rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq, but you only held USD issued by rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B. You must be able to transfer at least some of the asset you are trying to give to whoever takes your offer or the offer will not be placed.
  23. Ripple is not targeting XRP at "retail" use. There are a variety of reasons for this, including the regulatory challenge, but it's also because we (at least some of us) don't think any cryptocurrencies are quite ready for mass adoption through this route yet. (Just as you probably couldn't have launched anything remotely resembling Twitter or Facebook in 1988.) We did pursue a gateway strategy for several years. We had a very hard time onboarding gateways, and an unreliable gateway is probably worse than no gateway. Gateways faced challenges with regulatory compliance, customer service, and finding a good revenue model. Part of the problem is interest rates being at a very low level, making it not particularly profitable to hold other people's money. The security problems with interacting with cryptos didn't help either. So we pivoted to a strategy where we're promoting the XRP Ledger primarily as the ultimate store of XRP rather than as a decentralized exchange. We plan to expand and enhance our product line's XRP integration to provide XRP liquidity and take advantage of XRP liquidity wherever it may be. xRapid is our first big push to connect payments to XRP settlement.
  24. I think another interesting point is the ratio of sales off market to sales on open markets. You can argue the pluses and minuses of both, but having the actual numbers helps to put those arguments in context.
  • Create New...