Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by mDuo13

  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.
  15. We've launched some new items on the dev site hopefully providing great value to those who want to receive transactions in the XRP Ledger. (More on that still in the queue.) Transaction Sender - A new interactive tool that automatically provisions some test net addresses and lets you send transactions of various types to the test net address of your choice. You can use this to, among other things, test how your systems handle incoming partial payments, TrustSet transactions, etc. Look Up Transaction Results - Vastly expanded from the previous docs, this page now talks about how to know when a transaction's outcome is final and how to read transaction metadata to see what a transaction actually did. Transaction Metadata - Now finally describes all the stuff that can appear in the "AffectedNodes" array, including some of the weird edge cases that can trip you up when you write processing logic.
  16. Two announcements to the dev blog today: rippled 1.2.4 has been released. Yes, it's another hotfix. This one should hopefully fix the validator list expiry problem noted in this thread once and for all. The MultiSignReserve amendment is now enabled, so you can go and update your signer lists to save a few sweet, sweet XRP. Depending on how many signers you have on your multi-signing list, this cuts the reserve requirement down by 10 to 45 XRP! (Used to be 15-50 XRP; now it's always 5 XRP.)
  17. To my understanding, validators only send "yes" votes, so a missing vote means "no." That's not been true for a few versions now. The SHAMapV2 amendment is commented out because of this (same w/ OwnerPaysFee and Tickets). We've had numerous discussions within Ripple on how we could improve the amendment voting process, but it's a more challenging problem than most people initially think. If you change the default to "no", then even minor fixes probably won't get enabled without a lot of collective effort. Validator operators might be more active than gateway operators, who are staggeringly nonresponsive regarding new features¹, but it's still a big ask to get everyone to go in and manually add "fix1XYZ" to their configs and restart every time there's a release with fixes to transaction processing. If you add an "abstain" option (either explicit or treating non-votes as abstentions) then you have to figure out how that affects the necessary quorum for a majority. If abstentions are subtracted from the necessary total, then it could take very few explicit votes to get a majority, which makes voting "abstain" functionally very close to voting "yes". But if the necessary total doesn't change with abstentions, then voting "abstain" is identical to voting "no". The current system works very well as long as all amendments in the code that validators are running are fully implemented and sane. (Historically, Ripple hasn't been great about this, as evidenced by SHAMapV2. In the time since adding more external validators to the list, we're being much more careful about it.) Even if validators update without thinking, the two-week approval process provides a safeguard for validators to see, investigate, and potentially vote against new amendments they're not ready for. On top of that, going forward, Ripple aims to publish information earlier in the process of developing new amendments, so what happened with Checks won't be the norm. I do agree that "veto" is not really the right word for the setting in the config file, when it really means "vote no". If we do an update to the config file format, I'll push to change it to something a bit more intuitive. ¹ For example, when DefaultRipple got added, there was at least one gateway who never enabled it despite continuing to operate for quite a while, even after being contacted several times. Because of the way the NoRipple settings worked out, their legacy customers were still able to send and receive IOUs as normal, but new customers couldn't send to other new customers because the gateway was enabling NoRipple by default on new trust lines.
  18. I don't have the answers here, but if you're trying to look up an AccountRoot object, be sure you include the space key 0x0061 before hashing. (See AccountRoot ID Format and the corresponding pages for other object types. The Hash Prefixes table may also be useful for figuring out other hashes, though if you have the hash itself, that already takes it into account.)
  19. https://developers.ripple.com/blog/2019/corrections-to-data-api-xrp-charts-metrics.html tl;dr: yep, it was a Data API problem overcounting the number of ledgers. We've reprocessed the data so it should now show the correct metrics.
  20. Thanks, fixed the link. As for the BUIDL link, honestly, that article was the best explanation I could find for the "BUIDL" meme. (Seriously, get me a better one and I'll replace it.)
  21. The Ripple Dev Blog has moved. The new blog location has been inaugurated with a feature article about Interledger, and we plan to continue posting new blog articles at a higher rate than we previously have. *crosses fingers* Check out that Interledger article here: https://developers.ripple.com/blog/2019/interledger-checkin.html If you have any technical topics you'd like us to cover or other things you'd like to see from the Ripple Dev Blog, feel free to reply here and we'll do what we can to address them. (As usual, we cannot provide financial advice, forecast moon when the price of XRP, reveal confidential info about partners, comment on litigation, etc.) We can and are happy to talk about open source technology, the XRP Ledger's many features and potential uses, and provide insight into where Ripple's devs see fintech going in general over the next few years.
  22. I find that developers who have the most experience building stuff on the XRP Ledger tend to share their pet projects on this forum, on Twitter, and on Reddit. So that's one way to find them. But in general, developers with blockchain / DApp development experience are in very high demand and are pretty rare. In my experience, it's more effective to hire developers with good general purpose skills and experience who are eager to learn new things. Many of the devs I've met at Ripple didn't have much XRP Ledger experience before they were hired, but came from various technical backgrounds and learned the specifics on the job. Some background skills that can come in handy: Programming languages: JavaScript, C++, or others, but those two are the best for XRP Ledger development. I've seen some cool things in Ruby, Python, and C# as well so I wouldn't count almost any language out. Economic theory / understanding of the financial system. Most devs don't have much understanding of this, but more are learning. Stuff like understanding what ACH and SEPA are, what are remittances, what are securities, what's front-running, etc. This is important for roles other than devs, too—One of the most important challenges for any money/cryptocurrency/financial business is understanding the laws that are relevant to your jurisdiction well enough to make a reasonable argument that you are complying with them. Information security. Understanding how to use digital signatures securely, how to evaluate different algorithms, how to manage keys and passwords safely, etc. Elliptic curve cryptography is cool, but you don't necessarily need to know that much about the innards of the algorithms, just enough to evaluate which ones to use when and how. Scalable, robust system architecture and design. Not everything belongs on a blockchain. Usually, the best architecture for a given project uses some more "traditional" technologies like databases. So understanding that, and how to balance and scale that stuff is very relevant. User interface design / user experience testing. If a human is going to interact with your software at some point, you should have an idea of how to make their experience as positive and effective as possible. Frequently that means testing how users interact with it, designing with specific user goals in mind, etc. All manner of soft skills. You need to be able to communicate with your colleagues and others outside your business, to share what you're working on, provide constructive feedback and encouragement, to coordinate and build agreement on how to connect pieces that are being built by different people or companies. Soft skills are how you make sure that you and everyone you work with can do their best work. Overall, the highest quality developers are the ones who are motivated to make a quality product and patient enough to stick with it. Best of luck finding someone who fits that description! (No apologies if we get to them first.)
  23. If you want the details, @devnullprod's summary of the peerfinder and overlay network code is a good source. (I can't guarantee it's 100% accurate, but by and large I think it is.) As for other info about the anti-spam measures and stuff, I'm not totally sure. I think each server is mostly willing to provide whatever ledger data they have to any peers, relay validations, etc. as long as the signatures check out and the server is not currently overloaded. If a server gets busy then it starts refusing certain requests. I'm not sure about any automated mechanisms to block abusive / extremely spammy peer connections, but I think there are some because I remember hearing that information about which peers to block is one of the things that clustered servers share with one another.
  24. When a server receives a new, valid transaction, whether from a peer or from an API submission process, it does something like the following: Compare the transaction's XRP cost and to the local load cost (based on how busy the server is) If the cost is too low: Discard the transaction for now If the cost is sufficient: Compare the transaction's XRP cost to the open ledger cost (based on how many transactions are in the current ledger vs. how many are expected to be) If the cost is sufficient: Apply the transaction to the open ledger If the cost is too low: Pre-checks the transaction to see if it's likely to succeed and is allowed to be queued If so, queues the transaction (if the queue is full, possibly kicking another, cheaper transaction, out of the queue) Otherwise, discards the transaction If the server applied the transaction to the open ledger or queued it: Broadcast the transaction to the server's direct peers. Each of those servers repeats this process from the beginning, which spreads the transaction throughout the network. There are some slightly more complicated details of how the server decides when to relay a transaction (what failures are retriable, don't send transactions right back to the peer you got them from, etc.) but that's the gist of things.
  • Create New...