Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

About mDuo13

  • Rank

Profile Information

  • Gender
    Not Telling
  • Ripple Address

Recent Profile Visitors

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

  1. 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.
  2. 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.
  3. 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?
  4. 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!
  5. 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.
  6. 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!
  7. 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)
  8. What software are you using to generate the signature? ripple-lib? rippled? Something else?
  9. 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...
  10. 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.
  11. I had no idea it was real until a few minutes ago. But this is huge. Pretty excited to see where this takes us, both the company and the broader XRP community.
  12. The XRP Ledger dev portal is not just moving to new digs, it's got a new philosophy. It's not Ripple's site, it's the XRP Ledger's site. (We're just helping.) Check out the new site and get BUIDLing! https://xrpl.org/
  13. We recently launched a new interactive tutorial on the XRP Ledger Dev Portal, showing how to Monitor Incoming Payments with WebSocket. It has JavaScript examples that don't use ripple-lib, so you can hopefully adapt them to other programming languages. (In fact, if you do go through the exercise to re-create any of the sample code in other programming languages, please contribute your code samples back using the "Edit on GitHub" button on the page!) It has interactive sections that let you connect to a public XRP Test Net server using WebSocket, and subscribe to transactions affecting a particular account, and summarize how much XRP they delivered. (You may need to use the Transaction Sender to actually send some payments while you're monitoring.) I hope this guide is useful and easy to understand. We welcome your feedback, so I'd love to hear from you if you find the docs useful, confusing, or if you have ideas for how to improve them!
  14. If you have software that handles XRP payments, you can connect it to the Test Net and then test it by sending partial payments with the (recently added) Transaction Sender tool, which handles all the setup that's necessary to send maliciously misleading partial payments.
  • Create New...