Jump to content

mDuo13

Ripple Employee
  • Content Count

    470
  • Joined

  • Last visited

  • Days Won

    18

mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

About mDuo13

  • Rank
    Regular

Profile Information

  • Gender
    Not Telling
  • Ripple Address
    ra5nK24KXen9AHvsdFTKHSANinZseWnPcX

Recent Profile Visitors

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

  1. To answer the original question ("How would a global recession affect Ripple's strategy?"), I can offer my personal opinion. To be crystal clear: This is not a statement of what Ripple, the company, will do or is planning on doing. This is not using "insider" knowledge. This is just my own read on the situation from having been closely involved in this space and witnessing the company from up close for a long time. I believe Ripple would, by and large, keep its head down and continue working on the fundamental challenges of the internet of value. Chris Larsen loves to talk about how this is a marathon, not a sprint. Brad Garlinghouse believes the company should tune out the noise and get to work. Many employees at Ripple are doing roughly that today. (Not me; I'm here answering silly questions on a forum. Sorry!) But there are a lot of problems, many of them not easily solved, that people need to work on, from large to small. Scaling is always a challenge, custody is tricky, public transactions aren't for everyone and everything. Regulations are complex. Hiring and onboarding new employees is a lot of work. Even little things like translating error messages so people can more easily build stuff around the world is work that needs to be done. And most of that—regulations probably being the one exception—doesn't change in a recession. Hiring might be easier in a recession. Selling to banks and getting them to build on this stuff might be harder. The market price of XRP, of stocks, whatever else, will fluctuate due to expectations and hype and whatnot. Underneath that, we'd like to improve the fundamentals for the company, the XRP Ledger, and the world as a whole so that money can move faster, benefit more people, enable more types of work that people want to do... Cycles like booms and recessions provide opportunities as long as you keep your cool. And that's what I'm counting on the company to do.
  2. Usually the Data API is fine and good and can give you a lot of stuff pretty conveniently. Once in a while something goes wrong with the importer, or the database, or something, and it can fall behind, or even give wrong results (generally the "wrong" results are just for derived stuff like volume estimates, exchange rates between currencies, etc.). s2 goes directly to full-history rippled servers, which are the absolute backbone of the XRP Ledger. They'll always give you the correct data. (But they may be a pain in the rear end to work with. As someone who has some ideas about the rippled API, I'm probably more acquainted than most with the annoyances than most.
  3. Would love to see more integrations for using XRP for things like paying merchants. Ripple hasn't focused on it (we're more interested in cross-border payments in the broader sense) but there's certainly room to grow. Now with Xpring there's finally some room for the company to broaden its interests and help out anyone who's working on this stuff. One challenge is that the XRP Ledger (or any blockchain) isn't efficient enough to scale to every human and device having their own account in the XRP Ledger's shared state. Just assuming people will have XRP addresses may work well for early adopters, but eventually a more layered architecture will be necessary unless XRPL's core technology can become much more optimized than it is today. (Same goes double for other blockchains, especially proof-of-work ones that are even less efficient than XRPL!) Things like sidechains, hosted wallets, or something else. That's the kind of problem that Interledger is well-suited to solve, but Interledger's production network is still in its early stages so there are lots of things to work out and standardize like peering agreements, legal obligations, common tooling and methods of settling obligations, etc. By the way, if you're accepting payments in XRP like in the pseudocode above, don't forget to check the delivered_amount so you don't get tricked by partial payments!
  4. In the mean time, using a configurable software firewall is a decent workaround. The rbh script (courtesy @SkeinGraham) is one way to do it.
  5. Should be plenty possible. I guess it depends on what kind of user flow you had in mind, but having a service that just monitors for incoming payments of XRP with specific destination tags/memos/invoiceIDs/whatever and then crediting people with the appropriate items in the in-game databases shouldn't be much harder than anything else. You could potentially also use on-ledger issued currencies to represent different types of in-game resources and make markets for trading those to XRP/whatever else but that would involve some more complications.
  6. Sadly, it's not that convenient. After a reboot, a server needs ~5 minutes to re-sync to the network. More importantly, the performance characteristics of a server that has everything it needs in RAM are very different from a server that has to go to disk for certain items. At a certain point, the server that can't fit everything in RAM is going to fall behind and get desynced from the network. If that were to happen to enough validators, well-connected hubs, etc., it could cause intermittent outages (like brownouts in the XRP Ledger), increased fees, it could become more complicated to query history from public servers, etc. With a fast SSD and NuDB, a rippled server can access a lot of data with very little RAM usage, but it's inevitable that some amount of traffic is more than the hardware can handle. That's just the nature of any computing system. And it doesn't matter whether that's an intentional "attack" or just popular high-volume "legitimate" usage. Look at what CryptoKitties did to Ethereum. Same principle. What's "an attack" and what's "legitimate usage" is kind of subjective, because intent is hard to prove. One of the major differentiators I see is whether it's a small number of people or a large number. The XRP Ledger already has fee mechanisms to make it expensive for a small number of people to attack the ledger in this way. Any system will break if the attackers have enough resources and determination; it's always just a question of the degree of difficulty, and whether the system has any weaknesses that can be exploited to augment the attackers' strength. (For example, NTP reflection is an example of an augmentation technique.) Fortunately for everyone (except the attackers), it seems like the scope of this current attack isn't even close to overloading the hardware specs of the machines in the network today. I don't know if that's because the fee mechanisms worked as intended or because the attackers simply weren't serious. Maybe the fees on large transactions aren't currently enough to discourage this kind of attack effectively; any fee mechanism is imperfect, after all. But as of right now, it seems like it's working as intended.
  7. Excellent! It's great to see IPv6 support and an xrp-ledger.toml file! It's also great to get more validators in different parts of the world. (I wonder how many validators are in the Netherlands now. I'm guessing you're not the only one!)
  8. Ah, yes. The TLD is currently restricted to 6 characters, which might've been the longest one at the time that regular expression was originally written some years ago. PR#625 should fix that. Edit: and now it's done. The TOML checker now accepts skein.systems and a wider range of valid domains with unusual TLDs.
  9. It's a statement of intent. See the full description. All the fields are optional, so you can provide the network even if you don't want to specify your exact UNL.
  10. Welcome aboard! Great to get new validators on the network. How was the process of performance tweaking and setting up validator keys? Did you hit any wrinkles or challenges worth mentioning? If you've got any details you want to contribute back to the capacity planning or validator setup instructions, I'd love to help get that information published so others can follow in your footsteps! If everything went smoothly, that's also great feedback to hear, of course. P.S. if you're looking for your next project, may I suggest setting up an xrp-ledger.toml file?
  11. Happy Friday, everyone (or happy Saturday, depending on your time zone)! There's a new blog post and tool on the XRP Ledger Dev Portal. This time it's about the xrp-ledger.toml file, and why and how you can use it to identify yourself to the masses. Read the blog post here: https://xrpl.org/blog/2019/labeling-the-internet-of-value.html Use the new checker here: https://xrpl.org/xrp-ledger-toml-checker.html (Try entering "alloy.ee" or "mduo13.com") If you run a validator or some other XRP-related side project, setting up an xrp-ledger.toml file could be a nice, short weekend project. Have fun!
  12. Basically everything is retried automatically right now. Even stuff where it's basically impossible for it to succeed on retry like tem codes. Actually, there's a bug where only "ter" codes (the ones that actually might succeed on retry!) aren't retried, except for terQUEUED, which is retried.
  13. That's a great catch, and something I had no idea about. I've had the project of describing the signing process itself in more detail on my backlog for a while, but I've added it as an issue in the public repo just now with notes on this detail, so when I—or someone else, if the community beats me to it—write the docs, this will be included!
  14. Interesting. I wrote that module myself, but I haven't tested it extensively with multi-signatures. It's possible that I made an oversight and it doesn't serialize transactions correctly for multi-signatures. EDIT: Oh, also, are you sure you're using the correct prefix for an unsigned multi-signing transaction? (SMT\0 instead of STX\0)
  15. What software are you using to generate the signature? ripple-lib? rippled? Something else?
×
×
  • Create New...