Jump to content

mDuo13

Ripple Employee
  • Content Count

    478
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by mDuo13

  1. Memos are part of the signed part of the transaction blob. So if you signed a transaction with a memo, the memo can't be removed without invalidating the transaction signature. Now, the Data API doesn't necessarily need to serve transactions with valid signatures (it doesn't pull things directly from the blockchain), but the Websocket API does, and it doesn't see the memos, either.... so I think this has to be an issue with your bot. Ultimately no protocol changes have happened as a result of the "memo takedown squad" thing because it ended up being way more bluster than substance. I think it's healthy to continue to discuss whether the protocol should adjust transaction cost requirements based on the size and complexity of the transaction, but it's become apparent that nothing urgently needs to change so we can take the time to get it right.
  2. I think sometimes motivated reasoning tends to convince people that everything has to fit together, that no technology or effort is worthless, or won't be used. The reality is, we don't really know which ones could be or will be useful, and not everything always fits together into a grand master plan. One of the bigger open question around the XRP Ledger today is whether the decentralized exchange has a future. Technologically, it works pretty well. But does it solve a real problem? At the time it was created, I think the idea was that cryptocurrency exchanges were notoriously unreliable (a criticism which is still pretty valid today, although things have improved a lot since 2012) so why not move the trading on-chain and reduce the amount of work that had to be done at the endpoints? Running a gateway should be easier than running an exchange since you can implement less trading stuff and you only have to custody and track assets vs liabilities for (as little as) one fiat currency. In practice, plenty of gateways have still been unreliable, plus their business model is niche enough that it's not that well understood compared to exchanges, especially in how regulators should approach them: are they providing accounting software? Money transmitting services? Should they be treated as banks? On top of that, in recent years the industry has realized that one of the core challenges for blockchains will be scaling to mass adoption, so having trading activity on-chain competes with other uses like payments for resources that will eventually be scarce... but then again, currently the XRP Ledger has plenty of unused capacity because it's so much more efficient than proof-of-work blockchains. Meanwhile, the Interledger Protocol has introduced a different way to do currency conversions in a way that's essentially infinitely scalable. There are, of course, also questions for regulators about what it means legally to operate a connector in the Interledger. So, one view is that Interledger will eventually make the decentralized exchange completely obsolete, since on-chain transactions will only be used to settle balances between nodes (with no currency conversion on-chain). But another view is that, for a case like RippleNet's on-demand liquidity service (xRapid), the whole process of setting up accounts with exchanges, depositing, trading withdrawing, depositing, trading, and withdrawing again is a process that could be way more efficient if the actual exchange of currency occurred atomically on-chain. Will RippleNet and Interledger v4 directly interact? Will either one use the XRPL's DEX? There are lots of potential futures, and ideas of how to best use everything that exists today to build what ought to exist tomorrow. I won't say what Ripple's planning next, and I won't pretend to talk for leadership about which path the company thinks is most likely to succeed. But my point is, not everything needs to fit together into a perfect, planned puzzle. The Internet of Value is uncharted territory, and some paths might lead to dead ends. Some paths might take you to the same point, the long way around. We'll only know when we get there.
  3. Agree it looks like database corruption, but I've opened an issue in the rippled repo just in case. I'll also add the error message to the troubleshooting instructions when we have a better idea what the cause is and how to address it (even if the answer is just to blow away the databases and start fresh).
  4. I'm not sure I understand the original question. If you want to know if the XRP Ledger can be used for things other than bridging assets... of course it can! So can many systems. It may or may not be that the XRP Ledger is the best (or even a good) way to accomplish something, but you'd have to be more specific for me to clarify what can and can't be done. The XRP Ledger is not intended for storage of arbitrary data, so the existing transaction types and interfaces do not make it easy to do that sort of thing, but it technically can be done. There are probably plenty of things you could piggy-back onto the XRP Ledger network, like public key rotation, broadcast messaging, etc. As always, the question is, is it economic and socially responsible to do so? And unless I know more about what you have in mind, I can't really clarify.
  5. There are several important topics being discussed in this thread and it's hard to address all of them adequately, but I'll try. First, the scenario @jn_r described is my personal biggest concern for the XRP Ledger. If Ripple's recommended UNL was changed maliciously, I think it's an open question how the ecosystem would react. I don't think the technology has been specifically tested for this scenario, but it seems plausible to me that servers that trust the recommended UNL could report manipulated data until their operators realized what was happening. Now, it wouldn't be that easy for someone outside of Ripple to change the recommended UNL maliciously (you'd need control over both the domain and the key used to sign the UNL) but it's not out of the question that a rogue Ripple employee with privileged access or a government-level power applying pressure to Ripple could make it happen. This is a risk I'd really like to see addressed. So far as I've seen, the approach with the best potential would be to have a list that's either multi-signed, or requires agreement for some M-of-N lists. (Right now there are two kind of closely related entities publishing recommended UNLs—Ripple and Coil—so there's still some need for the ecosystem to grow for that to happen.) Meanwhile, others can and have created forks of the XRP Ledger, generally using the "from scratch" approach Sukrim described. Several have also forked the software itself, like Stellar, CasinoCoin (who forked our old docs), RADAR (who forked our even older docs, lol), etc. These projects don't quite have the same combination of credibility (including continuity!), technical expertise, regulatory expertise, and existing business relationships that Ripple has. (It's probably unfair to group Stellar with those other two, but, whatever.) Now, maybe a big company or organization could try to do the same thing, but at this point, I think it's not too likely. Either they can accept that many of the world's leading blockchain experts already work at Ripple so they may as well just work with us, or they don't like what we've done and they may as well lift a few of the good ideas while rebuilding the code from scratch (basically what Facebook did with Libra).
  6. You have it pretty much right. There's a more detailed set of instructions here: https://xrpl.org/look-up-transaction-results.html
  7. Ripple didn't "pay" MoneyGram to implement it. Ripple invested in MoneyGram to convince them to implement it. The difference is that Ripple is expecting their investment to become worth a lot more when MoneyGram reaps the benefits of implementing it.
  8. 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.
  9. 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.
  10. 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!
  11. In the mean time, using a configurable software firewall is a decent workaround. The rbh script (courtesy @SkeinGraham) is one way to do it.
  12. 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.
  13. 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.
  14. 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!)
  15. 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.
  16. 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.
  17. 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?
  18. 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!
  19. 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.
  20. 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!
  21. 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)
  22. What software are you using to generate the signature? ripple-lib? rippled? Something else?
  23. Yep, I've been thinking the same thing. Doing that involves a few extra challenges (which I've put into a ticket for tracking) but I'd definitely like to see it done. Won't be on top of my to-do list because I'm getting ready for rippled 1.3.0 plus finishing off some stuff I've already started, though. Of course, you could also contribute the changes yourself. The tool's HTML and JavaScript are open-source...
  24. To reinforce what pftq said, "2-factor" authentication is essentially the same as 2-of-2 multisigning, with the added rule that one of the two keys is kept on a specific device. It's theoretically possible to set up a 2-factor-like system for an XRP Ledger account, but I'm not familiar with any hardware or software that makes it easy at the moment. A Ledger Nano S, for example, can single-sign a transaction while keeping the key on the device, but I haven't heard anything that confirms that it can provide the first signature of a multi-signature. (I don't have one so I can't confirm myself whether it's possible.) But, if it could, that would be a way to do effectively 2-factor XRP transactions.
×
×
  • Create New...